TL;DR: Around 70% to 90% of modern applications are built from open-source components and third-party libraries, and Cycode argues that SCA now has to do more than enumerate dependencies because vulnerable packages, license exposure, and supply-chain compromise all travel through the same code paths. The real governance shift is toward reachability, policy enforcement, and remediation speed, where dependency inventory becomes an identity and access problem for software components as much as a code-quality issue.
At a glance
What this is: Enterprise SCA tools are being positioned as a control layer for dependency risk, not just a reporting layer for open-source inventory.
Why it matters: For IAM and security teams, the article matters because dependency governance increasingly intersects with third-party access, software supply chain trust, and the speed at which risky components reach production.
By the numbers:
- Around 70% to 90% of modern applications are composed of open-source components and third-party libraries.
Context
Software composition analysis is the practice of discovering open-source dependencies, third-party libraries, and their associated security and licensing risks. In enterprise environments, the control problem is no longer whether dependencies exist, but whether teams can distinguish benign usage from exploitable exposure before code is deployed.
This article sits in the software supply chain domain, but it has an identity angle because third-party components behave like delegated trust relationships. When dependency governance is weak, the organisation is effectively allowing software identities to enter the build and runtime estate without sufficient lifecycle control, which is a familiar failure pattern in NHI governance.
The article argues that modern SCA needs to move beyond enumerating packages and toward contextual risk, policy enforcement, and remediation speed. That is a typical enterprise position in 2026, but the scale of open-source reliance makes it materially more urgent than older dependency-scanning models assumed.
Key questions
Q: What breaks when SCA only inventories dependencies but does not test reachability?
A: Teams end up treating every vulnerability as equally urgent, which creates alert fatigue and wastes remediation effort on code paths that may never execute. The control fails because inventory alone cannot distinguish actual exposure from theoretical exposure, so the organisation loses prioritisation and slows response on the issues that matter most.
Q: Why do third-party libraries create so much application risk?
A: Because teams often depend on code they did not write, fully review, or even know is present in production. Third-party and transitive libraries can carry known vulnerabilities, hidden dependencies, or malicious packages. That makes software composition analysis a core control, not an optional review step.
Q: What do AppSec teams get wrong about open source licence compliance?
A: They often treat it as a legal review problem rather than a pipeline control problem. That leads to static checks, incomplete dependency visibility, and no handling for AI-generated code. The better model is to enforce policy where code enters and changes, with evidence captured continuously through the build chain.
Q: Should organisations prioritise build-time policy enforcement over post-release scanning?
A: Yes, if the goal is to stop risky dependencies before they become production exposure. Post-release scanning still matters for monitoring and response, but build-time controls are where teams can actually prevent insecure or non-compliant components from shipping.
Technical breakdown
Why dependency inventory is not enough
Traditional SCA tells teams what is in the codebase, but not whether a vulnerable package is actually reachable from the application path that matters. Reachability analysis reduces noise by tracing whether vulnerable functions can execute in the running code, which is what turns a long list of CVEs into a smaller set of actionable risk items. That matters because dependency sprawl creates alert fatigue when every finding is treated as equally urgent, regardless of exposure or exploitability.
Practical implication: prioritise tools that can prove exploitability, not just enumerate known issues.
How policy enforcement changes delivery risk
SCA becomes materially more useful when findings can block or gate builds, not merely report after the fact. Policy engines let teams define thresholds for vulnerability severity, license use, environment criticality, and deployment stage, then apply those rules consistently across CI/CD. This shifts SCA from a retrospective assurance activity into a control embedded in delivery, which is the point at which supply-chain risk can still be stopped before release.
Practical implication: enforce build-time policy on high-risk components instead of relying on post-release cleanup.
Why software supply chain context matters
Supply chain security in SCA is broader than dependency scanning. It also covers build processes, package provenance, and the possibility that central repositories or transitive libraries can be compromised to introduce backdoors or steal credentials. That is why contextual correlation matters: a dependency issue, a secrets issue, and a pipeline issue may combine into one attack path. The control failure is often fragmented visibility across code, build, and deployment stages.
Practical implication: correlate dependencies, secrets, and pipeline integrity in one workflow so compromise paths are visible end to end.
Threat narrative
Attacker objective: The attacker aims to turn trusted software dependencies into a scalable entry point for code execution, credential theft, or downstream compromise.
- Entry begins when a compromised open-source package or third-party library enters the software supply chain through a central repository or dependency update.
- Credential theft or backdoor behaviour can then execute inside build or runtime workflows, especially where the library has broad reach into application logic or developer tooling.
- Impact follows when vulnerable or malicious code propagates into production systems, exposing data, enabling unauthorized actions, or forcing emergency remediation across many applications.
Breaches seen in the wild
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
- Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
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
Enterprise SCA is now a reachability and trust problem, not a catalogue problem. The article’s core point is that simply knowing which dependencies exist is no longer enough when modern applications are built from deeply layered open-source and third-party components. Reachability, provenance, and policy enforcement decide whether a finding is real exposure or background noise. Practitioners should treat SCA as a decisioning layer for software trust, not a reporting layer.
Software supply chain governance now overlaps with identity governance. Third-party libraries, build systems, and CI/CD service accounts are all trust-bearing entities, and each can extend the blast radius if they are not scoped tightly. That makes dependency governance structurally similar to NHI governance: know what is present, know who or what can act, and know what happens when trust is delegated. The practical conclusion is that software components need lifecycle control, not just vulnerability scanning.
Policy enforcement is the real differentiator between visibility and control. The article emphasises prioritisation, automated gates, and remediation speed because security teams cannot manually absorb the scale of dependency sprawl. The important shift is that remediation should be driven by exposure, environment, and business criticality, not raw vulnerability count. Practitioners should align SCA policy with release authority, because that is where risk actually changes.
Contextual vulnerability triage is the named operating concept that matters here. The article repeatedly points to correlating dependencies, secrets, and infrastructure so teams can identify which findings are truly exploitable. That is the difference between a backlog and a control plane. Practitioners should use contextual triage to focus on vulnerabilities that can actually be reached from production paths and build pipelines.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: SaaS-to-SaaS and OAuth App Governance Guide
What this signals
Contextual triage will become the default expectation for enterprise SCA. Teams that still rely on raw dependency counts will keep generating more noise than value, because exposed software supply chain risk is a path problem, not a list problem. The control question is whether your programme can distinguish reachability from presence before release decisions are made.
Third-party component governance is converging with NHI-style trust management. Libraries, build agents, and pipeline credentials all behave like delegated identities when they are allowed to act inside delivery systems. That means the same discipline used for machine identity ownership, scoping, and offboarding now applies to software components and their execution paths.
Dependency risk and access risk are becoming the same conversation. When an application is built from outside code, the issue is not just whether a package is vulnerable, but whether that package can touch secrets, infrastructure, or production workflows. Practitioners should prepare for SCA programmes that are judged on reduction of exposure, not on scan volume.
For practitioners
- Implement reachability-based prioritisation Use exploitability and call-path analysis to separate theoretical dependency issues from vulnerabilities that can actually be executed in your codebase.
- Enforce policy gates in CI/CD Block builds or releases when dependency risk, license exposure, or package provenance fails your defined release policy.
- Correlate SCA with secrets and pipeline controls Review dependency findings alongside secrets detection, build integrity, and deployment context so one compromised library does not stay isolated from the rest of the control picture.
- Require SBOMs as a governance input Use SBOM generation and maintenance to keep component inventories current enough for incident response, compliance checks, and exposure analysis.
Key takeaways
- Enterprise SCA is shifting from dependency inventory toward control of what can actually be reached, executed, and released.
- The article’s scale claim, that around 70% to 90% of modern applications use open-source components and third-party libraries, explains why manual review no longer works.
- Practitioners should tie SCA findings to policy gates, build integrity, and remediation speed so dependency governance becomes an operational control rather than a reporting exercise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses 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; TA0010 — Credential Access; Exfiltration | Supply chain compromise can steal credentials and enable downstream exfiltration through trusted code paths. |
| Recommendation — Map dependency compromise to TA0006 and TA0010, then hunt for credential theft and exfiltration paths in delivery pipelines. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Third-party libraries and repositories create supplier risk that must be governed as a service-provider problem. |
| Recommendation — Apply CIS-15 to inventory supplier dependencies and review their trust impact on production systems. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest protection | SCA findings matter because compromised dependencies can expose or alter protected data paths. |
| Recommendation — Use PR.DS-01 to verify that dependency risk cannot reach sensitive data without additional controls. | ||
| SLSA | L3 — Build provenance | The article’s supply chain theme depends on knowing whether build artifacts can be trusted end to end. |
| Recommendation — Target SLSA L3 practices to improve artifact provenance and reduce build tampering risk. | ||
Key terms
- 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.
- 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 Supply Chain Security: Software supply chain security is the practice of protecting the people, code, tools, dependencies, and delivery paths used to build and ship software. It covers source integrity, dependency risk, build system hardening, artifact signing, provenance, and release controls so malicious changes are detected before software reaches production.
- SBOM: A software bill of materials is an inventory of components, dependencies, and often transitive packages used in an application or build. It gives defenders visibility into what entered the software supply chain and helps spot risky or newly introduced dependencies.
Deepen your knowledge
NHI Mgmt Group’s NHI Foundation Level course covers NHI governance, machine identity security, and secrets management as core control disciplines. It is the industry’s only accredited NHI security programme, designed for practitioners who need to govern trust-bearing identities across modern environments.
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