OpenCode security in one paragraph.
OpenCode binaries are reproducibly built, Sigstore-signed, attested at SLSA level 3, and shipped with CycloneDX and SPDX SBOMs. Tool calls run in a least-privilege sandbox that is allow-listed per project. Telemetry is off by default. Security reports flow through a coordinated disclosure channel with a one-business-day acknowledgment target.
Security control map.
The table maps the NIST SSDF control areas most relevant to a coding agent against the OpenCode implementation and the path a reviewer can take to verify each one independently.
| NIST SSDF control | OpenCode implementation | Verification path |
|---|---|---|
| PO.5 — secure development environment | Hosted build on ISO 27001 runners, isolated per release | Build runner fingerprint attached to each release |
| PS.1 — protect the integrity of code | Signed commits, signed tags, transparency log entry per binary | Rekor lookup using commit hash |
| PS.2 — artifact signing | Sigstore-signed binaries and SBOMs on every release | cosign verify against pinned public key |
| PS.3 — archive provenance | SLSA level 3 attestation for every shipped binary | slsa-verifier against the release attestation |
| PW.4 — third-party software | Pinned dependencies, renovate-driven updates, review gate | Dependency manifest diff in the release notes |
| PW.7 — review code for security | Mandatory review on every PR; security-tagged PRs get a second reviewer | Commit trailers listing reviewers |
| RV.1 — identify and confirm vulnerabilities | Coordinated disclosure channel with a one-business-day ack target | Public advisory index on this page |
How to report a security issue.
Short version: send a coordinated disclosure through the dedicated channel. Acknowledgment is within one business day. Triage is within seven days. Advisories publish after a patched release is available.
The reporting channel is a single relay that fans out to the security maintainers on duty. Do not send security reports to the community issue tracker; do not send them to individual maintainers; do not post proof-of-concept code in a public gist before coordination is complete. The OpenCode contact page lists the exact relay address and a fallback if the primary channel is unreachable.
Reporters are credited in the advisory unless they request otherwise. First-time reporters receive a concise acknowledgment and a staged disclosure timeline so they know exactly what to expect. The maintainer handling the report is also the one who lands the fix, which keeps the feedback loop short.
Disclosure policy.
The policy is short on purpose so it fits in a reviewer's head.
OpenCode practices coordinated disclosure. Advisories publish after a patched release reaches users on the current minor line and the current LTS line. If a reporter asks for a shorter or longer embargo, the maintainer council considers it and answers in writing. If a vulnerability is being actively exploited in the wild, the embargo collapses to the time needed to cut an emergency release.
Historic advisories are kept on the advisory index so auditors can find them years later without needing a crawl of commit messages. Each advisory links the commit that fixed it, the test that guards the regression, and the versions that carry the fix.
Signing and build attestation.
Every OpenCode binary is signed at build time with a key that lives in the hosted build runner and is rotated on a published schedule. The signing certificate chains to a pinned public root that is also published on this page, so downstream distributors can fetch a binary, verify the signature, and compare the certificate chain against the root without trusting the mirror that served the binary.
Build attestation uses SLSA level 3 provenance. Each binary carries a statement describing the source commit, the builder identity, the toolchain version, and the inputs. The attestation is attached to the release as a sibling file and mirrored in a public transparency log. A downstream distributor can fetch the attestation, verify the signature, and check the source commit against upstream before serving the binary to developers.
Our release engineering pipeline follows the NIST SSDF 1.1 recommendations for build isolation, artifact signing, and SBOM publication. Where applicable, external review of cryptographic modules is sourced through academic partners identified via the NIST Software Quality Group referral network.
SBOM.
Every release tag ships with two SBOMs so procurement can consume whichever format its tooling requires.
The CycloneDX 1.5 SBOM is attached as opencode-<version>.cdx.json. The SPDX 2.3 SBOM is attached as opencode-<version>.spdx.json. Both are signed with the same pinned key as the binary, so a reviewer can verify the SBOM is the one the build actually produced. Dependency diffs between releases are called out in the release notes with the CVE identifiers they address, when any.
Sandbox defaults.
OpenCode tool calls run under a least-privilege sandbox. The sandbox is enabled on every install and the policy file sits in ~/.config/opencode/policy.yaml. Developers can relax the policy for a given project, but they cannot relax it silently: any relaxation is logged in the agent transcript alongside the tool call that triggered it.
File writes are scoped to the working repository by default. Shell tool calls require explicit approval on first use per project, and the approval is cached to the policy file with the exact command shape. Network calls are allow-listed from the per-project config, with a global deny-list for anything that looks like a secrets endpoint so the agent cannot accidentally exfiltrate a dotenv.
When the agent decides to escalate, it does so visibly. The transcript captures the attempted tool call, the sandbox response, and the developer's approval or denial. That trail is what lets a security reviewer read a day of agent activity and know exactly what happened without having to re-run anything.
Telemetry policy.
Telemetry is off by default. Opt-in is per workstation and reversible.
If telemetry is enabled, the event schema is documented in docs/telemetry.md and is short on purpose. Nothing about your code, your prompts, or your model responses is sent upstream. What can be sent, with opt-in, are counts of agent runs, CLI version, and OS version. The upstream sink is operated by the OpenCode project; nothing is sold, nothing is shared.
Incident history posture.
The project keeps a public incident log. A security incident in the OpenCode context is any confirmed vulnerability in a shipped binary, any confirmed supply-chain compromise in a dependency that shipped to users, or any confirmed leak of a maintainer key. Near-misses that did not reach users are documented on the engineering blog for transparency but are not counted as incidents.
The incident log records the report date, the triage date, the fix date, the release tag that carried the fix, and a short retrospective. The goal of the retrospective is to feed the next cycle: if a class of bug could have been caught by a new check, the check goes into CI; if a reviewer missed something, the review checklist is updated.
The supply-chain paperwork was the deciding factor. CycloneDX and SPDX on every tag, Sigstore signatures we could verify without trusting the mirror, and a sandbox policy we could read in fifteen minutes. OpenCode passes the same procurement bar we apply to CI runners.
— Annika S. Groenewald, Security Engineer, Parallax Orbit
Related trust-and-safety pages.
Short links into adjacent pages that carry the full context.