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.
At a glance
What this is: Pixee says dependency scanning is producing more alerts than teams can absorb, and the core challenge has shifted from finding vulnerable packages to governing remediation across transitive chains.
Why it matters: This matters because AppSec and platform teams need remediation controls that developers will accept, not just more findings, especially when vulnerable code sits three layers deep in dependencies.
By the numbers:
- Supply chain attacks increased 567% between 2019 and 2024.
Context
Software composition analysis is only useful when organisations can separate meaningful dependency risk from background noise. In practice, the hard part is not generating alerts but deciding which findings are reachable, exploitable, and safe to change without breaking production systems.
This article is about a governance failure inside application security programmes: remediation workflows often lag behind discovery because dependency fixes require version reasoning, transitive chain tracing, and change validation. The identity angle is indirect but real, because software supply chain controls increasingly depend on who can change manifests, approve pull requests, and release fixes into production.
Key questions
Q: What breaks when dependency remediation is left to manual triage?
A: Manual triage collapses under scan volume because teams have to trace reachability, exploitability, transitive chains, and version compatibility for each finding. That creates backlog growth, inconsistent prioritisation, and a steady drift toward ignoring alerts. The failure is not lack of intent, but a remediation process that asks humans to do work at machine scale.
Q: Why do reachable dependency vulnerabilities still require exploitability analysis?
A: Because a reachable flaw is not always attackable in the real deployment context. Network exposure, authentication layers, service isolation, and control placement all change whether the vulnerable code path can actually be used. Exploitability analysis stops AppSec teams from spending scarce effort on findings that are reachable in theory but not practically dangerous.
Q: What are the signs that dependency update automation is failing?
A: The clearest signs are repeated rollback of upgrade PRs, low developer trust in automated fixes, and a backlog that keeps growing even though scans are running. If teams constantly reject or redo generated updates, the process is producing change without producing resolution. That usually means compatibility analysis is too weak or the remediation workflow lacks context.
Q: How should AppSec teams govern dependency fixes across many repositories?
A: They should centralise remediation policy while keeping review and approval local to the owning team. The practical model is a common triage standard, shared dependency intelligence, and repository-level review for actual merges. That prevents fragmented decision-making without turning remediation into a black box that developers will not trust.
Technical breakdown
Why dependency remediation is harder than SAST triage
SCA remediation differs from source-code vulnerability management because the vulnerable code is usually in a package you do not own. Teams cannot patch the library directly, so they must identify a safe replacement version, understand any transitive effects, and validate that the new version preserves expected behaviour. That creates a multi-layer decision problem spanning package manifests, dependency constraints, and application test outcomes. The operational burden rises quickly when the same vulnerability appears across many repositories, because each one may depend on a different chain of indirect packages.
Practical implication: treat dependency remediation as a controlled change process, not as a simple upgrade ticket.
Reachability and exploitability decide which SCA findings matter
Reachability asks whether the vulnerable function is actually called by the application, while exploitability asks whether the flaw can be used in the deployed context. Together they reduce the false-positive burden that makes raw scan output unusable at scale. The article’s point is that finding a CVE is not enough, because most vulnerable code paths never execute and some exposed flaws remain effectively inert behind compensating controls. This shifts triage from package presence to runtime relevance and attack path analysis.
Practical implication: prioritise SCA findings only after testing code-path reachability and deployment-context exploitability.
Breaking-change prediction is the missing control for safe upgrades
A dependency fix only helps if developers will merge it, and that depends on confidence that the upgrade will not break application behaviour. Breaking-change prediction compares the old and new package versions to infer API surface changes, removed methods, altered defaults, and compatibility risks before a pull request is merged. That is a governance control, not just a coding convenience, because it turns remediation into a reviewable decision instead of a gamble. Without it, teams revert to manual investigation or ignore automated update PRs altogether.
Practical implication: require pre-merge compatibility analysis before dependency updates are allowed into the release flow.
Threat narrative
Attacker objective: The attacker objective is to exploit reachable dependency vulnerabilities before organisations can convert scan findings into validated, production-safe fixes.
- Entry begins when vulnerable third-party code enters the build through package managers and is accepted without full review of its dependency tree.
- Credential-like trust is then placed in scanner output and automated update PRs, even though most vulnerable paths are indirect and many fixes are untested for compatibility.
- Impact emerges when teams cannot safely prioritise or merge fixes, leaving exploitable dependency flaws exposed across multiple repositories for months.
Breaches seen in the wild
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Remediation governance, not scan volume, is the real AppSec bottleneck. The article correctly frames SCA as a workflow problem rather than a detection problem. Organisations already know how to create findings, but they struggle to decide which ones are actually actionable, safe to change, and likely to be merged. The practical conclusion is that remediation policy now matters as much as detection coverage.
Transitive dependency debt: indirect packages turn every fix into a chain-of-trust decision. Once vulnerability remediation depends on chains three layers deep, the old assumption that a developer can simply bump a version collapses. That creates a governance burden over package provenance, version constraints, and change approval that traditional ticketing cannot manage well. Practitioners should treat indirect dependency depth as an operational risk signal, not just a software architecture detail.
Reachability and exploitability are the right filter, but they are not the end state. They reduce noise, yet they do not on their own close the loop between detection and secure release. The market is moving toward proof that a fix is not only valid in theory but mergeable in practice, which means AppSec programmes need evidence about runtime use, deployment context, and compatibility before escalation. The practitioner takeaway is to measure remediation quality, not alert count.
Supply chain security now intersects with identity governance through change authority. The article’s strongest identity lesson is not about end-user access, but about who is authorised to modify manifests, approve dependency updates, and release code into production. That makes pull-request review, signing authority, and release approval part of the control surface for software supply chain risk. Teams should govern those human and machine approvals as tightly as the dependencies themselves.
Breaking-change prediction is a control, not a convenience feature. If automated fixes are not predictable enough for developers to trust, they become another source of alert fatigue. The decisive question for AppSec leaders is whether their remediation process produces reviewable, context-aware fixes that reduce backlog without creating outage risk. The practitioner conclusion is to judge automation by mergeability and stability, not by the number of PRs generated.
From our research library:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Dependency remediation backlog: once SCA output exceeds human review capacity, security teams need a governance model that filters by reachability, exploitability, and mergeability rather than by CVE count alone. That changes the unit of management from findings to fixes, and it forces AppSec leaders to report on resolution quality instead of raw alert totals.
The operational lesson is that transitive dependency chains are now part of change control, not just code hygiene. If a team cannot trace who can approve a manifest change, who validates compatibility, and who owns the release decision, the remediation process will stay slow even when scanners are accurate.
For practitioners
- Define a triage gate for dependency findings Require reachability and exploitability checks before any SCA alert is promoted into the remediation queue, so teams stop treating every CVE as equally urgent.
- Map transitive chains to direct package owners Trace each vulnerable indirect dependency back to the manifest entries your team can actually change, then assign ownership at the package and repository level.
- Add pre-merge breaking-change validation Run compatibility analysis against API surface changes, removed methods, and default-behaviour shifts before dependency update PRs are allowed to merge.
- Measure remediation by merge rate Track the percentage of generated dependency fixes that developers accept without rollback, because mergeability is the clearest signal that remediation is usable.
Key takeaways
- Dependency scanning can expose vulnerable packages faster than teams can resolve them, which turns remediation into a governance and change-management problem.
- The article’s evidence shows why raw alert volume is misleading, because many critical findings are not actually critical in a given application context.
- AppSec teams need controls that improve triage, compatibility confidence, and mergeability if they want remediation to keep pace with modern software supply chains.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006 — Credential Access | Supply chain compromise often pivots into secret theft and downstream access abuse. |
| Recommendation — Map dependency-compromise scenarios to TA0006 and monitor for secret access paths in build pipelines. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is about managing vulnerability remediation in software supply chains. |
| Recommendation — Use CIS-16 to formalise vulnerability intake, triage, and remediation across application dependencies. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability Management | Dependency remediation is a core vulnerability-management and change-control activity. |
| Recommendation — Embed dependency remediation into PR.IP-12 so vulnerabilities move through a governed fix process. | ||
| SLSA | L3 — Build Provenance | Transitive dependency risk is amplified when build inputs and artifacts are not provenance-verified. |
| Recommendation — Adopt SLSA L3 practices to strengthen build provenance and reduce supply-chain uncertainty. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Automated dependency changes can introduce misconfiguration-like breakage in application behaviour. |
| Recommendation — Review dependency update automation for API8-style configuration drift that can break runtime behaviour. | ||
Key terms
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
- Exploitability context: Exploitability context is the evidence used to decide whether a vulnerability matters in a specific environment. It includes reachability, code path exposure, compensating controls, and product-specific advisories, and it turns raw scan data into a decision that can be defended.
- Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
- Breaking-Change Prediction: Breaking-change prediction estimates whether a dependency upgrade will alter APIs, defaults, or behaviour in a way that disrupts the application. It is the control that separates a safe automated fix from a PR that reintroduces risk through regressions or developer rejection.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps security and identity practitioners connect access governance to the wider controls their programmes depend on.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org