TL;DR: 77% of application code now comes from third-party sources, while 88% of SCA alerts are noise in many environments, leaving teams buried in triage and missing the vulnerabilities that are actually exploitable, according to Pixee. The practical shift is from counting findings to governing reachable risk, because prioritisation that ignores execution paths, authentication boundaries, and deployment context does not scale.
At a glance
What this is: This analysis says alert-heavy SCA is overwhelming teams and that reachability-based prioritisation is a better way to focus on exploitable vulnerabilities.
Why it matters: It matters because IAM, AppSec and platform teams need to separate theoretical exposure from reachable risk, especially where third-party code, authentication boundaries and deployment context shape exploitability.
Context
Modern software now ships with substantial third-party code, which means vulnerability management is no longer about a small set of internally written components. The governance problem is that scanners can surface far more findings than teams can triage, while many of those findings are not reachable in the deployed application.
For identity and access programmes, the important distinction is between code that merely exists in a dependency tree and code that can actually be reached through application paths, authentication boundaries and exposed services. That is a practical control question, not just an AppSec tuning issue, and the article treats that operational gap as the core problem.
Key questions
A: SCA creates noise because it maps findings from code and dependency metadata, then scores them without knowing how the application behaves at runtime. In cloud-native systems, libraries may be installed but unused, inaccessible, or shielded by controls that change real risk. That mismatch produces false positives, weak prioritisation, and a backlog that security teams struggle to reduce.
A: Prioritise by exploitability, exposure, and business impact, not by severity alone. A flaw with a known exploit, public reachability, and a critical business function should move ahead of a higher-scoring issue that is isolated or difficult to reach. The goal is to reduce attack surface, not simply clear the longest list.
Q: What are the signs that SCA triage is failing?
A: Common signs include a growing backlog, long triage cycles, repeated exceptions, and engineering teams treating security tickets as low-value noise. When most findings are not actionable and the team cannot explain why a specific issue matters in its runtime context, the programme is measuring volume rather than risk.
Q: What should organisations do when scanner findings overwhelm developers?
A: Shift from blanket scanning to context-aware prioritisation, then align security and engineering on a single queue of reachable issues. That means filtering out unreachable dependencies, ranking internet-facing components higher, and making remediation part of normal development workflows instead of a separate security bottleneck.
Technical breakdown
Why software composition analysis produces unusable noise
Traditional software composition analysis inventories dependencies and matches them to known CVEs, but it usually does not understand application context. That means a vulnerable package can be flagged even when the affected function is never called, the endpoint is not exposed, or compensating controls block exploitation. The result is a large volume of findings that are technically accurate but operationally unhelpful. In practice, this turns SCA into a backlog generator unless the team adds context about code paths, authentication, and deployment exposure.
Practical implication: Use reachability and exposure context to separate real remediation work from theoretical dependency risk.
How reachability analysis changes vulnerability prioritisation
Reachability analysis asks whether vulnerable code is actually executable from a real entry point in the deployed application. It traces call paths, data flow, and runtime conditions to determine whether a CVE can be hit in practice. That is more useful than severity labels alone because exploitability depends on whether an attacker can reach the vulnerable function through the application’s actual control plane. This shifts SCA from static counting to contextual risk ranking, which is why it can reduce actionable findings without reducing coverage.
Practical implication: Prioritise remediation based on code path, exposure, and exploitability instead of scanner severity alone.
Why authentication boundaries matter in exploitability analysis
Authentication boundaries are not just an access-control detail. They are part of exploitability because many vulnerabilities only matter when an attacker can reach a function before authentication, after weak authorisation, or through an exposed service path. If SCA tooling does not model those boundaries, it can overstate risk in protected areas and understate risk in internet-facing flows. For organisations with identity-aware architectures, this is where AppSec and IAM governance intersect: the access path determines whether the finding is theoretical or actionable.
Practical implication: Treat authentication and exposure context as part of vulnerability triage, not as separate disciplines.
Threat narrative
Attacker objective: Exploit reachable dependency flaws in production applications before defenders can identify which findings are actually exploitable.
- Entry occurs through third-party code and open source dependencies embedded in production applications, creating a large surface of potential flaws.
- Credentialed or unauthenticated access becomes relevant only when the vulnerable function sits on a reachable execution path or exposed service boundary.
- Escalation happens when teams cannot distinguish exploitable issues from noise, so real vulnerabilities stay unfixed while attention is spent on irrelevant findings.
- Impact is delayed remediation, larger backlog risk, and exposure to exploits in components that are actually reachable in production.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
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
Reachability is the missing governance layer in software composition analysis. Counting vulnerable dependencies is not the same as understanding exploitability, and that distinction has become operationally decisive. A scanner can be accurate and still be wrong for the environment if it ignores whether code is actually executed, exposed or protected by authentication. Practitioners should treat reachability as a control requirement, not a reporting enhancement.
Application security now depends on execution context, not just vulnerability presence. CVSS and backlog counts describe catalogue risk, while defenders need deployment-aware risk to decide what gets fixed first. That is especially true where services are segmented, authenticated, or partially unreachable. Teams that do not encode context into triage will continue to spend effort on findings that cannot be exploited.
Identity boundaries change whether a dependency vulnerability is operationally real. When vulnerable code sits behind strong authorisation or an unreachable path, the security meaning changes materially; when it sits on an internet-facing flow, the same CVE can move to the front of the queue. This is where AppSec and IAM governance intersect, and the practical conclusion is that access context must inform vulnerability governance.
SCA tooling is drifting from detection to decision support. The market signal is not that scanning is obsolete, but that scanning alone no longer answers the question defenders need answered. Reachability analysis, deduplication and workflow integration are becoming the governance layer around vulnerability data. Practitioners should expect prioritisation to move closer to runtime context and farther from raw alert volume.
Security teams should stop treating alert volume as a proxy for coverage. A high finding count can coexist with poor risk reduction if the programme cannot identify which issues are exploitable in the current architecture. The better measure is how quickly teams eliminate reachable risk in important applications. That shifts the programme from reactive triage to governed exposure reduction.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Reachability-aware triage is becoming the practical answer to alert fatigue. Teams do not need more raw vulnerability data if they cannot distinguish exploitable code from inert code. The programme-level shift is to make remediation decisions from execution context, not from scanner output alone.
Identity and exposure boundaries now influence vulnerability governance. If a vulnerable dependency is behind strong authentication or unreachable network paths, it should not compete with a flaw on an internet-facing service. That is a governance decision as much as a technical one, and it belongs in the triage model, not after it.
Only 5.7% of organisations have full visibility into their service accounts. according to the Ultimate Guide to NHIs That is a useful reminder that modern software risk is rarely isolated to code alone; access paths, service identities and deployment context all shape whether a vulnerability is truly reachable.
For practitioners
- Define reachability-based triage criteria Classify findings by whether the vulnerable code is actually called, reachable from user input, or exposed in production, then use that classification to set remediation priority.
- Map SCA findings to authentication and exposure boundaries Review whether vulnerable components sit behind authentication, behind network segmentation, or in internet-facing paths before assigning severity.
- Reduce duplicate findings across scanners Consolidate outputs from multiple SCA tools into one remediation view so teams work from a single prioritised queue instead of parallel alert streams.
- Track exploitability, not just CVSS Use exploit availability, code path evidence and deployment context together when deciding which dependency issues get fixed first.
- Measure the remediation bottleneck Record triage time, merge rate for fixes and backlog age so you can prove whether the new prioritisation model is actually reducing operational load.
Key takeaways
- Traditional SCA can generate more work than risk reduction when it treats every vulnerable dependency as equally important.
- Reachability analysis changes the triage question from whether a CVE exists to whether the vulnerable code can actually be hit in the deployed application.
- For practitioners, the control objective is to reduce exploitable exposure by combining code-path analysis, authentication context and remediation workflow discipline.
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 NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article focuses on exploitable code paths that attackers can use after reaching vulnerable components. |
| Recommendation — Map reachable dependency flaws to attacker paths and prioritise internet-facing code first. | ||
| NIST CSF 2.0 | PR.DS-10 — Information is protected from unauthorized disclosure during transmission | The article links exploitability to exposure paths and application boundaries in production. |
| Recommendation — Apply context-aware exposure controls so only reachable vulnerabilities are treated as urgent. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The piece is fundamentally about how to prioritise and manage vulnerabilities at scale. |
| Recommendation — Use continuous vulnerability management to rank reachable issues above noisy, non-actionable findings. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article repeatedly ties risk to exposed services and environment-specific control gaps. |
| Recommendation — Check whether exposed services and runtime settings make a vulnerability reachable before escalating it. | ||
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.
- Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.
- 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.
- Authentication boundary: The point in an application where identity is checked and access decisions begin to matter. In practice, this boundary may sit in the browser, middleware, or server. The safer design is usually the one that keeps enforcement closest to the protected resource.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security practitioners connect identity controls to the wider governance problems that modern software and cloud environments create.
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