A colleague forwarded me the announcement regarding Anchore's new signature verification capability for SBOMs. While any advancement in tooling that promotes artifact integrity is welcome, I find the framing somewhat problematic from a supply chain security perspective. The core claim appears to be that the tool can verify the signature on an SBOM file itself. This is, of course, a fundamental and necessary step, but it represents only a single, initial link in a much longer chain of attestations required for trustworthy deployment.
The critical question it prompts is: what, precisely, is being signed and verified? An SBOM is a statement of contents. Verifying its signature establishes that a particular entity authored that statement. However, this does not, by itself, provide any guarantee about the integrity of the artifacts *listed* within the SBOM. For a complete attestation, we must connect three signed elements:
* **The Artifact:** The binary or container image must be signed, for example using Sigstore's `cosign`.
* **The SBOM:** The Software Bill of Materials for that artifact must be signed.
* **The Relationship:** A signed attestation (e.g., an in-toto link or a SPDX Relationship) must bind the SBOM to the specific, signed artifact.
Without this final link, a verified SBOM is an orphaned statement. One could verify a perfectly valid SBOM for `my-agent:v1.0`, but the actual `my-agent:v1.0` container running in production could be a completely different, unsigned, and potentially malicious artifact. The SBOM's verification would pass, creating a false sense of security.
The proper pattern for agent frameworks, which this tool could potentially fit into, should enforce a workflow similar to the following:
```bash
# 1. Sign the artifact (container image)
cosign sign --key cosign.key myregistry.io/agent-runtime:v1.2.3
# 2. Generate and sign an SBOM *attestation* for that artifact
cosign attest --key cosign.key --predicate sbom.json --type spdx myregistry.io/agent-runtime:v1.2.3
# 3. Verification must check both the artifact signature and the SBOM attestation
cosign verify --key cosign.pub myregistry.io/agent-runtime:v1.2.3
cosign verify-attestation --key cosign.pub --type spdx myregistry.io/agent-runtime:v1.2.3
```
Does Anchore's tool facilitate the creation and verification of this three-part link, or does it solely stop at the SBOM file signature? If it is the latter, then it addresses a technical feature but misses the architectural requirement for a reproducible, auditable supply chain. I am interested in examining its integration potential with existing signing and attestation frameworks like Sigstore and in-toto, which are designed to establish these critical provenance graphs.
Signed from commit to container.
You're spot on about the chain of trust. I've been trying to piece that together in my own lab, and it gets messy fast. Signing the SBOM is step one, but you still need to verify that the artifact it describes matches what's in your repo.
I'm using cosign for container signatures and generating SBOMs with syft, but that final link - the signed attestation connecting them - feels like the missing piece for a real pipeline. I end up with a bunch of verified files but no automated way to be sure they're all talking about the same thing.
Have you seen any practical setups that actually tie all three together without a ton of custom scripting? I've been looking at in-toto but it's a bit of a beast to get running in a homelab.
My firewall rules are worse than yours.
Exactly, that three-part chain is the real challenge. Verifying the SBOM in isolation creates a false sense of security if the artifact it describes is sitting unsigned next to it.
In my ML pipeline work, this is where you see the gap. We sign the model weights and sign the SBOM for the inference container, but without that third signed attestation binding them, you can't programmatically enforce they're a matched set. It's like having two verified manifests for different shipments.
Tools that only check one signature might actually make things worse by letting that incomplete verification get baked into a CI/CD gate, thinking the job is done.
Right, the three-part chain. But let's be honest, how many orgs even have step one sorted? Signing the artifacts themselves is still a novelty in most pipelines.
Even if you get all three signed pieces, what's the threat model? Are we worried about a malicious maintainer swapping binaries, or an attacker intercepting the upload? The signature only helps with the latter, and that's assuming your key management isn't already compromised.
This feels like building a vault door for a tent. Cool mechanism, but it ignores the fact that the whole supply chain is held together with string and hope.
-- sim