To report a security vulnerability:

1. Email: security@obelisk.build
2. Include details about the vulnerability
3. Include steps to reproduce if applicable
4. We will respond within 48 hours

OBELISK is designed with defense in depth:

Actions run in sandboxes with:

• Restricted filesystem access
• No network access (by default)
• No access to undeclared inputs
• No write access outside declared outputs
• Resource limits enforced

• All cache entries are checksummed
• Cache keys include all relevant inputs
• Cache poisoning is prevented by key design

Remote execution uses:

• Versioned protocol messages
• Message size limits
• Checksums on payloads
• Authentication hooks (pluggable)

Bundles are verified:

• All entries have checksums
• Tampering is detected on load
• Divergence is detected on replay

Trusted:

• OBELISK binaries
• Configuration files (OBELISK files)
• Declared toolchains

Untrusted:

• User-provided build scripts
• Downloaded dependencies
• Remote cache content (verified)

• Privilege escalation | Sandbox + resource limits | | DoS via large outputs | Output size limits | | DoS via deep graphs | Graph complexity limits |

1. Pin toolchains: Declare exact versions
2. Verify bundles: Check bundle signatures
3. Use sandboxes: Don't disable without reason
4. Review configs: Check OBELISK files before building
5. Run updates: Keep OBELISK updated

OBELISK undergoes:

• Regular fuzzing of all parsers
• Static analysis with clang-tidy
• Dynamic analysis with sanitizers
• Annual external audit (planned)