Supply Chain Security: SBOM, Signing and Provenance for Defenders

Modern software is assembled, not written from scratch. A single production service can pull in hundreds of open-source packages, base images, build tools and transitive dependencies, each of which is a trust decision you rarely make consciously. When one of those upstream components is compromised, the damage flows downstream into every organization that consumed it. This is the essence of a software supply chain attack, and incidents such as the SolarWinds intrusion, the event-stream npm hijack and the XZ Utils backdoor showed that defenders can no longer treat the build pipeline as trusted infrastructure. This article looks at three defensive pillars that make the supply chain auditable: the Software Bill of Materials (SBOM), cryptographic signing of artifacts, and verifiable provenance. The framing throughout is understand in order to defend: what these mechanisms are, how they work, what telemetry proves they are effective, and how to harden your pipeline.

What software supply chain security actually means#

Supply chain security is the discipline of ensuring that every component entering your build and every artifact leaving it is known, verified and traceable. The chain spans source code, third-party dependencies, the build system, container base images, CI/CD runners, package registries and the deployment target. Each hop is a trust boundary where an attacker could inject or swap code. Historically defenders focused on the perimeter and on running code, but supply chain attacks move earlier in the lifecycle, where a single malicious commit or poisoned dependency multiplies across thousands of victims. The defensive goal is not to eliminate third-party code, which is impossible, but to make the chain transparent and tamper-evident: you should be able to answer, for any deployed artifact, exactly what is inside it, who built it, from which source, and whether anything changed on the way.

Understanding the SBOM (Software Bill of Materials)#

An SBOM is a formal, machine-readable inventory of every component contained in a piece of software, including versions, licenses, suppliers and dependency relationships. Think of it as the ingredient label for a build. Its defensive value is response speed: when a new critical vulnerability such as Log4Shell is disclosed, an organization with current SBOMs can query its inventory and answer "are we affected, and where?" in minutes rather than weeks of manual auditing. SBOMs are generated at different points, source SBOMs from the repository, build SBOMs from the compilation step, and deployed SBOMs from the running artifact, and the most trustworthy ones are produced by the build system itself rather than reconstructed later. Tools such as Syft, Trivy and the native features of many build systems can emit an SBOM automatically as part of the pipeline, which is the only sustainable approach at scale.

SBOM formats: SPDX and CycloneDX#

Two open standards dominate. SPDX (an ISO/IEC 5962 standard originating in the Linux Foundation) is widely used for license compliance and component inventory. CycloneDX (from OWASP) is designed with security use cases in mind and carries rich vulnerability, dependency and provenance metadata. Both are consumable by automated tooling, and most scanners can read and write either. For defenders the format matters less than the discipline of generating, storing and refreshing SBOMs continuously. An SBOM produced once and never updated is worse than none, because it creates false confidence. Store SBOMs alongside the artifact they describe, version them, and feed them into a vulnerability-matching pipeline so that a newly published CVE is automatically correlated against your existing inventory rather than requiring a fresh scan of production.

Artifact signing and Sigstore#

A signature answers a different question than an SBOM: not "what is inside?" but "is this artifact authentic and unmodified?" Cryptographic signing binds an artifact to a signer using public-key cryptography, so a verifier can detect tampering and confirm origin. Traditional signing with long-lived private keys is operationally painful because the keys must be stored, rotated and protected. Sigstore changed the economics with keyless signing: it issues short-lived certificates tied to an OIDC identity (for example a CI workload identity), records the signing event in a public tamper-evident transparency log called Rekor, and lets verifiers check both the signature and its log entry. cosign is the common tool for signing and verifying container images and other artifacts. The transparency log is the crucial defensive property, because it makes signing events publicly auditable and after-the-fact key abuse detectable.

Provenance and the SLSA framework#

Provenance is verifiable metadata describing how an artifact was built: which source commit, which builder, which parameters and which dependencies. It answers "where did this come from?" with evidence rather than trust. SLSA (Supply-chain Levels for Software Artifacts) is a framework that grades build integrity across increasing levels, from simply having provenance to requiring hardened, isolated, non-falsifiable build processes. At higher levels the provenance is generated by the build platform itself, not by the code being built, so a compromised build script cannot forge its own lineage. Combined with signing, provenance lets a deployment gate reject any artifact that was not built from an approved source by an approved builder. This turns "we trust our pipeline" into "we can prove, cryptographically, that this specific binary came from this specific commit through this specific builder."

Attack surface and threat model#

