Software Supply Chain Security & SBOMs: A Practical Primer

When Log4Shell broke, the scramble wasn’t about patching your own code. It was about finding every service in your organization that had ever imported Log4j — directly or through a transitive dependency buried three levels deep — and determining its exposure before attackers did. Most organizations couldn’t answer that question in hours. Some couldn’t answer it in days. That gap is what software supply chain security is designed to close.

Why supply chain attacks surged

Modern software is assembled more than it is written. A typical application depends on hundreds of open-source packages, each of which has its own dependency graph. Attackers have understood for years that the weakest link in this chain isn’t usually your own code — it’s the shared infrastructure your code inherits.

The Log4j vulnerability (Log4Shell) illustrated the blast radius problem: a single flaw in a ubiquitous logging library became exploitable across an enormous fraction of the internet’s Java-based infrastructure. More disturbing still was the xz/liblzma backdoor, where a sophisticated, patient attacker spent years cultivating trust as an open-source maintainer before inserting malicious code directly into a widely used compression library. No CVE database entry, no vulnerable API call to spot — just a compromised artifact distributed through normal channels.

These incidents share a structural cause: we consume software we don’t inspect, from build pipelines we don’t control, signed by keys we haven’t verified. Fixing that requires tooling and process, not just vigilance.

What is an SBOM?

A Software Bill of Materials (SBOM) is a machine-readable inventory of every component in a software artifact — libraries, versions, licenses, and provenance. Think of it as a nutritional label for software: when a new vulnerability is disclosed, you check the label rather than excavating the codebase.

When Log4Shell hit, organizations with SBOMs could query their inventory within minutes: “which services contain log4j-core at a vulnerable version?” Organizations without them spent days manually auditing dependencies.

SBOM formats

Two formats have emerged as the dominant standards:

Format	Maintained By	Notes
SPDX (Software Package Data Exchange)	Linux Foundation	ISO/IEC standard; broad adoption in compliance contexts
CycloneDX	OWASP	Security-focused; strong tooling ecosystem; widely used in DevSecOps pipelines

Both formats are JSON- and XML-serializable, both cover component identity and relationships, and both are supported by major package managers and CI tools. CycloneDX has leaned into security use cases — vulnerability linking, annotations for known-exploited components — while SPDX has deeper roots in license compliance. Most organizations pick one and generate it as part of their build pipeline.

SLSA: build integrity and provenance

An SBOM tells you what’s in your artifact. SLSA (Supply-chain Levels for Software Artifacts, pronounced “salsa”) addresses a different question: how was it built, and can you prove it?

SLSA is a framework of security levels, developed by Google and now stewarded by the OpenSSF, that describes the integrity guarantees of a software build:

• SLSA Level 1 — Build process is scripted; provenance is available but not necessarily verified
• SLSA Level 2 — Build uses a hosted build service; provenance is signed by the service
• SLSA Level 3 — Build environment is hardened; provenance is non-falsifiable
• SLSA Level 4 — Two-party review, hermetic and reproducible builds

The key artifact is a provenance attestation: a signed statement that says “this artifact was built from this source, at this commit, by this build system.” When you consume a dependency, you can verify its provenance before using it, rather than trusting that the tarball on the package registry is what it claims to be. The xz backdoor, which compromised the artifact at the distribution stage, is exactly the class of attack SLSA provenance is designed to detect.

Integrating SLSA into your CI/CD pipeline means generating and publishing provenance attestations automatically for every release build — a one-time investment that dramatically raises the bar for any attacker trying to tamper with your artifacts.

Signing and attestation with Sigstore

Sigstore is an open-source project that makes artifact signing practical at scale. Historically, signing releases required key management infrastructure: generate a long-lived key pair, secure the private key, rotate it periodically, distribute the public key somewhere users could find it. Most projects skipped it because the overhead was real.

Sigstore solves this with keyless signing. The core tool, cosign, lets you sign a container image or artifact using short-lived credentials tied to an OIDC identity — your GitHub account, a CI service account, or a Workload Identity token. The signature and a transparency log entry are recorded in Rekor, Sigstore’s public, append-only ledger. Verification checks the signature, the log, and the identity claim — no long-lived private key to manage or compromise.

For Rust-based toolchains and other compiled artifacts, the same approach applies: sign the binary at release time in CI, publish the signature to Rekor, and verify at deployment.

Practical supply chain security checklist

Step	How
Generate an SBOM on every build	syft, cyclonedx-cli, or native package manager tooling
Pin and verify dependencies	Lock files (package-lock.json, Cargo.lock, go.sum); verify checksums
Scan continuously for known CVEs	Integrate grype, Dependabot, or Trivy into CI and run on a schedule
Sign build artifacts	cosign sign in your release workflow; record to Rekor
Demand provenance for dependencies	Verify SLSA provenance attestations before promoting artifacts
Audit maintainer access	Limit who can publish; require MFA; review regularly

The Post-Quantum Cryptography transition is relevant here too: the signing algorithms underpinning today’s artifact signatures will eventually need upgrading, and building provenance infrastructure now means you’re managing a known surface when that migration arrives.

The takeaway

Software supply chain security isn’t about distrusting open source — it’s about consuming it with the same rigor you’d apply to any dependency you didn’t write yourself. SBOMs make your dependency graph visible so you can respond to CVEs in minutes rather than days. SLSA provenance makes your build pipeline auditable so tampering is detectable. Sigstore makes signing cheap enough that there’s no longer a good excuse to skip it.

Start with what delivers the fastest return: generate SBOMs in CI and wire up automated vulnerability scanning. Once that’s running, add signing to your release pipeline. Provenance and deeper SLSA compliance are the next layer. None of these steps require a security team — they’re all composable into the CI/CD workflows you’re already running.