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.
Editorial analysis by NHI Mgmt Group, based on content published by Pixee: “How to Secure the 77% of Code You Didn't Write”.
Key questions
Q: What breaks when supply chain security stays focused on visibility instead of remediation?
A: The control that breaks is the response loop.
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 can security teams measure whether supply chain controls are actually working?
A: Look for reduced use of long-lived publishing tokens, fewer workflows with broad secrets access, lower dependency auto-update exposure, and faster revocation after compromise.
Practitioner guidance
- Implement reachability-based triage Filter vulnerability queues by whether the vulnerable code path is actually executable in your environment, then prioritise by exploitability and asset criticality rather than severity labels alone.
- Automate dependency remediation workflows Generate tested pull requests for safe package upgrades so developers review fixes instead of manually authoring every change, and reserve human effort for exceptions and high-risk paths.
- Extend inventory to transitive dependencies Track dependencies of dependencies, not just first-order packages, so your review process covers the layers where many supply chain attacks actually land.
Bottom line: Software supply chain security is constrained less by discovery than by the ability to convert findings into verified fixes.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
21/08/2026 5:12 pm
Visibility has become the easy part of supply chain security; remediation capacity is the scarce control. Most organisations now know where many of their software risks are, but that knowledge is not reducing exposure because triage, prioritisation and fix generation still depend on human throughput. Remediation velocity is the named concept here: the programme’s ability to turn findings into verified fixes before the backlog compounds. Practitioners should treat this as an operating metric, not a tooling feature.
A question worth separating out:
Q: What should AppSec teams do when vulnerability alerts overwhelm developers?
A: Reduce the queue to actionable issues by combining reachability, exploitability and asset criticality, then convert safe fixes into pull requests. The goal is to stop treating every alert as equal and make the workflow executable for engineering teams.
👉 Read our full editorial: Supply chain security is stuck at visibility, not remediation velocity