| Version | Supported |
|---|---|
| 0.x (current) | ✅ Security fixes on best-effort basis |
CSC is pre-1.0. Security fixes are applied to the latest release on the default branch. Older versions are not backported unless a critical issue affects a deployed pilot.
Do not open a public GitHub issue for security vulnerabilities.
Instead, use this repository's GitHub Security Advisories page to report vulnerabilities privately.
- Description of the vulnerability
- Steps to reproduce or proof of concept
- Affected component (executor, sandbox, signing, approval, policy, CLI)
- Affected mode (local, hardened, or both)
- Severity assessment (your estimate)
- Any suggested fix
| Action | Target |
|---|---|
| Acknowledge receipt | 3 business days |
| Initial triage and severity assessment | 5 business days |
| Fix developed and tested | Depends on severity (see below) |
| Security advisory published | With the fix release |
| Severity | Description | Fix Target |
|---|---|---|
| Critical | Remote code execution, sandbox escape, signing key compromise | 48 hours |
| High | Privilege escalation, path traversal bypass, unsigned receipt accepted as signed | 7 days |
| Medium | Information disclosure, denial of service, approval replay in narrow conditions | 30 days |
| Low | Minor information leak, cosmetic security UI issue, documentation gap | Next release |
- High/critical issues block the bounded production claim until resolved.
- Medium issues require an explicit acceptance note with rationale if the claim is maintained.
- Low issues may remain open with documented rationale.
csc_runner/— all runner modules (executor, sandbox, signing, approval, policy, pathutil, limits)csc_runner/cli.py— CLI entry pointsschemas/— JSON Schema definitionsDockerfile— hardened mode container image- Receipt integrity and signing
- Approval artifact validation and replay prevention
- Sandbox boundary enforcement (bubblewrap launcher construction)
- Third-party dependency vulnerabilities affecting CSC (triage and remediation; upstream disclosure may also be appropriate)
- The host/container runtime configuration (we document requirements but don't control the runtime)
- PIC ecosystem components (report to PIC directly)
- Attacks requiring host root access (documented as a known limitation)
- We follow coordinated disclosure.
- We aim to publish a security advisory simultaneously with the fix release.
- Credit is given to reporters unless they request otherwise.
- We do not pay bug bounties at this time.
When a security fix is ready:
- Fix is developed and tested in the private security advisory workflow (or equivalent non-public fix branch).
- Security advisory is drafted in GitHub Security Advisories.
- Fix is merged, tagged, and released.
- Advisory is published with the release.
- Release notes reference the advisory (see
.github/SECURITY_RELEASE_TEMPLATE.md). - A regression test for the vulnerability is added to the appropriate test suite (adversarial, unit, or integration).
These are documented design boundaries, not vulnerabilities:
- Command blocking is advisory, not enforcement. The sandbox namespace is the real boundary.
- Approval replay prevention is process-local. Consumed approvals are lost on restart.
- Receipt signing proves integrity, not sandbox configuration. A signed receipt does not prove the sandbox was correctly set up.
- No syscall filtering (seccomp). Deferred to post-pilot.
- No Windows/macOS hardened mode.
- No network allowlisting. Stage 2 enforces "no network" only.
See docs/deployment-modes.md for the full security posture by mode.