Understanding the threat model helps prioritize defenses. Attackers target dependency confusion (publishing a malicious internal-looking package to a public registry), typosquatting (a package name one character off a popular one), account takeover of a maintainer, compromise of the build system to inject code at compile time, and tampering with artifacts in transit or at rest in a registry. The XZ Utils case additionally showed a long-game social-engineering path where a malicious actor gains maintainer trust over months. The defensive lesson is that no single control is sufficient: SBOMs address the "what is inside" question, signing addresses "was it tampered", and provenance addresses "where did it come from". Layered together they close the gaps that any one control leaves open, and they convert an opaque pipeline into one where anomalies produce evidence.

Detection: telemetry and signals#

Defensive value depends on detection, so instrument the pipeline. Emit and centrally collect build logs with the source commit, builder identity and resulting artifact digest for every build. Alert when an artifact is deployed whose digest has no matching signature or provenance record, which is the strongest signal of an out-of-band or tampered release. Monitor your registries for unexpected pushes, and watch for new dependencies appearing in an SBOM diff between builds, especially transitive ones added without a corresponding source change. Query the transparency log for signing events attributed to your identities that your CI did not initiate, which can reveal credential abuse. Feed vulnerability scanners with your stored SBOMs on a schedule and on every new CVE publication. In your SIEM, correlate registry pull events, deployment events and signature-verification failures so that a verification failure in production raises an incident rather than being silently ignored by a permissive gate.

Mitigation and hardening#

Harden the pipeline in layers. Pin dependencies to exact versions and cryptographic hashes rather than floating ranges, and use a lockfile that is reviewed on change. Consume dependencies through an internal proxy or artifact repository that caches and scans them, which also mitigates dependency-confusion by giving internal names precedence. Isolate build runners, make them ephemeral, and grant them least-privilege credentials scoped to a single job. Generate SBOMs and provenance automatically in the build, sign every artifact with keyless signing tied to the CI identity, and require verification at the admission gate so unsigned or unverifiable artifacts cannot deploy. Enforce two-person review on build configuration and on dependency additions. Rotate and scope registry credentials, enable branch protection and required reviews on source, and adopt SLSA levels incrementally, starting with provenance generation and moving toward hardened, isolated builds.

Common pitfalls#

The most common failure is generating an SBOM once for a compliance checkbox and never refreshing it, which produces false confidence. Another is signing artifacts but never verifying them at deploy time, so the signature is decorative. A permissive admission gate that logs a verification failure but still allows the deploy defeats the entire control. Teams also frequently trust provenance that is generated by the build script itself rather than by the platform, which a compromised script can forge. Storing SBOMs separately from the artifacts they describe leads to drift and mismatch. Finally, ignoring transitive dependencies, where most real risk lives, leaves the largest part of the attack surface uninstrumented. Each pitfall shares a root cause: treating supply chain security as a document to produce rather than a control to enforce and monitor.

Implementation checklist#

Use this checklist to assess maturity. 1) Every build emits an SBOM (SPDX or CycloneDX) automatically. 2) SBOMs are stored with the artifact and refreshed on every build. 3) A vulnerability-matching job runs SBOMs against new CVEs continuously. 4) Every artifact is signed, preferably keyless via Sigstore, tied to the CI identity. 5) Deployment admission verifies signatures and rejects unverifiable artifacts. 6) Provenance is generated by the build platform and checked at the gate. 7) Dependencies are pinned by hash and consumed through an internal proxy. 8) Build runners are ephemeral, isolated and least-privilege. 9) The transparency log is monitored for signing events your CI did not initiate. 10) Verification failures in production raise incidents. Working through these moves an organization from opaque trust to provable integrity.

Frequently asked questions#

Does an SBOM by itself make software secure? No. An SBOM is an inventory; it improves visibility and response speed but does not prevent compromise. It must be paired with signing, provenance and an enforcing admission gate to deliver security value. Is keyless signing safe if there is no long-lived key to steal? Keyless signing shifts trust to the OIDC identity provider and the transparency log rather than a stored key, which reduces key-management risk, but the identity itself must be protected and the transparency log monitored. It is a strong improvement, not a silver bullet, and its value comes from verifying signatures and auditing the log, not merely from producing signatures.

Conclusion#

Software supply chain security is fundamentally about replacing implicit trust with verifiable evidence. SBOMs tell you what is inside an artifact, signing tells you it has not been tampered with, and provenance tells you where it truly came from. Individually each answers one question; together they turn an opaque pipeline into a tamper-evident, auditable system where anomalies leave forensic traces. The defender's job is not to produce these artifacts as compliance paperwork but to enforce them at admission and monitor the resulting telemetry, so that an unsigned deploy, a forged provenance or a suspicious signing event becomes an incident rather than a silent success. Start by generating SBOMs and provenance automatically, add signing tied to your CI identity, and make verification a hard gate. Each step converts a leap of faith in your pipeline into something you can prove.