In the wake of Executive Order 14028, the Software Bill of Materials (SBOM) became the industry's silver bullet. The logic was simple: if we know every ingredient in the software, we can identify every vulnerability.
But there is a fatal flaw in this logic.
An SBOM is a list of ingredients. It tells you that your software contains Log4j, a specific version of React, or a Go module. What it cannot tell you is if the kitchen where that software was cooked was compromised.
The Illusion of Security in Modern Pipelines
Standard security practices have historically focused on Static (SCA) and Dynamic (DAST) analysis of code. However, the rise of sophisticated attacks—such as the SolarWinds and Codecov breaches—demonstrates that an attacker does not need to compromise your source code to compromise your software. They only need to compromise the environment that compiles it.
Modern CI/CD workflows, specifically those relying on ephemeral GitHub Actions runners or shared GitLab executors, introduce a series of unverified variables:
- The Shadow Toolchain: Hidden dependencies and pre-installed binaries on build runners that are not tracked in your SBOM.
- The Secret Sprawl: Over-privileged OIDC tokens and long-lived secrets that provide an invisible "backdoor" to production environments.
- The Policy Gap: Compliance checks that happen too late in the process, forcing developers to choose between security and velocity.
The Transparency Gap
If an attacker compromises your CI/CD runner—the "kitchen"—they don't need to touch your source code. They can inject malicious binaries during the build process, steal OIDC tokens to escalate privileges, or modify the final artifact after the security scans have already passed.
Your SBOM will still look perfect. Your vulnerability scanner will show all green. Yet, your software is a Trojan horse.
84% of organizations use an SBOM, yet supply chain attacks are up 300%. We are verifying the code, but trusting the pipeline blindly.
From "Trust Me" to "Prove It"
The industry is currently suffering from a Chain-of-Custody crisis. An SBOM tells you the ingredients, but it doesn't tell you if the chef was compromised or if the kitchen was clean. To achieve true software sovereignty, organizations must move toward a model of verifiable integrity.
This requires a shift in the mental model of engineering enablement:
- Security as Code: Compliance must be written in the same language as the infrastructure, using Rego and OPA to create immutable guardrails.
- The Pipeline as a Product: The CI/CD engine must be treated with the same rigor as the customer-facing application, requiring its own hardened "Golden Images" and audited configurations.
- Verifiable Attestation: Every build must produce a PBOM (Pipeline Bill of Materials)—a cryptographically signed receipt that proves exactly which runner, which version of Go, and which security policies were active at the moment of creation.
Introducing the PBOM
At Build Flow Labs, we argue that visibility without integrity is an illusion. To secure the modern supply chain, we must move beyond the "What" (SBOM) and start documenting the "How."
The PBOM (Pipeline Bill of Materials) provides cryptographic proof of the build's lifecycle:
- Who triggered the build (OIDC Identity)?
- What specific runner environment was used?
- Which security policies were enforced during runtime?
- How was the final artifact signed and attested?
By shifting from reactive vulnerability scanning to proactive Pipeline Integrity, organizations can reclaim sovereignty over their software supply chains. Every line of code becomes not only secure but also verifiable from origin to deployment.
What Comes Next
In the next installment of The Integrity Series, we'll define the PBOM framework in detail—including the technical schema, the cryptographic mechanisms, and a reference implementation using BuildGuard and Sigstore.
It's time to stop just reading the label and start verifying the process.