SBOMs and Identity: From Inventory to Trust

SBOMs and Identity: From Inventory to Trust

The modern software supply chain is a complex maze of dependencies, third-party libraries, and automated builds. Incidents like Log4Shell exposed a critical vulnerability: organizations knew what software they ran but often lacked visibility into specific versions within their containers or the ability to verify if those versions had been tampered with during the build process. A Software Bill of Materials (SBOM) resolves the inventory problem by listing every component in a piece of software. However, an SBOM without identity is merely a list that could be forged. To secure the supply chain, we must couple the "what" (the SBOM) with the "who" (cryptographic identity via SLSA and cosign). This combination transforms the supply chain from a black box into a verifiable pipeline.

As Part 12 of the Machine Identity & DevSecOps Series, this guide details how these mechanisms shift security from perimeter-based detection to artifact-level verification.

The SBOM as a Dependency Map

An SBOM is not a narrative document; it is a structured data file, typically in JSON or XML formats like SPDX or CycloneDX. Its primary mechanism is to enumerate all direct and transitive dependencies within a software artifact. When a developer compiles a Go binary or a Java application, the build system aggregates a list of libraries. An SBOM captures this list, assigning each component a unique identifier, a version string, and often a cryptographic hash of the dependency itself.

Consider a scenario where a microservice depends on libcrypto. Without an SBOM, an operations team sees only the compiled binary. If libcrypto has a CVE, the team must manually inspect the binary or guess the version. With an SBOM, the dependency is explicitly listed as libcrypto: 1.1.1k. This enables Software Composition Analysis (SCA) tools to automatically cross-reference the list against vulnerability databases. The mechanism here is static analysis: the tool reads the SBOM, parses the component identifiers, and queries a CVE database to flag mismatches.

This approach is codified in standards like the NIST SP 800-161, which outlines how SBOMs should be generated and utilized to manage supply chain risk. Without this explicit inventory, security teams are blind to the transitive dependencies that often carry the highest risk. Furthermore, while the SBOM provides the necessary data for dependency security, it relies on artifact signing to ensure that the list itself has not been spoofed or altered before reaching the scanner.

The Provenance Problem

Having an accurate list of components is necessary but insufficient. An attacker can generate a valid SBOM for a malicious artifact. If I compile a malicious binary that includes a legitimate copy of libcrypto, my SBOM will correctly list libcrypto, yet the binary itself is compromised. The SBOM proves what is inside, but it does not prove who built it or how.

This is the provenance gap. In a typical CI/CD pipeline, source code flows into a build environment, which produces an artifact. If the build environment is compromised, or if the artifact is swapped during transit (a "build supply chain attack"), the artifact's integrity is broken. An SBOM generated after the fact cannot detect that the build process was hijacked. We need a mechanism that binds the artifact to the build environment and the source code cryptographically.

This is where the SLSA (Supply-chain Levels for Software Artifacts) framework becomes essential. SLSA does not generate the SBOM; instead, it generates "provenance" metadata. Provenance is a cryptographic record stating: "This specific artifact was built from this specific source code commit, using this specific build configuration, in this specific environment."

SLSA Levels and Verification

SLSA defines four levels of maturity, moving from informal to highly secure. Level 1 requires that the artifact exists and has a link to the source, but the build process is not verified. Level 2 requires that the build environment is controlled by the provider. Level 3, which is the target for most high-security organizations, requires that the build environment is isolated and that the source code is verified before the build starts. Level 4 adds the requirement that the build is reproducible.

The mechanism at Level 3 involves the build runner generating a "build provenance" file using the SLSA provenance format (based on in-toto statements) that includes a hash of the source code and the build logs. This provenance is attached to the artifact. When a consumer receives the artifact, they do not just check the SBOM; they verify that the provenance matches the expected source and build environment.

Google's SLSA specification details how these levels are implemented, emphasizing that the integrity of the build pipeline is as important as the integrity of the code. By enforcing these levels, organizations ensure that an artifact claiming to be built from commit-abc123 actually originated from that commit, preventing attackers from injecting code into a legitimate build process.

Artifact Signing with Cosign

Even with SLSA provenance, we need a way to verify that the provenance file itself hasn't been altered. This is where artifact signing comes in. The standard mechanism for this in the cloud-native world is using Public Key Infrastructure (PKI) via tools like cosign.

cosign allows you to sign an artifact (like a container image) with a private key. This creates a digital signature that is mathematically bound to the artifact's content. If even a single bit of the artifact changes, the signature becomes invalid. The verifier holds the corresponding public key to validate this signature.

In a practical workflow, the CI/CD runner (which holds the private key) signs the artifact immediately after the build completes. The signature is stored alongside the artifact in the container registry. When a security engineer or an automated policy engine pulls the image, it runs cosign verify. This command checks:

