01 / Field notes
Executive Summary
An SBOM is an inventory. Build provenance is evidence about how an artifact was produced. A digest identifies bytes. These are complementary tools, and confusing them creates a dangerous shortcut: accepting a release because it comes with a convincing collection of documents.
The acceptance question is narrower: do these documents describe the exact artifact we intend to deploy, and was it produced through a process we permit? A valid signature does not answer every part of that question. A complete-looking component list does not establish that a build runner or dependency was trustworthy.
Use this guide when reviewing a vendor release, an internal application or a deployment pipeline. It provides an original acceptance worksheet, not a certification scheme or a claim that any named product is vulnerable.
02 / Field notes
Prerequisites / Lab Setup
Choose a non-production release candidate and preserve its original download location, release identifier and artifact digest. Obtain the vendor's published SBOM and provenance through documented channels. Record the expected publisher identity, approved builder and verification tool version before examining the evidence; letting the artifact choose its own trust anchor defeats the review.
Work in a restricted staging environment. Do not execute an unknown binary just to discover its version. Do not upload proprietary artifacts to public analysis services without authorization. If your supplier does not provide one of the evidence types, record the gap honestly rather than generating a document that appears supplier-issued.
03 / Field notes
Technical Analysis
Read each document for its actual purpose
NTIA's 2021 minimum-elements report establishes a useful historical baseline for component information and related SBOM practices. It is not proof that every inventory contains every runtime dependency. SLSA v1.2 defines provenance describing a build and its output, including information that a verifier can evaluate against policy. NIST's SSDF places such evidence within a broader development process. [1][2][3]
| Evidence | Useful question | Question it cannot settle alone |
|---|---|---|
| SBOM | Which components does the supplier declare? | Is this application free of exploitable flaws? |
| Artifact digest | Are these the same bytes as the referenced output? | Were those bytes produced honestly? |
| Provenance | Which build process produced this subject? | Is that builder acceptable to us? |
| Signature or attestation verification | Was this statement authenticated under the checked trust policy? | Should our policy authorize deployment? |
This distinction matters when a build and a deployment disagree. Suppose a fictional supplier publishes release 4.2 with an SBOM for its server package, while your team downloads a separately assembled container. Even if both carry the same product name, the scope may differ. Ask for evidence covering the container and its base image rather than assuming that the server document covers the assembled deployment.
Bind the evidence to the candidate
Start with the candidate artifact's digest. Check that the provenance subject identifies that digest, not merely a mutable tag such as “stable.” Confirm the expected project and approved build identity. Review the builder and build definition against your acceptance policy. Preserve the verification result and policy version alongside the release decision.
Next, examine SBOM scope: operating-system packages, language dependencies, bundled libraries and optional modules may be represented differently. A component missing from one inventory is a question to investigate, not immediate proof of deception. Ask how the inventory was generated and which parts are excluded.
An artifact can pass cryptographic verification and still fail policy. For instance, a test builder may be correctly authenticated but prohibited from producing production releases. Likewise, an approved builder can produce a release containing a dependency your organization has decided to retire. Verification establishes evidence; policy determines acceptance.
Keep a useful exception path
Small suppliers may lack mature provenance tooling. Define a time-bounded exception that records the missing evidence, business need, staging checks and accountable approver. Do not quietly label the release “verified” with a green badge. If the exception becomes permanent, review whether the residual risk and supplier relationship are still acceptable.
The forward-looking opportunity is consistent evidence evaluation across repositories, package registries and deployment systems. More attestations will not help if teams never inspect their subjects or identities. Prefer a small number of enforced checks with a clear failure reason over a pipeline that collects documents and always deploys.
04 / Field notes
Mitigation / Defense
- Identify the exact artifact, expected publisher and approved builder before running verification.
- Reject mismatched digests and unexplained provenance subjects; investigate missing evidence separately from failed evidence.
- Compare the SBOM's declared scope with the deployed package, container and optional components.
- Save the policy version, decision, exception expiry and rollback candidate with the release record.
- Reassess deployed components when new vulnerability information appears; a successful release review is not permanent immunity.
In a tabletop exercise, substitute an old SBOM for a new candidate and confirm that the reviewer notices the mismatch. Use only your own harmless test artifacts. The goal is to expose a workflow gap without introducing malicious dependencies. For the next stage, see KEV and EPSS prioritization and model artifact security.
05 / Field notes
References
Checked 28 October 2026. The NTIA document is identified by its 2021 publication date; SLSA references version 1.2. The fictional release and acceptance tests are editorial examples. These documents support evidence collection, not a blanket warranty of software safety or a substitute for application testing.
- The minimum elements for a software bill of materials ↗NTIA · accessed 2026-10-28
- SLSA v1.2 build provenance ↗SLSA · accessed 2026-10-28
- Secure Software Development Framework, SP 800-218 ↗NIST · accessed 2026-10-28
Questions readers ask
Does an SBOM prove that software is safe?
No. It describes components within its scope. It does not prove secure behavior, complete vulnerability coverage or that the deployed artifact matches the document.
Is signed provenance enough to trust a release?
No. Verify the signature against an approved identity, check the artifact digest and builder, and apply your own release policy. A valid statement can describe an unacceptable build.
About this edition: Articles include AI-assisted drafting and editing. Conceptual illustrations are not evidence of a real incident or product test. Read our sourcing and review standards.
Research improves with scrutiny. Send a correction with the article URL and supporting evidence.
Contact the editorial desk ↗
