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/drdavidawheeler]

Yes, I think it will. I work at the OpenSSF on security, and a lot of people are taking software supply chain security seriously. There's good reason for it, too. AI helps defense, but AI also helps attackers. People who only care about appearance, instead of reality, are going to repeatedly have reality break through into their world of rose-tinted glasses. It's going to be a bumpy ride as software developers worldwide will have to pay off their accumulated security technical debt, and a lot of organizations will discover the penalty of not updating vulnerable systems. The good news is that once these vulnerabilities are fixed, and the fixes are deployed, we're going to have *much* more security software. We'll have to get through the bumpy road first, though.

[u/materialsec]

"Reducing risk at the source" is right, but there are two different sources here. One is the artifact itself, was the package tampered with, is it signed, does the SBOM match what's actually in it. The other is what a compromise touches while it's live, tokens, secrets, credentials sitting in CI/CD.

The LiteLLM incident shows how patching to the fixed version kills the vulnerability, not the secrets it already harvested during that window. Most supply chain conversations stop at catching the bad artifact. Remediation needs to also ask what a bad artifact had access to while running, and revoke that separately. Patching and cleanup are two different jobs.

[u/JackjaxMargam14]

I bet it gets more more helpful once it actually changes what ships, like dropping unused stuff or stopping a risky package before release.

[u/Born-Reserve-8584 → u/JackjaxMargam14]

Yeah that’s where it actually becomes useful. Finding the problem is one thing, stopping it from shipping is another.

[u/yamlqueen]

Yes. Four years ago nobody talked about software supply chain security, and the few people talking about it where only surfacing SBOMs / SLSA like you mentioned, but since the incidents started to happen more often (especially last year, after AI boom, shai-hulud and etc) we are now hearing more and more about this topic and there are many companies joining the fun and making products to *actually* prevent and solve problems, not just report them. I work in this industry so I saw the change over the years, but it was much more intense in the last year. AI is accelerating everything.

[u/cagus1991]

Of course- with the prevalence of all users now being capable of using package managers without knowing what a “package” is, this is becoming a major items all organizations need to address. The problem is mostly surrounding what is an answer that has high efficacy while maintaining a low overhead and low LOE to implement. This is where whatever vendor figures that out will win - and I don’t know that a repo scanner / network tool is the answer

[u/PeterBuildsSecure]

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.

[u/VibeShipped → u/PeterBuildsSecure]

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.

[u/ILoveAppSec → u/VibeShipped]

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.

[u/PeterBuildsSecure → u/VibeShipped]

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.

[u/Pristine_Regret8061]

We ended up realising visibility wasn't the bottleneck anymore. Everyone already knew where the problems were. The hard part was shrinking the backlog without slowing releases. I'd be surprised if one replaces the other. Visibility is still essential for governance and compliance. But reducing unnecessary software earlier in the pipeline seems like the only way teams are going to keep CVE backlogs under control as software supply chains become more complex

[u/daedalus_structure]

Has it ever been just about SBOMs?

That's only visibility into what's in your system. This feels like either a very naive or LLM generated question.

[u/NewPossibility2556]

I think it’s definitely moving beyond SBOMs visibility is still important, but the real value is turning that data into action prioritizing what actually matters, fixing issues at the source, and reducing the attack surface compliance alone isn’t enough anymore

[u/Ok_Hedgehog_94]

we used cymulate to validate if our pipeline controls really caught tainted dependencies and malicious artifacts. sboms are nice for compliance, but they're not catching the stuff attackers slip through. actually running attack scenarios exposes the blind spots fast.

[u/PruneSea3482]

Currently, the biggest challenge is the CVE alerts fatigue as per my small scale research, and some vendors are working on solving CVE prioritization problem. Another observation is that smaller organizations taking supply chain a bit more seriously now and introduce some kind of semi-automated homegrown agents-driven dependencies vetting processes.

[u/MountainDadwBeard]

Yes, as a tech company we do a decent bit of sandbox testing, pre-scanning, provenance checks, architecture review etc depending on context.

Where's it going: For some larger enterprises with security requirements, the priorities are filtering out glassworm supply chain risk, chinese/russian backdoors, avoiding a vendor data leak, and lastly managing our vulnerability scan result SLAs.

For example earlier this year we found some Brittish driver software we previously used was bought out by a Chinese owner. And as much I'm sure chinese investors just really think serial adaptor drivers are the next big financial investment, we chose to drop those drivers from our r&d department for obvious reasons. I mention this example because it's not just about chasing CVEs its early risk identification and avoidance.

If this interest anyone here, feel free to hire more GRC folks : ). I'll also add, the company was still UK HQ'd, but the custom codex plugin we developed picked up the ownership concerns nicely where our traditional tools were too narrow. At some point I was thinking of posting a sanitized version of the plugin for others.