1. Is the signature valid? (Has the artifact been tampered with?)
2. Does the signer match the expected key? (Did the authorized CI/CD pipeline sign this?)
3. Does the signature contain a statement of the SBOM and SLSA provenance? (Optional but recommended).

This mechanism ensures that the artifact, its SBOM, and its provenance are all part of a single cryptographic chain of trust. The private key never leaves the secure build environment, and the public key is distributed to consumers.

cosign verify-image --key <public-key> <image-tag>

The End-to-End Verification Flow

To see how these pieces fit together, imagine a consumer downloading a container image for a production service. The verification flow is now a linear sequence of checks:

1. Pull and Verify Signature: The consumer runs cosign verify-image --key <public-key> <image-tag>. The tool confirms that the image was signed by the authorized build pipeline. If the signature fails, the process stops.
2. Extract Provenance: The consumer extracts the SLSA provenance file attached to the image. This file contains the hash of the source code and the build environment details.
3. Verify Source Integrity: The consumer compares the source hash in the provenance against the known source repository. This confirms the artifact was built from the expected code.
4. Extract SBOM: The consumer pulls the SBOM (often embedded in the image annotations or attached as a separate file).
5. Run SCA: The consumer feeds the SBOM into a Software Composition Analysis tool. The tool scans the list of dependencies against the CVE database.

If any step fails—say, the signature is invalid, or the SBOM lists a library version that has a critical CVE—the artifact is rejected. This flow shifts the security posture from "trust but verify" to "verify before trust."

The power of this approach lies in the separation of concerns. The SBOM handles the inventory and vulnerability scanning. The SLSA provenance handles the build integrity and source verification. The cosign signature handles the authenticity of the entire package. Together, they create a strong defense against supply chain attacks, ensuring that the software running in production is exactly what was developed, built, and tested.

As organizations adopt these standards, the complexity of managing keys and provenance files increases, but the reduction in risk is substantial. The mechanism is no longer about guessing what might be wrong; it is about mathematically proving what is right.

Common Pitfalls

Implementing SBOMs and SLSA introduces new operational challenges that must be anticipated.

1. Key Rotation Management: Private keys used for signing must be rotated periodically. Failing to update the public keys distributed to consumers or failing to revoke old keys in the policy engine can lead to stale trust relationships or security gaps. Automation is required to handle key generation, distribution, and revocation seamlessly.
2. False Positives in SCA: While SCA tools are powerful, they often flag vulnerabilities in transitive dependencies that are not actually reachable by the application code (e.g., conditional imports). Relying solely on automated reports without context can lead to "alert fatigue" and wasted engineering time.
3. Reproducibility Challenges: Achieving SLSA Level 4 requires reproducible builds. Minor environmental differences, such as timestamps, file system ordering, or non-deterministic compiler flags, can cause the build hash to change even if the source code is identical. This breaks the verification chain unless strict build environment controls are enforced.

Practical Takeaways

To successfully integrate these technologies, adopt the following mental models:

1. Trust is Local, Verification is Global: Do not assume the build environment is safe. Treat every artifact as potentially untrusted until the cryptographic chain of trust is verified by the consumer.
2. Shift Left, Not Just Right: Integrate SBOM generation and signing into the CI pipeline immediately after the build, not as a post-deployment audit step. This prevents compromised artifacts from ever reaching the registry.
3. Progressive Maturity: Do not aim for SLSA Level 4 immediately. Start by achieving Level 2 (controlled build environment) and Level 3 (isolated build), then iterate toward reproducibility.

FAQ

Q: Do I need SLSA Level 4 for immediate security? A: No. While Level 4 offers the highest assurance through reproducibility, Level 3 provides significant protection by isolating the build environment and verifying source code. Most organizations start at Level 2 or 3 depending on their risk tolerance.

Q: Can I use SBOMs without signing them? A: You can generate and store SBOMs without signing, but they offer limited security value. An unsigned SBOM can be easily swapped with a fake list, hiding vulnerabilities or malicious dependencies. Signing ensures the integrity of the inventory data.

Q: How does cosign handle key management? A: Cosign supports various key storage backends, including local files, hardware security modules (HSMs), and cloud key management services (KMS). For production environments, it is recommended to use KMS or HSMs to prevent private keys from ever touching the build host's disk.

Conclusion

By integrating SBOMs for inventory, SLSA for provenance, and cosign for identity, organizations establish a multi-layered defense against supply chain attacks. This triad moves security from a reactive stance to a proactive, verifiable model where every artifact carries its own history and proof of origin. As the threat landscape evolves, these mechanisms provide the necessary foundation for maintaining trust in the software supply chain.