Perhaps the single most powerful control was requiring the signed build attestations to be a mandatory, non-bypassable promotion gate between staging and production. Prior to that, SBOMs and security scans were informational, producing tickets that could be deprioritized. By requiring a verifiable signature to be a prerequisite for the release, we made the fundamental shift from 'scan-and-report' to a 'prove-and-proceed' model that changes behavior. While conducting an intense audit on behalf of a financial services client we had to prove exactly the source of every item in a decomposed container deployed to production. Utilizing the SLSA framework we programmatically constructed a verifiable dependency graph from the production artifact back to individual source code commits, build logs, and engineer identities. The audit passed because the provenance evidence created was truly immutable and machine-generated, coming from the pipeline and not retyped or even recreated later manually. Immutability and machine-generated proof provide a greater degree of trust than a simple SBOM file.
The single control that moved the needle was enforcing signed provenance at deploy time, not just generating SBOMs. We made provenance verification a hard gate so artifacts without valid attestations simply could not run in production. Example: we implemented SLSA Level 3-style provenance using in-toto attestations signed by the CI system and verified by the cluster admission controller. Each build had to prove source, builder, and immutable artifact digest before deployment. During a customer audit, we traced a running container back to a specific commit and build job in minutes. That closed the loop auditors actually care about and turned SBOMs from paperwork into enforceable security. Albert Richer, Founder, WhatAreTheBest.com
Being the Founder and Managing Consultant at spectup, one control that had the biggest impact on software supply chain security was enforcing strict provenance through signed build attestations combined with SBOMs for every release. Early on, we noticed that while SBOMs increased visibility into dependencies, they didn't inherently guarantee integrity or traceability across pipelines. I remember one situation where a client asked for evidence that every component in their deployment could be traced back to a trusted source, and we realized we needed a more robust mechanism than just inventory lists. The solution we implemented was adopting SLSA-based attestations across all build pipelines. Each build artifact carried a signed provenance record, detailing not only source inputs and versions but also the identity of the builder, the environment used, and any automated validation steps executed. One instance that stands out was during a customer audit for a fintech client: the auditor requested end-to-end traceability for a production release that included dozens of third-party libraries. Because our pipelines enforced signed attestations, we could produce a verifiable chain from source commit to deployed artifact, and the auditor specifically noted the clarity and reliability of our provenance records. Operationalizing this control required both cultural and technical alignment. Developers had to treat provenance metadata as a first-class citizen, and CI/CD pipelines had to reject any builds lacking valid attestations. At spectup, we often see founders underestimate the discipline required to make this stick. In practice, the control pays off because it not only satisfies audits but also prevents accidental or malicious inclusion of unverified components, which is the silent risk most companies overlook. What is rarely highlighted is that provenance enforcement doesn't just meet compliance it actively reduces risk by making every dependency auditable and every build reproducible. Over time, this approach became a cornerstone for client confidence and internal governance, ensuring that when security or regulatory questions arise, the answer is traceable, reliable, and defensible.