Strengthening the OpenSecOps Supply Chain

OpenSecOps is open-source code under MPL 2.0, and we approach development as a cathedral, not a bazaar.                                                                                 
   
The source is public – for transparency, for verification, for security review by anyone who wants to read it. But contribution is closed. External pull requests are not accepted. Design decisions, architectural changes, and dependency updates are made by a small core team. Vulnerability reports are welcomed from anyone, with named credit; patches from external parties are not.                                                                                                                                                                        
We are deploying security software with administrator-equivalent privilege scope inside customer accounts. The cathedral model is the appropriate governance for that level of responsibility. It means there is one chain of accountability, one signing identity per release, one set of decisions about what runs with that privilege.
                                                                                                                                                                                          
This article is about strengthening the next layer of that posture: supply-chain security.

What's not changing​

​Before anything else: ./deploy is unchanged. Customer-facing deployment of OpenSecOps Foundation, OpenSecOps SOAR, and every other component continues exactly as before. This is a maintainer-side and release-side change. You will not need to install new tools, modify your scripts, or migrate anything.
                                                                                                                                                                                          
What you will see – once we land it – is a SECURITY.md file appearing on each repository's GitHub Security tab, signed release artefacts on the GitHub Releases page, and SBOMs (in CycloneDX format) attached to every release. Your existing automation keeps working; new artefacts appear alongside it.

​What's changing, and what it eliminates

Today, version specifications exist where correctness or compatibility demands them. Direct dependencies are range-pinned. Security-sensitive libraries — requests, urllib3, and others on user-input paths — are tightly bounded with explicit upper limits. What we do not yet have is uniform coverage: full lock files that pin every transitive dependency with a cryptographic hash, a machine-readable bill of materials per release, and a published vulnerability-response timeline. This initiative extends the existing discipline to every single external library, transitives included, and adds the artefacts and timelines enterprise security teams expect.

After it lands:

• Every dependency, including transitives, is pinned to an exact version with a cryptographic hash. Two builds of the same release, for the same target and toolchain, resolve the same dependency set and install only package artefacts whose bytes match the recorded hashes. A compromised upstream registry cannot silently substitute different code, because the hash check refuses to install anything that doesn't match. 
• Every release ships with a CycloneDX SBOM listing every direct and transitive component. When a CVE is announced against any library, you can grep the SBOM and answer "are we affected?" in seconds – not "open a ticket and wait for us to investigate."
• Every release artefact is cryptographically signed with Sigstore. Customers can verify that what they downloaded matches what we published, using a single cosign verify-blob command documented in SECURITY.md.                                                                                                                                                              
• Continuous CVE detection runs between releases, not only at release time. GitHub Dependabot alerts notify us when a vulnerable pinned dependency is detected. A daily scan-only workflow on each public repository acts as a between-release backstop. CVE findings and malicious-package matches are not printed in public workflow logs and do not open public issues; they are routed privately through the vulnerability-disclosure channel. The release path itself does not move — humans still decide when to ship.
• A concrete CVE-response SLA is published. For SOAR: critical → 3 business days, high → 10, medium/low → next regular release. No more "we'll get to it." A clock that starts at public disclosure or receipt of a private vulnerability report, whichever applies.     

​Where we land on the frameworks

We are aiming for a defensible, framework-anchored posture — using the language enterprise FOSS intake teams already speak:                                                                

• S2C2F (Secure Supply Chain Consumption Framework, OpenSSF): Level 1 + Level 2 baseline across all components. SOAR additionally implements the locally-runnable subset of Level 3 — malware-feed scanning against the OSSF malicious-packages feed, direct-dependency provenance checks, and the time-bound CVE-response SLA — because of SOAR's privilege scope.
• SLSA (Supply-chain Levels for Software Artifacts): Build Level 1, with documented L2-adjacent controls (Sigstore signing, hash-pinned reproducible resolution, second-machine reproducibility verification). We do not claim L2 because L2 requires a hosted build platform, and our release authority remains on a maintainer machine — deliberately.                
• CISA Secure Software Development Attestation Form: filled, signed, and published as federal-intake evidence for agencies and primes that may request it.
• ECCN 5D002 / Exception ENC: explicitly stated in SECURITY.md. Standard classification for security software using cryptography; the vendor is expected to declare it.                 
• EU Cyber Resilience Act: a CRA-readiness statement covering both the 11 September 2026 vulnerability-reporting obligations and the 11 December 2027 full-application date.            

                                                                                                                                                                                          
We do not pursue S2C2F Level 3 controls that require write-capable CI infrastructure — auto-merge dependency bots, hermetic builds inside a runner — or any Level 4 control (rebuilding upstream OSS on our own infrastructure). Those are out of scope by deliberate decision, not omission. The cathedral model and the maintainer-laptop release path exist for the reasons stated at the top of this post; we do not abandon them to chase a higher framework number.   ​

​On the question of a paid third-party audit

We will not be commissioning a paid commercial audit from a tier-1 firm. We do not have that funding, and we are honest about it rather than hiding it.                                 
   
What we are doing instead: applying to OSS-funded audit programmes — OSTIF, OpenSSF Alpha-Omega, the German Sovereign Tech Agency, NLnet Foundation. If accepted, these programmes can fund professional audits or security work at no cost to the project. If rejected, the application itself is documented in SECURITY.md as evidence of due diligence. We may also coordinate with prospective enterprise customers' own AppSec teams under NDA — many large organisations review the code as part of intake regardless, and turning that into formal coordination is free and useful for both sides.    ​

​How this rolls out

​Gradually, one component at a time. SOAR is first, because its privilege scope is broadest and the case for the most thorough posture is strongest. Foundation and the remaining components follow the same pattern, repository by repository. Each gets its own SECURITY.md with the same structure — supported versions, vulnerability reporting channel, SLA, posture statement, signing identities, "am I affected?" guidance — so reviewers find what they expect at the same address in every component.                                 

​We will not announce per-component dates. Each component lands when it lands; the GitHub Security tab on each repository is the source of truth.

​In summary

Open-source code, closed contribution governance, signed releases, hash-pinned dependencies, SBOMs per release, a concrete CVE-response SLA, and explicit alignment with the frameworks enterprise security teams already use to evaluate us. No deploy-path change. No marketing language about "industry-leading" anything — just the substance of what we are doing, and why, in the language that reviewers already know.                                                                                                                                           
                                                            
If your organisation has a FOSS intake process and you would like to discuss this before the per-component SECURITY.md files appear, contact us at [email protected].