OpenSecOps runs in customer accounts with admin-equivalent privilege scope. Whether to trust the platform is the substantive question, not a procurement formality. This page is the entry point to the artefacts that answer it.
What's at stake
SOAR orchestrates Security Hub findings, runs auto-remediations, and creates incident tickets across customer accounts. Foundation implements multi-account governance, IAM, log aggregation and routine hygiene automation. The blast radius of a compromised release of either is comparable to that of a compromised CSPM, EDR or SIEM. OpenSecOps is built and released to that bar.
Posture
Every OpenSecOps component implements two framework claims, uniform across the suite:
We claim Build L1 rather than rounding up. Build L2 explicitly requires a hosted build platform that signs the provenance, and our release authority remains on a maintainer machine by deliberate design – release authority belongs to a named human, not to a runner.
- S2C2F Level 1 + Level 2 baseline plus the locally-runnable subset of Level 3. Hand-edited abstract dependency specs; hash-verified resolved locks; release-time CVE scan; OSSF malicious-packages feed gating; direct-dependency PyPI provenance advisory.
- SLSA Build Level 1, with documented L2-adjacent controls: Sigstore keyless signing of every release artefact, deterministic hash-pinned dependency resolution, and second-machine reproducibility verification of every committed lock.
We claim Build L1 rather than rounding up. Build L2 explicitly requires a hosted build platform that signs the provenance, and our release authority remains on a maintainer machine by deliberate design – release authority belongs to a named human, not to a runner.
What ships with every release
Three artefacts attached to every GitHub Release of a component:
Each of the three carries a Sigstore signature bundle. A single `cosign verify-blob` invocation, with the signing identity published in each component's `SECURITY.md`, confirms the bytes came from an authorised OpenSecOps signing identity.
- A CycloneDX 1.6 aggregate SBOM – every direct and transitive component, exact versions, SHA-256 hashes.
- A deterministic per-function evidence tarball – per-function CycloneDX SBOMs and PyPI publisher-provenance baselines for every Lambda function in the release.
- A SLSA Build L1 in-toto provenance document naming the build steps that ran.
Each of the three carries a Sigstore signature bundle. A single `cosign verify-blob` invocation, with the signing identity published in each component's `SECURITY.md`, confirms the bytes came from an authorised OpenSecOps signing identity.
What you can verify yourself
Four independent verifications are available against any published release tag, with no maintainer cooperation:
The full recipes are in the canonical document linked below.
- Hash verification of the deployed dependency set against PyPI.
- Per-function SBOM and provenance reproducibility from the committed locks.
- Sigstore signature verification of every release artefact.
- Lock reproducibility from the abstract spec, using the recorded `# uv-compiled-at:` timestamp as an `--exclude-newer` fence on a clean `uv` cache.
The full recipes are in the canonical document linked below.
Continuous detection between releases
A vulnerability disclosed against a pinned dependency between OpenSecOps releases reaches the maintainer without waiting for the next release-time gate run. Two layers operate today:
- Push-based. GitHub Dependabot alerts are enabled on every OpenSecOps repository, in alerts-only mode. Auto-PRs and auto-merge are explicitly disabled; alerts are detection signal, the fix itself is authored and reviewed by the core team.
- Poll-based. A daily scan-only GitHub Actions workflow runs on every public OpenSecOps-Org repository, executing the release-time gate's checks against the published locks. Sensitive findings are redacted from the world-readable workflow log; the workflow has no push, deploy, sign or release authority.
Governance
OpenSecOps is open source under MPL-2.0. The contribution model is a cathedral, not a bazaar: a small core team curates the codebase, and external pull requests are not accepted on any OpenSecOps repository, for any change. Vulnerability reports are the explicit carve-out – reports are welcomed from anyone, reporters receive named credit, and the fix itself is authored by the core team.
The CVE-response SLA is uniform across every component: critical within 3 business days, high within 10, medium and low at the next regular release. The release-time gate fails on any `pip-audit` finding regardless of severity unless it is on the per-component acknowledged-and-deferred list, published in each component's `SECURITY.md`.
No automated release path. No auto-merge dependency bot. Updates are deliberate maintainer actions.
The CVE-response SLA is uniform across every component: critical within 3 business days, high within 10, medium and low at the next regular release. The release-time gate fails on any `pip-audit` finding regardless of severity unless it is on the per-component acknowledged-and-deferred list, published in each component's `SECURITY.md`.
No automated release path. No auto-merge dependency bot. Updates are deliberate maintainer actions.
Where to find more
- OpenSecOps Supply-Chain Security and CVE Response – the canonical reference, with verification recipes, framework citations, and a procurement-questionnaire crosswalk: Documentation/docs/security/supply-chain.md
- Per-component SECURITY.md – every OpenSecOps component carries its own `SECURITY.md` at the root of the repository, with the per-component acknowledged-and-deferred CVE list, signing identities, and supply-chain status. Browse the OpenSecOps-Org GitHub organisation.
Vulnerability disclosure
Preferred channel: the GitHub Security Advisory ("Report a vulnerability") flow on the affected component repository. This produces a private advisory visible only to the core team. The public Issues tab is for non-security defects only.
For coordination on something that does not yet have a clear repository home, contact [email protected].
For coordination on something that does not yet have a clear repository home, contact [email protected].