Topic starter
21/08/2026 4:54 pm
TL;DR: Software supply chain security still stalls on triage and verified fixes, with MTTR at 252 days and 67% of organisations lacking SCA coverage, according to Pixee. Dependency sprawl keeps exposure alive until remediation catches up.
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: 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.
Q: What breaks when supply chain security stays focused on visibility instead of remediation?
A: The control that breaks is the response loop.
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.
Glossary terms: Remediation velocity, Software Composition Analysis, Transitive Dependency, Reachability analysis
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
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