I'm putting together a software supply chain security plan for a mid-sized team, but most of the material I've found comes from vendor blogs. We already generate SBOMs in CI, although they mostly sit unused. I'm comparing open-source signing tools with paid platforms, and they seem to solve different parts of the problem. Signing and build provenance appear valuable, but I'm unsure how far teams get before the process becomes too difficult to maintain. Which controls have actually caught a real issue in your pipeline?
4 Answers
The controls that caught real issues for us were surprisingly basic. We once published a binary that was two releases behind, and another time our CLI worked in CI but failed for users because the dependency resolution differed between the lockfile and the published package. We fixed that by installing the actual published wheel in CI and running the real command. We also flag deleted or skipped tests in code changes, which has become especially useful with machine-generated code. SBOMs are only useful when dependency changes trigger checks during pull requests or builds; otherwise they’re just an inventory nobody reviews.
For signing, public transparency logs make verification convenient across environments, but they also expose metadata about what was signed. Teams with stricter privacy requirements can use customer-managed keys, a private transparency service, or another signing standard, though those options add key-management and verifier-distribution work. Whatever approach you choose, signing only matters if release and deployment systems enforce it rather than treating signatures as optional documentation.
A practical baseline is signed artifacts, provenance attestations, and deployment policies that reject anything unsigned or missing the expected metadata. Add automated dependency update tooling, preferably with a cooldown period before newly released packages are allowed into internal builds. A dependency proxy or mirror can block direct access to public package repositories while providing malware, vulnerability, and license scanning. For SCA, VEX or OpenVEX support is important so teams can distinguish exploitable findings from components that are present but not actually affected. Build fingerprints can also connect every deployment back to its commit and pipeline run.
Reducing the image first helps too. Minimal or distroless images contain fewer unused packages, which cuts both the attack surface and the amount of vulnerability noise. VEX explains why a finding isn’t relevant, but it doesn’t replace keeping unnecessary packages out in the first place.
One gap is that conventional SBOMs don’t describe every executable dependency. For example, tool servers added to an editor or CI environment may have no lockfile, versioned artifact, or conventional package entry, yet they can run with developer credentials. Their available tools and capabilities can change during a handshake. A useful lightweight control is to capture the tool list and relevant capability or credential requirements at session start, hash it, and store it with the run. That won’t prevent a change, but it turns a vague incident investigation into a concrete diff. The broader challenge is representing a dependency that has no stable version or artifact in an SBOM.
I’ll take a simple check that catches real failures over an impressive control that nobody monitors.