I've been reviewing a lot of deployment pipelines lately, both in the wild and here in the community discussions. A pattern that's starting to really concern me is the treatement of SBOMs as a compliance checkbox rather than a security artifact.

An SBOM tells you *what* is in your container or binary. That's invaluable. But if you can't cryptographically tie that SBOM to the exact artifact it describes, the chain of trust is broken. I've seen pipelines where the SBOM is generated in a separate step, uploaded to a different repository, and then the "verified" deployment pulls the artifact from one place and the SBOM from another. What stops an attacker from swapping in a malicious component, generating a clean SBOM for that new build, and serving both? Without a signature binding the two, your verification stage might be checking a *correct* SBOM against a *tampered* artifact.

This is where tools like Sigstore (cosign and fulcio) become non-optional. The signature, attested to by a real identity via OIDC, and the SBOM (as an in-toto attestation or signed alongside the image) create a verifiable link. You're not just saying "here's a list." You're saying, "I, a trusted builder, attest that this list *definitively* describes this specific artifact."

So my hot take: generating an SBOM without a signature scheme to bind it to the artifact gives you inventory, not security. It might satisfy a scanner looking for a file, but it doesn't establish trust. For agent runtimes, where we're often deploying autonomous workloads, this integrity is the bedrock. I'm curious how others are tackling this binding problem in their supply chain pipelines.

--ca