OpenSecOps Supply Chain: Conversion Complete

[PeterBengtson]

OpenSecOps Supply Chain: Conversion Complete

12 September 2026

OpenSecOps is open-source security software that runs with administrator-equivalent privilege inside customer AWS organisations. This year we have been strengthening the supply chain behind it: making it possible for anyone deploying OpenSecOps to verify, mechanically, that what they are about to run is what we published, that it contains exactly the libraries we chose, and that none of those libraries is known to be vulnerable. That work is complete. What remains is paperwork.

Why

The code is public under MPL 2.0, and it is developed as a cathedral: a small core team makes every decision, external pull requests are not accepted, and each release is signed by a named maintainer identity. That model gives one chain of accountability for software that holds privileged access. It does not, by itself, answer the question a customer's security team will ask before granting that access: how do we know the bytes we deploy are the bytes you released, and what exactly is in them?

Until this year, the answer was partial. Direct dependencies were range-pinned and security-sensitive libraries were tightly bounded, but transitive dependencies were resolved at build time, there was no per-release bill of materials, releases were not signed, and there was no published timeline for responding to a vulnerability. Enterprise intake processes expect all four, in the vocabulary of frameworks they already use — S2C2F, SLSA, the OpenSSF Best Practices programme, the EU Cyber Resilience Act.

The plan

Bring every OpenSecOps component onto one uniform posture, so that a reviewer finds the same guarantees at the same address in every repository:

• Contents fixed. Every direct and transitive library dependency pinned to an exact version and a SHA-256 hash. pip refuses anything whose bytes do not match, so a compromised package registry cannot substitute code.
• Contents declared. A CycloneDX SBOM attached to every release, listing every component in it. When a CVE is announced, "are we affected?" is a grep, not a ticket.
• Build attested. A SLSA in-toto provenance document naming the release-gate steps that ran and the toolchain that produced the artefacts.
• Everything signed. Every release artefact carries a Sigstore signature recorded in the public Rekor transparency log.
• Vulnerabilities watched between releases. Dependabot alerts plus a daily scan on every repository; findings routed privately, never to public logs or issues.
• Response time-bound. A published SLA: critical CVE fixed in a new release within 3 business days, high within 10, medium and low in the next regular release.
• Governance stated. A SECURITY.md in every repository with the same structure: supported versions, reporting channel, SLA, posture, signing identities, an "am I affected?" recipe, and the cathedral model stated plainly.
• Verified on the customer side. The Installer checks all of the above before it deploys anything. The deploy commands themselves do not change.

Framework alignment: S2C2F Level 1 and 2 across all components (SOAR adds the locally runnable subset of Level 3), SLSA Build Level 1 with documented L2-adjacent controls. We deliberately do not claim SLSA L2, which requires a hosted build platform; release authority stays on a maintainer machine, because that is where the accountability sits. We also do not commission a paid tier-1 audit; instead we apply to OSS-funded audit programmes and document the outcome either way.

We announced this plan on 28 April and reported twelve of twenty-three components converted on 5 May.

What we did

The remaining eleven components shipped on 13 May. From that date, every component the Installer deploys — the 22 repositories declared in its apps/foundation/repos.toml and apps/soar/repos.toml, plus the Installer itself — carries signed releases with the guarantees above. (Documentation has no code and is out of scope.)

Two shapes of component emerged. Fifteen are Python-bearing, Lambda functions with library dependencies, and carry the full set: hash-pinned requirements.txt, aggregate SBOM, per-function evidence tarball, provenance, and signatures on all three. Eight are pure CloudFormation templates or JSON policy documents with no libraries at all. For those there is nothing to pin or scan, but the questions "is this what OpenSecOps published?" and "how was it built?" still apply, so a libraryless release carries a signed deterministic source archive of the tagged commit plus the same signed provenance document. The publishing tooling detects the shape from the repository itself; no per-component configuration, so the two paths cannot diverge by mistake.

On the customer side, the Installer now verifies releases at three points: its own release at ./init, each component immediately after cloning or updating it, and each component again at ./deploy before anything is built. Verification is pure Python via the sigstore package, installed by the Installer's existing hash-verified pip step — no extra tooling, no login, read-only checks against public Sigstore infrastructure. During the rolling conversion an unsigned component produced a warning and continued; since 13 May that path is gone. A component whose release lacks signatures fails closed, and a release that appears to have had its signatures stripped is refused as such.

OpenSSF Best Practices Passing level was attained the same day (bestpractices.dev/projects/12827).

Since May the pipeline has been in routine operation. The Installer alone has shipped six further releases through it, several carrying dependency CVE fixes.

Where we are

The engineering side of the plan is done. What remains is documentation anchored to specific frameworks:

• OpenSSF Best Practices Silver level. Most of its additional criteria map onto controls already shipped; the gaps are written artefacts (roadmap, style guide, assurance-case pointer), not code.
• An ECCN 5D002 / License Exception ENC classification line in each SECURITY.md — the standard export classification for security software using cryptography, which a vendor is expected to state.
• An EU Cyber Resilience Act readiness statement mapping OpenSecOps to the Act's reporting and essential-requirement obligations.
• Applications to OSS-funded audit programmes — OSTIF, OpenSSF Alpha-Omega, Sovereign Tech Agency, NLnet — with the outcome recorded in each SECURITY.md whether accepted or not.
• The CISA Secure Software Development Attestation form. This became optional under OMB M-26-05 in January; the substantive coverage is already published, and the form will be filed if and when a US federal customer asks for it.

The single canonical reference for the whole posture, with verification commands and a framework crosswalk, is Documentation/docs/security/supply-chain.md. Each component's SECURITY.md links to it.

Operational notes for upgrading

• Update the Installer first: cd Installer && git pull, then ./init on both Foundation and SOAR before ./deploy-all. The Installer verifies every component it touches; each must be on its signed release for ./deploy to proceed.
• ./init resyncs an existing component clone to the current signed release on its own, whatever state the clone was left in. The only case it refuses is a dirty working tree with uncommitted local changes, which it reports with instructions.
• ./deploy itself is unchanged.