SBOMs and the Evidence Gap in Software Supply-Chain Security

TL;DR

An SBOM tells teams what software components are present. It does not prove how the artifact was built or whether the declared inventory is complete. That requires provenance, verification, and an operational policy. The article covers the Netics position, the operational boundary, and the implementation checklist. The TL;DR also covers the operational boundary and the Netics position.

An SBOM answers a composition question

CISA defines an SBOM as a formal record of software components and their relationships. That visibility helps teams correlate dependencies with vulnerability databases and advisories. It is valuable inventory, not a safety certificate.

Provenance answers a production question

The SLSA specification [1] addresses increasing guarantees about how software artifacts are produced. A strong control plane joins the SBOM to the source revision, builder, artifact digest, and verification policy.

The operational boundary

CISA’s SBOM guidance [2] distinguishes transparency from risk decisions. The SBOM can answer whether a component is present. Provenance can answer which process produced the artifact. VEX can help answer whether the product is actually affected.

The Netics position

Generate the SBOM during the build, attest the artifact and provenance, retain the build context, and verify the chain before deployment. Procurement should ask how the SBOM maps to the delivered digest, not merely whether a document exists.

For the international guidance, consult the joint CISA SBOM guidance [3].

For an architecture review, visit Netics or book a free audit.

CycloneDX and SPDX are not interchangeable

The two dominant SBOM formats encode different things well. CycloneDX, maintained by OWASP, was built with a security and vulnerability-management focus and has first-class support for describing vulnerabilities, licenses, and component relationships in machine-readable form. SPDX, an ISO/IEC 5962:2021 standard, originated in license-compliance tracking and has broader adoption in regulatory contexts, including U.S. federal guidance. A team that standardizes on one format without checking what its downstream consumers actually expect — a customer’s procurement tooling, a regulator, an internal vulnerability scanner — can produce a technically valid SBOM that nobody downstream can actually ingest.

Verification needs tooling, not just a specification

SLSA describes what a strong provenance chain should guarantee; it does not ship the tooling to produce or verify one. In practice that verification layer is built from in-toto attestations (a standard for signed, structured statements about how an artifact was built) and Sigstore’s cosign for signing and verifying container images and SBOMs without teams having to run their own key-management infrastructure. A provenance policy that names SLSA levels but has no cosign-verified attestation gate in the deployment pipeline is a documented intention, not an enforced one — the artifact still deploys if the attestation is missing, unless the pipeline is explicitly configured to block on it.

VEX closes a loop an SBOM alone cannot

An SBOM listing a vulnerable component does not mean the running application is actually exploitable — the vulnerable code path may be unreachable, or the component may be a dev-only dependency never shipped. A Vulnerability Exploitability eXchange (VEX) statement records that judgment explicitly: affected, not affected, or under investigation, with a stated reason. Without VEX, every SBOM-flagged component reads as equally urgent, which trains reviewers to ignore the alerts entirely rather than triage them.

Questions for a production review

Ask who owns the inventory, where the artifact digest is recorded, how provenance is verified, and what happens when evidence is missing. Reviewers should be able to follow one release from source revision to deployed digest. That trace is also useful during incident response: it narrows the affected versions and shows which policy decision admitted them. Procurement, engineering, and security should agree on the minimum evidence before a supplier is marked compliant. Evidence should expire when the build process changes, so a historical attestation is not treated as a permanent guarantee.

Decision criteria for leaders

Use the evidence requirement as a design input for the delivery process. If a team cannot bind its inventory to the delivered digest, first fix that traceability gap before adding more scanners. If provenance exists but cannot be verified by the deployment boundary, fix key ownership, trust configuration, or retention. If verification passes but a vulnerability decision remains unclear, record the exception and its owner. This sequence prevents tools from producing a false sense of closure. The goal is not a perfect document; it is a repeatable explanation of what was built, what is running, and why the release was admitted.

Operating questions

A good implementation must be observable by more than one team. Ask what data is produced, where it is retained, who can change it, and what event triggers a fresh verification. Assign an owner for policy and an owner for operations. Record exceptions with an expiry date, a responsible person, and a reason. Define a recovery path as well: when a control fails, the team should be able to pause, correct, and resume without losing history. This discipline turns a security recommendation into a repeatable procedure. It reduces implicit decisions, makes audits easier, and gives operators a clear signal when the system leaves its documented assumptions.

Handoff notes

Keep decisions and evidence with the relevant release or task. During review, compare the observed result with the declared policy, then improve the procedure instead of hiding the gap. The loop should remain short, understandable, and reusable by the next team. It also provides a concrete starting point for quarterly tests and provider changes.

Sources

1. The SLSA specification
2. CISA’s SBOM guidance
3. the joint CISA SBOM guidance