Where does your software come from? SBOM, SLSA and signing

When we talk about software security, we usually think about our own code. Is it vulnerable? Did we validate input? But most of what we ship isn't our code. It's open-source libraries, base images, build tools, CI actions, and their dependencies, and their dependencies' dependencies.

Attackers have noticed. Instead of breaking into one company, they target something thousands of companies use. The XZ Utils backdoor found in 2024, the hacked GitHub Action in 2025, and the self-spreading npm worm called Shai-Hulud: all examples of supply chain attacks.

Three ideas have become the foundation of defending against them: SBOMs, signing, and SLSA.

Why this suddenly matters

Three reasons:

1. Attacks are increasing, and they're getting more sophisticated.
2. Regulation is arriving. The EU Cyber Resilience Act, US federal requirements and industry standards increasingly expect you to know what's in your software and prove where it came from.
3. Customers are asking. "Can you provide an SBOM?" is now a standard question in security questionnaires.

SBOMs: an ingredient list for software

A Software Bill of Materials (SBOM) is a list of every component in your software: libraries, versions, licenses, and where they came from. Like the ingredient list on food packaging.

Why it helps: when a new vulnerability like Log4Shell is announced, you can answer "are we affected?" in minutes instead of days, by searching your SBOMs.

The two main formats are CycloneDX and SPDX. Generating one is easy:

syft registry.example.com/shop-api:1.4.2 -o cyclonedx-json > sbom.json
trivy image --format spdx-json -o sbom.spdx.json registry.example.com/shop-api:1.4.2

Generate SBOMs in CI for every release, store them alongside the artifact (or attach them to the image in the registry), and scan them regularly for new vulnerabilities.

An SBOM doesn't make your software secure. It makes your ignorance visible, and that's where security starts.

Signing with Sigstore and Cosign

An SBOM tells you what's inside. Signing tells you who built it and that nobody changed it afterwards.

Sigstore is an open-source project (under the OpenSSF) that made signing practical. Its tool Cosign signs container images and other artifacts. The clever part is keyless signing: instead of managing long-lived private keys, your CI's identity (like a GitHub Actions OIDC token) is used to get a short-lived certificate, and the signature is recorded in a public transparency log.

# In CI, with OIDC available
cosign sign registry.example.com/shop-api@sha256:abc123...

# Anywhere, to verify
cosign verify registry.example.com/shop-api@sha256:abc123... \
  --certificate-identity-regexp "https://github.com/acme/shop-api/.*" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

The verification says: this exact image was signed by a workflow in the acme/shop-api repository. If someone pushes a different image under the same tag, verification fails.

Verifying at deploy time is where signing really pays off. Admission controllers like Kyverno, Sigstore policy-controller or Connaisseur can block unsigned or wrongly signed images from running in your Kubernetes cluster.

SLSA levels, simply

SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a framework that describes how trustworthy your build process is. It focuses on provenance: a signed record of how an artifact was built, from which source, by which builder.

Simplified, the build levels are:

• Level 1: provenance exists. You document how the artifact was built.
• Level 2: provenance is generated and signed by a hosted build platform, not by hand.
• Level 3: the build platform is hardened, so builds are isolated and provenance can't be forged even by the project's own maintainers.

GitHub Actions can generate SLSA provenance with artifact attestations (actions/attest-build-provenance), and the slsa-github-generator project provides Level 3 builders. Docker BuildKit can attach provenance to images too.

Putting it together

A practical pipeline:

1. Build the image in CI (hosted, ephemeral runners).
2. Generate an SBOM and attach it to the image.
3. Generate provenance (SLSA attestation).
4. Sign the image with Cosign, keyless.
5. Scan the SBOM for vulnerabilities, continuously.
6. Verify signatures and provenance in the cluster before anything runs.

Each step is a few lines of CI configuration today. A few years ago, this was a research project.

So, where do I start?

Generate SBOMs for your main images this week. Add keyless signing next. Then test signature verification in one non-production cluster. Once that's working, move it to production. You'll be ahead of most companies and ready for the regulations coming your way.

My take: you can't secure what you can't see, and you can't trust what you can't verify. SBOMs give you sight, signatures give you trust.

— Desly