Notifications
Clear all
Topic starter
20/08/2026 5:43 pm
TL;DR: Dependency scanning is producing more alerts than teams can absorb, but the real failure is remediation: Pixee argues that reachability, exploitability, and breaking-change prediction are what turn noisy SCA output into fixes developers will actually merge. The bottleneck is no longer detection, but governed resolution across transitive dependency chains and reviewable pull requests, which changes how AppSec programmes should measure success.
NHIMG editorial — based on content published by Pixee: SCA Remediation at Scale: Dependencies Are the Real Challenge
By the numbers:
- 567% between 2019 and 2024., sed 567% between 2019 and 2024.
- 88% of "Critical" dependency CVEs are not actually critical in their environment.
- 71% of organisations report that 21-60% of their scan results are worthless.
Questions worth separating out
Q: What breaks when dependency remediation is treated as simple version bumping?
A: Version bumping can remove a CVE while introducing API changes, test failures, or runtime regressions that delay or reverse the fix.
Q: When should organisations prioritise reachability over raw vulnerability counts?
A: Organisations should prioritise reachability whenever scan volume exceeds human review capacity, which is common in large dependency trees.
Q: What do security teams get wrong about SCA when malicious packages are involved?
A: They assume dependency analysis alone is enough.
Practitioner guidance
- Implement reachability-based triage Filter dependency findings by whether the vulnerable function is actually called in your application, not just present in the lockfile.
- Add breaking-change prediction to fix generation Require dependency remediation workflows to estimate API and behaviour changes before they generate pull requests.
- Move dependency remediation to manifest ownership Assign clear ownership for package.json, pom.xml, requirements.txt, and go.mod changes so transitive vulnerability fixes do not stall between teams.
What's in the full article
Pixee's full article covers the operational detail this post intentionally leaves for the source:
- Scanner-agnostic ingestion patterns for normalising findings from multiple AppSec tools into one remediation queue
- Breaking-change prediction logic for dependency upgrades, including how to evaluate API surface and downstream breakage risk
- Manifest-level resolution workflows for transitive dependencies across package.json, pom.xml, requirements.txt, and go.mod
- Developer-reviewable pull request patterns and the merge-rate metric used to judge remediation effectiveness
👉 Read Pixee's analysis of SCA remediation at scale and dependency triage →
Dependency remediation at scale: what AppSec teams are missing?
Explore further
20/08/2026 6:26 pm
Dependency remediation is now a control-plane problem, not a ticketing problem. The article shows that the decisive issue is not whether scanners can find vulnerabilities, but whether organisations can convert findings into safe, reviewable change. That shifts SCA from alert handling to control-plane design, where reachability, exploitability, and release governance all intersect. For practitioners, the lesson is to treat remediation as an operating model with ownership and approval paths, not a backlog of defects.
A question worth separating out:
Q: How should teams govern dependency changes across transitive chains?
A: Teams should treat transitive fixes as governed manifest changes with clear ownership, review, and rollback paths. The direct dependency owner must be accountable for resolving indirect exposure, validating the upgrade path, and confirming that the new version does not break downstream services.
👉 Read our full editorial: SCA remediation at scale is now a governance problem
