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.
