When a serious vulnerability is announced in a widely used library, the first question every defender faces is embarrassingly hard to answer: do we even ship that library, and if so, where? Teams that cannot answer quickly spend the first day of a response grepping through build systems and asking developers to remember what their code depends on. A software bill of materials, or SBOM, exists to turn that frantic archaeology into a lookup. It is an itemized list of the components inside a piece of software — the libraries, their versions, and often their origins — produced at build time and kept alongside the artifact it describes.
An SBOM on its own is just a claim, though. It says “this artifact contains these parts,” but nothing about it forces that claim to be true or ties it to the specific thing you are running. That is where signatures and attestations come in. A signature binds a publisher’s identity to a specific artifact so you can tell who produced it and whether it has been altered. An attestation is a signed statement about the artifact — “this SBOM describes this exact digest,” or “this image was built by this pipeline from this source commit” — so the metadata itself becomes verifiable evidence rather than a text file anyone could have written. Read together, these three turn the supply chain from a matter of trust into a matter of checkable fact.
What each artifact actually proves
It helps to keep the three claims separate, because they answer different questions and fail in different ways. An SBOM answers “what is inside.” Its value is inventory: given a component name and a vulnerable version range, you can ask which of your artifacts match without rebuilding or guessing. A good SBOM lists components at a useful depth, including the transitive dependencies that developers never named directly but that ship anyway, which is exactly where nasty surprises tend to hide.
A signature answers “who made this, and is it unaltered.” It does not say the software is good, only that it came from the identity you expect and has not changed since signing. An attestation answers “is this claim about this specific thing true,” and it is the piece that stitches the others together. An unsigned SBOM sitting in a repository could describe a different build than the one you deployed; a signed attestation that binds the SBOM to a specific content digest removes that gap. The same reasoning underlies Container Image Trust , where the digest is the anchor everything else attaches to. The defensive habit is to always ask what a given artifact does and does not prove, rather than treating “we have an SBOM” as if it settled the question of safety.
Provenance is the part attackers care about
Supply-chain incidents rarely announce themselves as a single obviously-bad file. The unsettling ones involve a legitimate-looking component that was built from tampered source, or published by a compromised account, or slipped in through a dependency nobody reviewed. Provenance attestations exist to make those substitutions visible. When an artifact carries a signed statement describing the source revision it was built from, the builder that produced it, and the steps involved, you gain the ability to ask “was this built the way our other releases are built,” and to notice when the answer is no.
The identity behind the signing matters as much as the signature itself. If a single long-lived key can sign anything, then whoever holds that key inherits all the trust, which is why modern approaches lean toward short-lived, workload-bound identities tied to the build system rather than durable secrets a person keeps. That is the same discipline covered in Service Accounts and Secrets and IAM Roles and Least Privilege : the strength of an attestation is only as good as the control over the identity that produced it.
Toy example
Imagine a fictional design studio, Loomcraft, that publishes a small internal tool and keeps a signed SBOM plus a build-provenance attestation with every release. One afternoon an advisory lands about a serious flaw in a logging library, versions below a certain release. Instead of a fire drill, a Loomcraft defender queries the stored SBOMs and finds that two of eleven active services list the affected library, one at a vulnerable version and one already past it.
The calm write-up stays narrow and evidence-first: “SBOMs for services checkout and mailer list the affected component; checkout pins a vulnerable version, mailer does not; both SBOMs are bound by signed attestation to the digests currently deployed, so the inventory reflects what is actually running.” That single paragraph does what a day of guessing could not. It scopes the problem to one service, confirms the metadata describes the live artifacts rather than some stale build, and turns “are we exposed” into “checkout needs a patched rebuild, mailer needs only a note.” Nothing in the exercise involves attacking anything; the whole value is that the evidence was captured before it was needed.
What evidence matters?
The most useful evidence is an SBOM you can trust to describe the artifact actually deployed, which means an SBOM bound by a signed attestation to a specific content digest rather than a loose file that may describe an older build. Inventory you cannot tie to the running thing tells you what you hoped to ship, not what you shipped. The second kind is the signature and its verifying identity: confirming that the artifact and its attestations were produced by the builder you expect, and have not been modified since. The third is provenance — the source revision and build path — which lets you judge whether the ingredients were reviewed rather than merely present.
Around those, the ordinary records still matter: where the artifact came from, when it was pulled, and which pipeline produced it. As with all evidence work, the strongest notes are timestamped, exported, and tied to a named source rather than reconstructed from memory, the same standard described in Evidence-First Triage and in the record-keeping habits of Logs: What to Keep and Why . If the attestation that binds an SBOM to a digest is missing, that absence is itself a finding: you can still use the SBOM as a hint, but you should say plainly that you cannot yet prove it describes the running artifact.
Common mistakes and false positives
The first common mistake is treating the presence of an SBOM as proof of safety. An SBOM is inventory, not a verdict; a perfectly accurate bill of materials can list a component with a serious vulnerability. Its job is to make that fact findable, not to make it disappear. The mirror-image mistake is trusting an SBOM that no signed attestation ties to the artifact in hand, so it may quietly describe a different build than the one deployed. Confirm the binding before you rely on the contents.
False positives are common on the vulnerability side. An SBOM may list a component whose vulnerable function your code never calls, or a version string that a naive match flags incorrectly, so a raw “affected component present” hit is a prompt to investigate rather than a confirmed exposure. Handle those the way Vulnerability Scan Findings Without Panic recommends: verify that the finding maps to something actually reachable before you escalate. And a valid signature should never be read as a clean bill of health; it proves origin and integrity, not the absence of bugs, and keeping those claims separate is what keeps a supply-chain review credible.
What to do next
Begin by generating SBOMs as part of your build rather than after the fact, and store them next to the artifacts they describe. Bind them with signed attestations to specific content digests so the inventory provably matches what runs, and verify signatures against an expected build identity before trusting either the artifact or its metadata. Capture provenance so a release can be traced back to reviewed source, and keep the SBOMs somewhere queryable so the next advisory becomes a lookup instead of an excavation.
If a supply-chain concern becomes a real incident — a component confirmed reachable and exploitable, or an attestation that will not verify — switch modes. Preserve the artifact, its SBOM, and its attestations as evidence, follow your incident-response plan, communicate through approved channels, and involve qualified responders and legal counsel where warranted. For learning, keep every component and identity fictional and rehearse the calm sequence: find it in the inventory, confirm the inventory is bound to the real artifact, then decide.
How this guide was made
This page is defensive education drawn from public software-supply-chain frameworks and openly published secure-development guidance, illustrated with an invented studio and toy components. It makes no claim to certification, compliance sign-off, legal advice, or incident-response authority, and it avoids exploit detail on purpose so it stays useful for safe study rather than operational misuse.
Official references
For further grounding, the NIST Computer Security Resource Center publishes secure-software-development and supply-chain integrity guidance in depth, and the CISA Secure Cloud Business Applications Project offers secure-configuration baselines for the services that consume these artifacts. The CIS Critical Security Controls v8 place software inventory and integrity in a broader control set, while the CISA Known Exploited Vulnerabilities Catalog shows why fast, accurate inventory matters when a component comes under active exploitation. Treat these as orientation, not certification.
Related guidebooks
The closest companion is Container Image Trust , which shows how digests, signatures, and provenance anchor to the images you deploy. From there, Service Accounts and Secrets explains the non-human identities that sign and publish these artifacts, and Storage Bucket Mistakes extends the same verify-before-you-trust habit to the data your software reads and writes.
