SBOM Strategy & Attestation for OSS Projects: A 2026 Best-Practices Guide
| Jason Smith — CEO, ShiftLeftCyber
The open-source ecosystem is facing an unprecedented regulatory and operational shift. Open-source maintainers are now on the hook for the same supply-chain expectations as commercial vendors. Between the enforcement of the EU Cyber Resilience Act (CRA), US FDA premarket guidance, and NIS2, the baseline assumption is that software cannot ship without a maintained Software Bill of Materials (SBOM) and verifiable evidence of how it was built.
For an OSS project, meeting that bar comes down to two things: a clear SBOM strategy (what you produce, in what format, and how) and a resilient attestation model (how consumers can trust what you produced). When a downstream manufacturer has to satisfy global regulations, they push those requirements upstream. If your project ships a high-quality SBOM, you stay in their bill of materials. If it doesn’t, you become the security gap they have to engineer around.
This guide lays out the high-level SBOM framework and practices that hold up to enterprise compliance standards in 2026.
✅ TL;DR: An OSS SBOM & Attestation Checklist
Pick an SBOM Format (CycloneDX or SPDX)
Generate SBOMs in CI Pipelines (On Every Build/Release)
Build the Trust Model (Provenance + Signatures)
Distribute It Where Consumers Will Actually Find It
Enrich with Dynamic VEX Information
Plan for Long-Term Lifecycle and Retention
📄 Step 1: Pick an SBOM Format and Commit To It
The format war is the wrong thing to agonize over. Both major formats (CycloneDX and SPDX) are globally recognized standards, broadly accepted, and rapidly modernizing. Pick one as your canonical output and convert on demand if a consumer needs the other. Completeness and automation matter far more than the format choice.
Feature | CycloneDX | SPDX |
Primary Strength | Application Security, VEX, defined signature standard | License compliance, legal review, ISO level standardization |
Standard | ||
Latest Version | 1.7 | 3.0 |
Common Ecosystem | AppSec & automated supply-chain tooling | Enterprise legal compliance & regulated industries |
Formats Supported | JSON / XML / Protobuf Note: CycloneDX is expected to move to JSON only in the 2.0 version expected to come out later in 2026. | JSON-LD, XML, RDF |
🛠️ Step 2: Generate Your SBOMs Automatically in CI with Every Build
A hand-built or manually created SBOM is stale the moment your dependency tree changes. The only durable practice is to treat the SBOM as a core build artifact.
Automate the Pipeline: Run SBOM generation as a native CI step (GitHub Actions, GitLab CI, etc.) tied to your release tag or commit. If the SBOM generation fails, the build fails.
Generate From the Artifact, Not Just the Manifest: Manifests and lockfiles frequently miss transitive, transient, or build-time components. This is especially true for complex setups like C/C++, where the SBOM must be derived from the actual build process rather than a static package manager.
Strict Versioning Alignment: A release SBOM must be explicitly versioned, tagged, and tracked alongside the exact build version it represents (e.g., v1.4.2-sbom.json matching v1.4.2.tar.gz).
🛡️ Step 3: Build the Trust Model
An SBOM tells consumers what's inside. An attestation tells them they can believe it. This is the critical step most projects skip, and it's exactly what regulators increasingly ask for.
An attestation model for an OSS project has three layers:
Provenance: A statement of how the artifacts and SBOMs were built. The in-toto / SLSA frameworks define this. Many CI systems can emit SLSA provenance natively.
Signing: Sign the SBOM and provenance so tampering is detectable and the signer is verifiable.
Self-attestation: For projects feeding US federal supply chains, the Secure Software Development Attestation Form is the standardized way to assert conformance to secure-development practices.
Together these turn "here's a JSON file" into "here's a signed, verifiable record of what we shipped and how", which is precisely what the CRA, FDA, and NIS2 frameworks are looking for.
📦 Step 4: Distribute It Where Consumers Will Actually Find It
The most common failure isn't generating an SBOM, it's losing it. Attaching a loose JSON file to a GitHub Release page makes it invisible to automated enterprise scanners and security tools. GitHub Releases are where SBOMs go to die.
Better distribution practices:
Attach the signed SBOM directly to the artifact registry (e.g., as an OCI/registry attestation or package metadata) so it travels with the software.
Use a stable, predictable URL or API per release.
Keep historical SBOMs available. Consumers auditing an old version need the SBOM that matches that build.
✨ Step 5: Enrich with Dynamic VEX Information
An SBOM is a static inventory. The ingredients of a specific release will never change. However, vulnerability data is highly dynamic. A component deemed perfectly safe today could have a critical zero-day discovered tomorrow.
Matching a raw SBOM against a vulnerability database can create a flood of false positives. To solve this, complement your strategy with VEX (Vulnerability Exploitability eXchange). VEX lets you state, per vulnerability, whether your product is actually affected, turning the SBOM from a noise generator into a decision tool for the people consuming it.
Establish a Continuous Cadence: Maintain a live, dynamic VEX companion file or endpoint. Run automated daily or per-commit vulnerability scans against active branches, updating your VEX data so consumers can see real, actionable exploitability status rather than raw CVE noise.
🔁 Step 6: Plan for Long-Term Lifecycle and Retention
Generating an SBOM is a point-in-time action, but managing it is a multi-year commitment. Under global frameworks like the EU Cyber Resilience Act (CRA), software manufacturers face a strict 10-year data retention mandate after a product’s lifecycle ends. Your artifacts must transform from temporary pipeline outputs into a permanent compliance archive.
Historical SBOMs must remain stable, predictable, and addressable. If a consumer needs to audit an old version a decade from now, that specific matching SBOM must be retrievable.
How Interlynk helps
Interlynk automates this whole lifecycle for OSS and product teams: generation across ecosystems (including hard cases like C/C++), format conversion, signing and attestation, VEX, and per-release versioning. So the strategy above runs in CI instead of by hand. Start free or book a demo.
Further reading
ShiftLeftCyber, a proud partner of Interlynk, provides their SecureSBOM solution for digital signing and verification of SBOMs. You can explore more insights from ShiftLeftCyber on the ShiftLeftCyber Blog or follow Jason on LinkedIn for regular updates on software supply chain security.