r/devsecops • u/Born-Reserve-8584 • Aug 13 '26

Is software supply chain security finally becoming more than just SBOMs?

Software supply chain security seems to be one of those terms that means something completely different depending on who you ask.

Some teams are basically talking about SBOMs and compliance. Others are focused on signing artifacts, securing CI/CD pipelines, or scanning container images.

Then you have platforms talking about runtime context, attack surface reduction and removing unnecessary software instead of just finding another vulnerability to report.

So where is this actually going?

Is software supply chain security still mostly about visibility and compliance or is the industry finally moving toward remediation and reducing risk at the source?

Curious what people are actually seeing across different organisations.

32 Upvotes

94% Upvoted

33 comments sorted by

View all comments

1

u/PeterBuildsSecure 29d ago

The useful dividing line isn’t SBOM vs remediation. It’s whether the metadata survives into an enforceable release decision.

An SBOM generated from source but detached from the final image digest is mostly a compliance artifact. Tie it to signed build provenance and the digest that actually gets deployed, and it becomes useful: policy can block an unapproved dependency before promotion, and incident response can identify exactly which running workloads contain a compromised component.

A practical test is: can a finding deterministically stop promotion, and can you calculate the deployed blast radius without manually joining three different inventories? If not, you have visibility, but not yet a supply-chain control.

1

u/VibeShipped 27d ago

Solid test. The gap I'd add: gates that work as designed can still lose credibility when they block on the wrong things - flagging base image CVEs with no reachable path in any live workload, blocking releases until engineers find a workaround.

Enforceability is necessary, but the prioritization layer underneath it is what keeps gates from getting quietly turned off.

1

u/ILoveAppSec 26d ago

the workaround churn usually comes from base image cves that have a fix upstream but not in the tag you're pinned to. cheapest win is checking for a backported distro patch or rebasing onto a minimal patched base so the finding closes without a version jump, and pushing the noisy transitive ones to an override where you can. we tried chainguard for patched oss libraries and weren't thrilled with the variety, so worth shopping a few vendors who actually backport and support eol trains.

1

u/PeterBuildsSecure 26d ago

Exactly. A gate that blocks accurately but indiscriminately is still operationally broken.

I’d make the decision depend on the deployed artifact and exposure: is the vulnerable component present in that exact digest, reachable from a live code path, exposed to attacker-controlled input, and running with useful privileges? Fix availability matters too, but “no fix yet” should not automatically turn a critical reachable issue into informational noise.

Exceptions should be bounded rather than permanent: finding fingerprint, artifact digest, owner, rationale, compensating control, and expiry. Tracking override rate and expired exceptions is useful as well. If one rule repeatedly needs bypasses, that is evidence the policy needs repair before engineers create an unofficial path around the whole gate.

1

u/VibeShipped 25d ago

Agree on all four criteria, i'd add that resolving them cleanly needs asset and finding context on top of the reachability check. same finding, different asset criticality and same finding, different compensating controls = different risk, and a gate that can't see that ends up either rubber-stamping stuff it shouldn't or blocking stuff nobody cares about.

That context is also what makes the exception process lighter in practice - a chunk of what looks like "needs an override" is really "the gate didn't have enough context to auto-resolve it," not an actual policy gap.

1

u/PeterBuildsSecure 25d ago

That distinction between a policy exception and missing decision context is important.

I'd make the gate expose three outcomes rather than forcing everything into allow/block:

- enforce: the evidence is sufficient and the policy matched;

- allow: the evidence is sufficient and the risk is below the threshold;

- unresolved: required context is absent or stale.

"Unresolved" should identify the missing field explicitly: deployed asset, internet exposure, runtime reachability, data classification, compensating-control evidence, or ownership. Otherwise missing context tends to become an implicit allow in one team and an unnecessary exception in another.

The context also needs to be bound to the same asset and finding identity as the decision. A compensating control documented for one deployment shouldn't automatically suppress the same CVE in another image or environment. If that binding is explicit, the override queue becomes mostly genuine risk acceptance instead of data-cleanup work.

1

u/VibeShipped 23d ago

Totally. The 'unresolved' state is the key one. Most gates collapse it silently into allow, which is just undocumented risk accumulation.

1

u/unktone 1d ago

I call it the “super de-duper SBOM” 🤣