📦 Software Supply Chain Security: SBOMs, Signing, and Knowing What You Ship

When a major vulnerability lands in a widely-used library, the first question every security team scrambles to answer is brutally simple: do we even use it, and where? The teams that can answer in minutes have a software supply chain they can inventory. The teams that spend three days grepping repos do not.

After 25 years of running production systems, I’ve watched supply-chain attacks go from theoretical to routine. Here’s how I make what we ship inventoriable and verifiable — SBOMs, artifact signing, provenance — and how I use AI to turn that data into answers instead of more spreadsheets.

The core idea: trust nothing you can’t verify

Modern software is assembled, not written. A single container image might pull in hundreds of transitive dependencies, a base image you didn’t build, and actions you didn’t audit. Supply-chain security is about making every link in that chain verifiable:

1. Know what’s in your artifacts — generate an SBOM.
2. Prove who built them and how — provenance attestations.
3. Prove they weren’t tampered with — cryptographic signing.
4. Enforce all three at deploy time — admission policy.

Skip any one and the chain has a soft link.

Generate an SBOM for everything you ship

A Software Bill of Materials is exactly what it sounds like: a machine-readable list of every component in an artifact, with versions. Tools like Syft generate them from images and source trees in standard formats (SPDX, CycloneDX).

# Generate a CycloneDX SBOM from a built image
syft myorg/api:1.4.2 -o cyclonedx-json > sbom.json

The payoff comes the day a new CVE drops. Instead of guessing, you query your stored SBOMs:

# Is the vulnerable library anywhere in our fleet?
grep -l "log4j-core@2.14" sboms/*.json

Minutes, not days. Store SBOMs as build artifacts and attach them to your images so they travel with the thing they describe.

Sign your artifacts with Sigstore

An unsigned image is one a registry compromise can swap out from under you. Signing proves an artifact came from your pipeline and hasn’t been altered. Sigstore’s cosign makes this approachable, including keyless signing that ties the signature to an OIDC identity (your CI’s identity) instead of a long-lived private key you have to guard.

# Keyless signing in CI — identity comes from the pipeline's OIDC token
cosign sign --yes \
  myorg/api@sha256:abc123...

# Verify before you trust an image
cosign verify \
  --certificate-identity-regexp "https://github.com/myorg/.*" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  myorg/api@sha256:abc123...

Keyless signing is a big deal: there’s no signing key to leak, rotate, or lose. The signature is bound to the verified identity that produced it, recorded in a public transparency log.

Attest the build, not just the binary

Signing proves what shipped. Provenance attestations (the SLSA framework formalizes this) prove how it was built — which source commit, which builder, which steps. Attach the SBOM and provenance as signed attestations so a verifier can check the whole story:

# Attach an SBOM as a signed attestation to the image
cosign attest --yes \
  --predicate sbom.json \
  --type cyclonedx \
  myorg/api@sha256:abc123...

Now “this image was built from this commit by our pipeline, and here’s exactly what’s in it” is a cryptographically verifiable claim, not a README assertion.

Enforce at deploy time

Generating signatures and SBOMs accomplishes nothing if you deploy unsigned images anyway. Close the loop with an admission controller that rejects anything unsigned or unattested:

# Policy intent: cluster admits only images signed by our CI identity,
# with a valid SBOM attestation. Everything else is denied.

Tools like Kyverno or the Sigstore policy controller enforce this in Kubernetes. This is the step that turns supply-chain security from documentation into a control: an attacker who pushes a malicious image can’t get it scheduled because it isn’t signed by your identity.

Using AI to make supply-chain data actionable

SBOMs and attestations are dense JSON. Their value is locked up until something makes them queryable, and that’s a good fit for AI as an analyst over your own data.

When a CVE drops, I point it at the relevant SBOMs:

“Here are SBOMs for our production services. Tell me which services include the affected package and version range for CVE-XXXX, list the exact version each uses, and whether it falls in the vulnerable range. Don’t infer beyond what’s in the SBOM data.”

For dependency review, I run it over a new SBOM or a lockfile diff:

“Review this dependency manifest. Flag packages that are unmaintained, recently changed ownership, or pulled from unexpected sources, and any version that’s far behind a known-good release. Explain the supply-chain risk of each.”

The model is good at spotting the dependency that quietly changed maintainers or the transitive package nobody chose to include. As always, it analyzes and flags — verification against the official advisory and the actual fix is a human step. Keep these prompts with your other security hardening prompts, and run dependency and policy diffs through our Code Review tool.

Pin and reduce, always

Two habits underpin all of this:

• Pin by digest, not floating tags — for base images, actions, and dependencies. A mutable tag means your verified artifact can change under you.
• Reduce the dependency surface. Every package you don’t include is a supply-chain risk you don’t have. Prefer minimal base images and prune dependencies you no longer use.

The short version

You can’t secure software you can’t inventory. Generate an SBOM for everything you ship and store it so you can answer “do we use this?” in minutes. Sign artifacts with keyless Sigstore so there’s no key to leak and tampering is detectable. Attach SBOM and provenance as signed attestations, then enforce signatures and attestations at deploy time so unsigned artifacts simply can’t run. Use AI to make all that dense data queryable when a CVE lands — verifying findings against the real advisory. Pin by digest, prune what you don’t need, and every link in the chain stays verifiable.

AI-generated supply-chain analysis is assistive, not authoritative. Always confirm CVE applicability against the official advisory and your verified SBOM data before acting.