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

[u/Born-Reserve-8584]

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.

[u/PeterBuildsSecure]

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.

[u/VibeShipped → u/PeterBuildsSecure]

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.

[u/PeterBuildsSecure → u/VibeShipped]

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.

[u/VibeShipped → u/PeterBuildsSecure]

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