A verifiable software supply chain is not built from a single control but from three mechanisms working in sequence: a software bill of materials (SBOM) that documents what is inside the artifact, cryptographic signing that proves the artifact has not been altered, and build attestation that records how and where the artifact was produced. Each answers a different question—what, whether, and how—and a CI/CD pipeline that integrates all three creates a chain of custody that can be checked independently at deployment time.
Understanding the Software Supply Chain and Its Threats
No piece of software is developed in isolation. The OWASP Cheat Sheet Series, citing NIST's definition, describes a software supply chain as "a collection of steps that create, transform, and assess the quality and policy conformance of software artifacts," spanning the entire development lifecycle and the wide range of components and tools used along the way. From a developer's perspective, that means every stage—source, build, packaging, and deployment—is part of the attack surface.
The threat landscape matches that breadth. OWASP's guidance on supply chain security lists dependency confusion, compromise of an upstream provider's infrastructure, theft of code signing certificates, and CI/CD system exploits among the threats developers should understand. The U.S. Cybersecurity and Infrastructure Security Agency, in its developer guidance from the Emergency Services Sector, warns that rather than waiting for public vulnerability disclosures, threat actors "proactively inject malicious code into products that are then legitimately distributed downstream through the global supply chain," and that these next-generation compromises have significantly increased in both open source and commercial software.
That last point is the architectural driver for this article: malicious code can enter through a compromised dependency, a tampered artifact, or an exploited build system, so controls must be distributed across the pipeline rather than concentrated at one checkpoint.
Key Security Mechanisms: SBOMs, Code Signing, and Build Attestation
Each mechanism addresses a distinct gap. An SBOM provides transparency: it documents all of the components in the final product being packaged for delivery, including first-party, third-party, open source, and commercial parts. JFrog's supply chain guidance notes that for open source projects this means knowing what is in your source code and container images, so that when a vulnerability surfaces you can quickly determine where it occurs in your architecture, which container image introduced it, and which team maintains that package. Demand for SBOMs is increasingly external as well: CircleCI's Jacob Schmitt reports that risk-averse businesses and governments request them, with vendors working with the U.S. federal government required to provide one, and the European Union's Cyber Resilience Act requiring software makers to create and maintain SBOMs in a standardized, machine-readable format.
Code signing provides integrity and authenticity. CISA's developer guidance states that software distributed as an artifact to a customer should be delivered with a unique cryptographic signature that verifies the integrity of the artifact, and recommends that all released software meet company-wide cryptographic standards. A valid signature tells the consumer the artifact has not been modified and originates from the holder of the signing key—which is why OWASP flags signing certificate theft as a threat in its own right.
Build attestation provides process integrity. It produces a verifiable record of the build itself, covering the source code, build environment, and dependencies used. CircleCI's guidance connects this to SLSA provenance: CI/CD platforms that generate and verify SLSA provenance metadata make it harder for attackers to inject malicious code during the build process. Where a signature proves an artifact is unchanged, an attestation proves the artifact came from a build that behaved as expected.
Secure Software Supply Chain Workflow Model
The model below maps each mechanism to a stage of the build and deployment pipeline, showing where security artifacts are generated and where they are verified. The sequence matters: each artifact builds on the one before it, so that by deployment a consumer can check the whole chain rather than any single link.
| Pipeline stage | Security artifact generated | Verification at or after this stage | Threat addressed |
|---|---|---|---|
| Source control | Signed commits | Commit signatures checked before code enters the build | Unauthorized or injected source changes |
| CI/build environment | Build attestation / SLSA provenance recording source, environment, and dependencies | Provenance metadata verified against expected build parameters | Malicious code injection during the build process; CI/CD exploits |
| Artifact generation and packaging | SBOM documenting all components in the final package | SBOM checked against vulnerability data on an ongoing basis | Compromised or vulnerable dependencies |
| Artifact registry | Cryptographic signature applied to the artifact before storage or distribution | Signature verified when the artifact is pulled from the registry | Artifact tampering in transit or storage |
| Deployment | Verification step consuming all prior artifacts | Signature, attestation, and SBOM checked together before release | Deployment of tampered or unverified software |
Reading the table as a sequence: a developer signs commits at the source stage; the build system generates an attestation capturing how the artifact was produced; the packaging step produces the SBOM describing its contents; the finished artifact is signed before it is stored in a registry or deployed; and the deployment stage verifies the signature, the attestation, and the SBOM together. The evidence supports placing SBOM generation during artifact generation or packaging and signing before registry storage or deployment, though it does not pin down the exact ordering of SBOM generation relative to compilation and final signing—teams should treat that ordering as a design decision consistent with those boundaries.
Mitigating Threats Through Integrated Controls
The value of running all three mechanisms together is that each covers a failure mode the others cannot. Consider the threats named in the evidence against the controls:
- Malicious code injection during the build: build attestations and SLSA provenance verification make it harder for attackers to inject code mid-build, because the recorded provenance will not match a build that deviated from expected sources and environment.
- Artifact tampering in transit or storage: cryptographic signatures detect any modification after signing, since the signature verification fails on altered bytes. CISA's guidance ties this directly to delivery: distributed artifacts should carry a unique signature verifying their integrity.
- Compromised or vulnerable dependencies: SBOMs expose the full component inventory, enabling identification of affected packages when a vulnerability is disclosed and ongoing scanning as part of the build process—CISA's guidance references automated code scanning within the build as part of ongoing vulnerability identification.
- Signing infrastructure compromise: OWASP lists code signing certificate theft as a distinct threat, which is why CISA recommends company-wide cryptographic standards for all released software rather than ad hoc signing practices.
No single control covers all four cases. A signed artifact built from a poisoned dependency passes signature verification; an SBOM cannot tell you whether the artifact was rebuilt after packaging. Only the integrated workflow closes the loop.
Achieving Verifiable Software Delivery
The architectural decision for a security architect is to implement an integrated security workflow that incorporates SBOM generation, code signing, and build attestations throughout the CI/CD pipeline, rather than adopting any one mechanism in isolation. The reasoning is cumulative: the SBOM establishes what the software contains, the signature establishes that it is unchanged, and the attestation establishes that it was built the way it was supposed to be. Together they form a chain of custody that a consumer or downstream automated gate can verify without trusting the producer's word.
The measurable indicator of success is concrete: successful verification of artifact signatures and build attestations at deployment, coupled with up-to-date SBOMs for all deployed software. A pipeline that can demonstrate that combination—every deployed artifact passing signature and attestation checks, with a current component inventory behind it—has achieved verifiable software delivery. Where that verification fails, the failure localizes the problem: a bad signature points to post-build tampering, a failed attestation points to the build environment, and an SBOM match against a new vulnerability disclosure points to a dependency to replace.
