Most security teams have a Software Bill of Materials (SBOM) today. But a list of software components is only half the story. It tells you what is inside your software yet says nothing about how that software was built or whether anyone tampered with it between your source repository and the production server.
Proving build integrity, not just cataloguing components, is the gap that build provenance and artifact signing are designed to close. In short, build provenance is a signed, verifiable record of how, where, and from what source a software artifact was built, and artifact signing is the cryptographic seal that makes that record tamper-evident.
This blog explains what build provenance really means, how the Supply-chain Levels for Software Artifacts (SLSA) framework levels work in practice, and how artifact signing fits into a CI/CD pipeline.
Why SBOMs Alone Are No Longer Enough
A SBOM is essentially a parts list. It tells you which libraries, packages, and dependencies are bundled inside your software. That is useful for tracking known vulnerabilities and managing license obligations. But it says nothing about the integrity of your build process itself.
Attackers have understood this limitation for years. In the SolarWinds SUNBURST breach, all the software components in the affected build were legitimate. The attacker had compromised the build pipeline and injected malicious code into the compiled output. An SBOM would have listed clean, trusted components. It would not have detected the compromise because the attack happened inside the build, not inside a dependency.
More recent incidents follow the same pattern. The 2024 XZ Utils backdoor (CVE-2024-3094) and the 2025 Shai-Hulud npm worm both slipped past component-level checks. The Shai-Hulud worm did so by compromising trusted package publishing and CI/CD workflows. In each case, the build or release path itself was subverted, not a listed dependency.
This is why regulators, enterprise security teams, and DevSecOps engineers are now asking for something more specific. They want cryptographic, tamper-evident proof that an artifact was built from a known source, using a defined process, on a verified build system. That proof is called build provenance.
NIST SP 800-204D, published in February 2024, addresses this directly. It emphasizes cryptographically signed attestations as a foundational mechanism for establishing software integrity and provenance throughout CI/CD pipelines. The publication also explains that SBOMs alone cannot be used for vulnerability management because they provide a component inventory rather than cryptographic evidence of how software was built or whether the build process was trustworthy.
That cryptographic evidence is exactly what build provenance provides. The practical question, then, is what it records, and how that record is structured.
What Is Build Provenance?
Build provenance is a verifiable record that is typically cryptographically signed and answers four questions about a software artifact.
- What: The exact artifact, identified by a cryptographic hash (SHA-256 digest).
- Where: The source repository and the specific commit that produced it.
- When: The time at which the build was performed.
- How: The build system, workflow definition, runner environment, and inputs used.
Together, these details create a traceable, verifiable chain of custody from code commit to deployable artifact. When an incident occurs, you can trace backward through provenance records. When something looks suspicious at a deployment gate, you can verify the claim cryptographically rather than relying on a developer assertion or a CI log that anyone with pipeline access could alter.
Provenance is expressed using the in-toto attestation framework. An in-toto attestation is a signed document that binds metadata to an artifact. It has three parts: the statement type (what kind of claim this is), the subject (the artifact, identified by its digest), and the predicate (the actual metadata, such as the repository, workflow, build inputs, and builder identity). SLSA Build Provenance is a standardized provenance predicate carried within an in-toto attestation statement.
Defining provenance is one thing; setting a measurable bar for how trustworthy it must be is the job of the SLSA framework.
SLSA: A Framework for Build Integrity
SLSA is an open framework maintained by the Open Source Security Foundation ( OpenSSF ) that defines increasingly strict requirements for how software should be built and how provenance should be generated and protected. The current stable release is SLSA v1.2 (November 2025), which adds a Source Track to the existing Build Track; the Build Track defines three distinct levels of increasing security.
SLSA Level 1: Provenance Exists
The build process generates a provenance document describing how the artifact was produced. This document is distributed alongside the artifact. At Level 1, the provenance is not cryptographically signed. Anyone who can modify the build script can also modify the provenance. Level 1 is a starting point that improves traceability and helps with incident response, but it does not prevent a determined attacker from forging claims.
SLSA Level 2: Signed by the Build Platform
Provenance must be generated and signed by the build platform itself, not by a user-controlled build script. The signing key is held by the platform and is not accessible to the build steps. This distinction is critical. If an attacker compromises a build script at Level 2, they cannot forge a valid provenance document because they do not have access to the platform’s signing key. Level 2 is the practical target for most teams. It is achievable on GitHub Actions or GitLab CI with a small amount of pipeline configuration.
SLSA Level 3: Hardened and Isolated Build Environment
The build environment is hardened so that the signing key and secret material are never accessible to the user-defined build steps, even if those steps are fully compromised. The build platform enforces isolation at the infrastructure level. Level 3 is the appropriate target for critical components, software shipped into regulated environments, and anything with a high-consequence attack surface.
A simple way to think about it: Level 1 is a receipt. Level 2 is a receipt with an official platform stamp that the developer could not have printed themselves. Level 3 is a receipt produced inside a locked room where the operator had no access to the stamping mechanism.
There is also a fourth level: covering hermetic, fully reproducible builds with two-party review. It exists in the original SLSA draft and is planned for a future release, but it is not part of the current v1.2 specification, so Level 3 is the highest level you can certify against today.
With the levels clear, the next step is seeing how provenance and signing flow through a working CI/CD pipeline.
How the Full Workflow Comes Together in CI/CD
Here is how build provenance and signing flow through a typical CI/CD pipeline from commit to deployment.
- It starts when a developer pushes code to a branch, and that push event triggers the CI pipeline.
- The build then runs, compiling or packaging the source code, with dependencies resolved from pinned digest-based versions rather than mutable tags.
- Provenance is generated by the platform itself, not the build script, which produces an in-toto attestation capturing the source commit, workflow identity, runner environment, and the SHA-256 digest of the output artifact.
- In a keyless signing implementation, the attestation is signed by a service that issues a short-lived certificate tied to the build platform’s OIDC (OpenID Connect) identity, uses it to sign the attestation, and records the signing event in a public, tamper-evident transparency log. Because the certificate is short-lived, there are no long-lived private keys to store, rotate, or revoke.
- The signed attestation is then stored alongside the artifact in a container registry or artifact repository, in a transparency log, or in both.
- Finally, verification runs at the deployment gate. Before an artifact is promoted to staging or production, a policy check verifies the signature, confirms the attestation came from the expected repository and workflow. It also checks that the artifact digest matches the provenance record. Artifacts that fail verification are rejected automatically.
GitLab CI has built-in provenance support. Verification can be done using the GitHub CLI, a signature-verification tool, or a Kubernetes admission controller that enforces policy on every pod deployment.
Wiring this into a single pipeline is straightforward; rolling it out across an entire organization takes a more deliberate approach.
Enterprise Implementation Considerations
Start with Critical Artifacts, Not Everything
Not every artifact in a large organization needs SLSA Level 3 from day one. Begin by identifying which software components are customer-facing, shipped into regulated environments, or part of critical infrastructure. Apply SLSA Level 2 to those first, establish the verification gates that enforce it, and then roll out more broadly. This staged approach keeps the effort manageable while delivering compliance value quickly.
Verification Matters as Much as Signing
Many teams implement signing and assume the work is done. Provenance only delivers real security value when it is actively verified at the point of deployment. Add a verification step to every deployment pipeline. Configure your Kubernetes admission controller or deployment gate to reject artifacts that lack a valid, policy-compliant attestation. An artifact whose provenance does not match the expected source repository, branch, or workflow identity should never reach production.
Pin Dependencies to Digests
Build provenance accurately describes the inputs to your build only if those inputs are stable. If your pipeline resolves dependencies dynamically from mutable version tags, a malicious update to a public registry package can change what ends up in your artifact without any change to your source code. Pin dependencies to specific SHA-256 digests rather than version tags. This is what makes your builds reproducible and your provenance meaningful.
Long-Lived Signatures Require Timestamps
Short-lived signing certificates are well suited for build-time signing where verification happens shortly after signing. If you need to verify release artifacts years after they were signed, short-lived certificates alone are not sufficient because the certificate will have expired long before verification. In those cases, you also need an RFC 3161 timestamp from a trusted Timestamp Authority, which binds the signature to a point in time that can be verified independently of certificate validity. For the highest assurance, anchor your signing keys in an HSM (hardware security module) to prevent key extraction and ensure the physical security of your signing infrastructure.
Even teams that follow these practices closely can still stumble, so it is worth calling out the mistakes that most often undermine build provenance in practice.
Where Provenance Goes Wrong
- Generating provenance inside the build script: If the build script controls the provenance generator, an attacker who compromises the script can falsify what the provenance claims. Provenance must be generated by the build platform, outside the user-controlled steps. This boundary is what separates SLSA Level 2 from Level 1.
- Signing without verification gates: Producing signed attestations without enforcing them at deployment creates a false sense of security. Every path to production must include a verification step that rejects non-compliant artifacts.
- Using long-lived keys without HSM protection or rotation plans: A compromised signing key invalidates your entire trust chain. Static, software-stored keys must be protected by HSMs and supported by documented rotation and revocation procedures.
- Treating provenance as a documentation exercise: Provenance provides value only when it drives access control and incident response decisions. If your verification policy is not enforced automatically, it offers compliance theater, not actual security.
- Ignoring third-party dependency provenance: Your first-party source code may be clean, but your third-party dependencies may not be clean. When an upstream package publishes SLSA provenance, verify it. And when it does not, assess whether that gap is an acceptable risk given the component’s role in your software.
Avoiding these pitfalls is the difference between a provenance program that genuinely reduces risk and one that exists only on paper.
Getting these details right consistently is where specialist guidance pays off, especially as the cryptography underneath build security begins to shift.
How Encryption Consulting Can Help
CodeSign Secure is Encryption Consulting’s enterprise-class code signing management platform, designed to provide the infrastructure controls that industries need.
HSM-Backed Key Management
CodeSign Secure stores all private signing keys inside FIPS 140-2 Level 3 certified Hardware Security Modules, integrating with Thales Luna, Entrust nCipher, Utimaco, Securosys, and cloud HSMs from AWS and Azure. Per-product key isolation is enforced at the HSM partition level: each product line receives its own dedicated key, generated inside hardware and never exported.
M-of-N Signing Quorum and RBAC
The platform’s Role-Based Access Control model enforces M-of-N approval requirements for production firmware signing. No single individual can initiate and approve a signing operation. Signing requests, approvals, and rejections are all logged. The RBAC configuration itself is auditable and version-controlled, providing the documented signing policy that CRA conformity assessments require.
Immutable Audit Logging
Every signing event in CodeSign Secure generates an immutable log entry capturing the artifact hash, the key identifier, the certificate used, the approving identity, and the RFC 3161 timestamp. Logs are centralized, separately stored from the signing infrastructure.
Cross-Platform Firmware Format Support
CodeSign Secure supports signing of firmware artifacts across the full range of formats that a diverse product portfolio requires: .bin, .img, .hex, .fw, .dfu, and .efi, satisfying the CRA’s requirement for consistent controls across product lines without rebuilding the signing infrastructure for each platform.
Post-Quantum Cryptography Support
CodeSign Secure v3.02 supports production-grade ML-DSA (FIPS 204, at ML-DSA-44, ML-DSA-65, and ML-DSA-87 security levels) and SLH-DSA (FIPS 205) as detachable signatures alongside classical algorithms. For manufacturers building products with five-plus year CRA support obligations, PQC signing today is the architecture that protects against the HNDL threat before a CRQC arrives.
CI/CD Pipeline Integration
CodeSign Secure integrates with Azure DevOps, Jenkins, GitLab CI, and other major pipeline platforms through API and command-line interfaces. Firmware signing is a controlled, policy-enforced stage in the build pipeline, not a manual step.
Conclusion
SBOMs give security teams visibility into what goes into their software. Build provenance and artifact signing take the next step. They give you cryptographic proof of how the software was built, and they help confirm it reaches production unchanged. The SLSA framework turns that idea into a practical, staged path. Instead of asking teams to solve everything at once, it defines clear levels that can be adopted incrementally.
Level 1 requires build provenance to be generated and made available, giving teams a record of how each artifact was produced. Level 2 raises the bar by having the build platform itself generate and sign that provenance. This prevents a compromised build script from forging it, and it is achievable on most modern CI platforms. Level 3 further hardens the build environment for critical workloads and high-assurance software. For many organizations, reaching Level 2 early provides a strong security baseline, while Level 3 can be adopted over time where higher assurance is required. Organizations that begin this journey now will be well positioned as verifiable build integrity becomes a baseline expectation.
If you want to understand where your organization stands today on build provenance, artifact signing, or PQC readiness for your supply chain, reach out to us to start the conversation.
