Notifications
Clear all
Topic starter
21/08/2026 4:54 pm
TL;DR: Software supply chain security has improved visibility, but triage and remediation still lag, with MTTR stalled at 252 days, 67% of organisations lacking SCA coverage, and supply chain attacks rising 567% year over year, according to Pixee's analysis of 20 industry reports. The governance problem is capacity, not awareness, because detection without automated remediation cannot keep pace with dependency sprawl and transitive risk.
NHIMG editorial — based on content published by Pixee: How to Secure the 77% of Code You Didn't Write
By the numbers:
- The average application has 128 direct dependencies, each with 4+ of their own, creating 1,536 potential vulnerability points from a single application.
- The industry has seen a 567% increase in supply chain attacks year over year, according to Google Cloud.
- Teams fix less than 10% of existing vulnerabilities monthly, even as organisations add 458 new packages yearly.
Questions worth separating out
Q: Where does supply chain security fail when organisations rely on detection alone?
A: It fails when teams can see vulnerabilities but cannot triage and fix them fast enough.
Q: Why do transitive dependencies create more software supply chain risk than direct packages alone?
A: Transitive dependencies hide exposure inside nested libraries that are often missed by top-level package reviews.
Q: How do security teams know if software supply chain governance is working?
A: It is working when teams can identify which software and dependencies are deployed, match them to critical environments, and prove they can act quickly on vulnerability disclosures.
Practitioner guidance
- Map transitive dependency risk across the full build chain Inventory direct and nested dependencies, then flag packages that enter production through multiple layers of abstraction.
- Tie remediation SLAs to exploitability and reachability Stop using a single severity threshold for every finding.
- Govern CI and package registry identities as part of SCA Review service accounts, tokens, and signing credentials that publish or approve software artifacts.
What's in the full report
Pixee's full analysis covers the operational detail this post intentionally leaves for the source:
- The report's vendor-by-vendor benchmark comparisons for SCA maturity, triage workflows, and remediation performance
- Detailed breakdowns of detection-only, policy-driven, and automated-remediation SCA generations
- The underlying methodology behind the 20-report synthesis and the way each benchmark was normalised
- Examples of remediation workflows and developer acceptance patterns that are useful for implementation planning
👉 Read Pixee's analysis of the 2025 supply chain security benchmark →
Supply chain security stall: what AppSec teams need to fix now?
Explore further
21/08/2026 5:12 pm
Visibility is the easy part of supply chain security; remediation velocity is the control that matters. Most organisations can now enumerate dependencies, but the article shows that enumeration has not produced faster risk reduction. That is the same pattern we see in identity programmes that can inventory secrets but cannot govern their lifecycle. The practical conclusion is simple: measure what gets fixed, not just what gets found.
A question worth separating out:
Q: What should teams do when dependency alerts outnumber their fix capacity?
A: Prioritise by reachability, exploitability, and asset criticality, then automate low-risk remediation so human effort goes to the issues that can actually hurt production. Add policy-based exception handling for the remainder, and tie build-system identity controls to the same workflow so compromised automation cannot widen the blast radius.
👉 Read our full editorial: Supply chain security is stuck at visibility, not remediation velocity
