Your supply chain is a graph, and you only see the first layer
A service declares a dozen dependencies and ships a thousand. Every build tool, base image, CI action and transitive package is code you execute with your privileges, and the practical question is not how to trust all of it but how fast you can answer which parts you have.
TL;DR: The risk is the closure, not the manifest. Three questions decide whether you can act when something is disclosed: what is in this artifact, how was it built, and can I prove this is the artifact I built. SBOM, provenance and signing answer one each, and the value of all three is measured in how long it takes to answer "are we affected".
The graph is bigger than the list
A Node service with fifteen declared dependencies resolves to several hundred packages. A Python image adds the base image's operating system packages, which nobody declared and everyone ships. The build itself pulls a toolchain, a set of CI actions, a package registry and whatever those trust in turn.
Every node in that graph is code that runs with your privileges, either at build time or at runtime. Build time is the more interesting half and the less examined one, because a compromised build step can alter an artifact that passes every test.
Three questions, three artifacts
What is in this? An SBOM, in SPDX or CycloneDX, generated with a declared scope and tied to the artifact digest. Build metadata and analysis of the final image complement each other: include shipped OS packages and check what is deployed. Measure coverage, freshness and time from disclosure to an affected-service list; possession of an SBOM alone guarantees none of them.
How was it built? Provenance, in the shape SLSA describes: an attestation generated by the build system saying which source commit produced this artifact, on which builder, with which inputs. It matters because a signature on an artifact from a compromised pipeline is a signature on a compromised artifact. A verified signature authenticates a signing identity; trusted provenance describes the asserted build process. Neither proves the source or builder harmless.
Is this the artifact I built? Signing, keyless in the Sigstore model so there is no long-lived key to protect, with the signature recorded in a transparency log. Configure admission to verify the artifact digest, expected signer identity and issuer, plus required attestations. A valid signature from an unrelated identity must not pass.
Enforcement is where programmes fail
Every one of those artifacts is inert unless something checks it. The check belongs at admission, as a policy in Kyverno or an OPA equivalent, refusing an image without provenance from a known builder.
The rollout order decides whether it survives. Generate and observe, then warn, then enforce on new workloads, then enforce everywhere. Teams that enforce on day one block every existing deployment, the policy is disabled within the hour, and the programme is set back further than a slow start would have cost. The observe phase also produces the argument for the work, because it usually reveals how many images in production have no provenance at all.
What none of it covers
Scanning finds known vulnerabilities in known components. It does not find a backdoor in a package nobody has reported, a maintainer account takeover, or a dependency that behaves differently when it detects a CI environment. Those need different controls: pinning by digest, vendoring what matters, limiting what a build step can reach, and treating a package's ability to run arbitrary install scripts as the privilege it is.
Being clear about that boundary is what makes the rest credible. A programme sold as making the supply chain safe will be judged against an impossible claim. A programme can instead measure improvements in inventory coverage and response time, and demonstrate which artifacts its admission policy rejects.
The one habit
Pin by digest, never by tag. A tag is a mutable pointer, and every argument in this piece assumes the artifact you verified is the artifact you run. That assumption is free to hold and expensive to discover you did not.
Self-check
An image has a valid signature from an unknown account and an SBOM with only application packages. Is it ready for admission? Not under a policy requiring a trusted builder and complete shipped-component inventory. Validate identity and provenance, and reconcile OS packages in the final image.
Sources: SBOM types, Sigstore verification, SLSA provenance.