TL;DR: Software supply chain risk has shifted from occasional dependency hygiene to a persistent exposure problem, with 82% of organisations carrying security debt and 66% of the most critical long-lived vulnerabilities coming from third-party code, according to Veracode and the 2026 Verizon DBIR. The control model now has to combine continuous inventory, reachability-based triage, and pipeline enforcement because point-in-time scanning no longer matches how code enters production.
At a glance
What this is: Veracode argues that software supply chain risk in 2026 is increasingly driven by exploited code, third-party dependencies, and AI-generated code that enters production faster than teams can govern it.
Why it matters: IAM, NHI, and application security teams need to treat third-party code, CI/CD controls, and AI-assisted development as part of the trusted execution boundary, not just a software quality issue.
By the numbers:
- 82% of organisations are now carrying security debt, up 11% year-over-year.
- 66% of the most critical, long-lived vulnerabilities originate from third-party code.
- The 2026 Verizon Data Breach Investigations Report confirms that exploitation of vulnerabilities has risen to 31% of initial access vectors.
- Veracode found that only 45% of AI-generated code passes basic security tests.
Context
Software supply chain risk is the exposure created when code, dependencies, build tools, and automated pipelines become part of the trust boundary. In this article, Veracode argues that the boundary has shifted away from the network edge and toward every external artifact that touches code before production.
That shift matters because modern delivery chains now combine open-source dependencies, third-party SDKs, AI-generated code, and multi-stage CI/CD workflows. For identity and governance teams, the important intersection is control over who or what can introduce code, packages, secrets, and build artefacts into production systems.
Key questions
Q: How should security teams prioritise software supply chain vulnerabilities?
A: Prioritise by exploitability, reachability, and runtime exposure rather than total CVE volume. A flaw that exists in a package but is never executed is lower risk than one that is reachable in production and tied to sensitive data paths. That approach reduces noise and directs remediation to the weaknesses most likely to matter operationally.
Q: Why do third-party code and AI tools increase product security risk so quickly?
A: They extend trust across dependencies that security teams do not fully own. A third-party package, model, or agent can introduce code, data, or credential exposure that crosses into the build or runtime environment, which means one weak external link can become a direct production path.
Q: What are the signs that software supply chain controls are failing in practice?
A: Common warning signs include overreliance on vulnerability lists, weak visibility into third party dependencies, limited scrutiny of developer tooling, and no practical way to audit the full software estate. If teams can only identify known CVEs but cannot assess package provenance, build trust, or dependency risk at scale, their controls are missing the real attack surface.
Q: How should teams govern code context in AI coding assistants?
A: Treat code context as a governed input, not a convenience layer. Limit retrieval to approved repositories, document which internal libraries are eligible for reuse, and require review of enriched prompts when assistants pull in project-specific logic. The goal is to ensure the assistant inherits enterprise constraints instead of amplifying undocumented code patterns.
Technical breakdown
Why point-in-time scanning misses supply chain risk
Software composition analysis at one moment in time cannot keep pace with a dependency that becomes vulnerable after it is already deployed. The security problem is not only whether code was clean at import, but whether it remains trustworthy as advisories, exploitability, and transitive dependencies change. This is why software supply chain risk management has become a continuous governance problem rather than a quarterly hygiene task. The practical challenge is inventory depth, timing, and the ability to connect a vulnerability to the application paths that actually use it.
Practical implication: Build continuous dependency monitoring instead of relying on periodic scans.
How reachability and exploitability change triage
Risk-based triage separates theoretical exposure from code paths that attackers can actually reach. Reachability analysis asks whether the vulnerable function is invoked in a real application flow, while exploitability scoring checks whether the issue is known to be weaponised in the wild or listed as a known exploited vulnerability. Together they help teams avoid wasting remediation effort on low-impact findings while critical exposures remain open. This is especially important in large CI/CD estates where remediation backlogs grow faster than engineering capacity.
Practical implication: Prioritise remediation using reachability and exploitability rather than severity alone.
Why AI-generated code must be treated as untrusted input
AI coding assistants change the supply chain because the origin of a function no longer tells you anything about its security quality. Veracode reports that 45% of AI-generated code contains known security flaws, with context-sensitive weaknesses such as XSS and log injection remaining especially weak. That means generated code behaves more like external input than vetted internal code. The governance problem is not whether AI can write code, but whether organisations can prove that AI-assisted code passed the same security controls as human-authored code before merge and deployment.
Practical implication: Apply the same scanning and review gates to AI-generated code as to any third-party dependency.
Threat narrative
Attacker objective: Attackers aim to use vulnerable code paths as the entry point into production environments and application data without relying on credential theft.
- Entry occurs when vulnerable third-party code, transitive dependencies, or AI-generated functions are introduced into the software delivery chain and shipped into production.
- Credential or code-path abuse follows when attackers exploit the vulnerable component directly, bypassing the need for stolen credentials.
- Impact comes from initial access through exploited code, which Veracode cites as rising to 31% of initial access vectors in the 2026 Verizon DBIR.
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.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
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
Exploited code has become a governance problem, not just a secure development problem. When third-party code and AI-generated snippets become the dominant source of risk, the issue is no longer only whether developers wrote secure code. It is whether the organisation can prove that every imported artefact was authorised, monitored, and kept within policy. Practitioners should treat code provenance as part of identity and access governance for software delivery.
Security debt is now an exposure inventory problem. Veracode’s figures show that organisations are accumulating unresolved vulnerabilities faster than they can remove them, and that most of the most critical long-lived issues sit in code they did not write. That changes the control objective from periodic cleanup to continuous risk ownership. Teams need a named process for deciding which external code is trusted, monitored, and retired.
Supply chain security now overlaps with NHI governance wherever pipelines and agents act on behalf of teams. CI/CD runners, build tokens, package managers, and AI coding assistants all operate as non-human actors that can introduce or propagate risky code. That means access scope, approval paths, and provenance controls around these systems matter as much as classic vulnerability management. The practical conclusion is that software delivery controls and NHI governance are now part of the same risk surface.
Reachability-based triage is the named concept practitioners should operationalise next. It is the difference between knowing a vulnerable library exists and knowing whether an attacker can actually trigger it in a live business flow. In a world where remediation backlogs are already too large, that distinction determines whether security teams reduce risk or merely generate noise. Practitioners should make reachability the default lens for backlog prioritisation.
AI-generated code should be governed as an external supply source. The article’s data shows that generated code still contains familiar flaws at unacceptable rates, so the right control model is not trust but verification. Security leaders should align policy, scanning, and review requirements so AI assistance does not become a bypass around established software assurance processes.
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.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- Read next: Ultimate Guide to NHIs — Regulatory and Audit Perspectives
What this signals
External code is now part of the production trust boundary. Security programmes that still treat open-source packages, AI-generated snippets, and build tooling as separate from access governance will keep missing where risk actually enters the environment. The control question is no longer only whether code was scanned, but whether every artefact was authorised and monitored before it was allowed to act inside the delivery chain.
Reachability-based triage should replace blanket vulnerability queues. When remediation capacity is limited, the most useful governance signal is whether a vulnerable path can actually be invoked in a business flow. Teams that can tie findings to runtime reachability will spend less time on noise and more time on exposures that change real attack paths.
For practitioners
- Map the full dependency estate Build and maintain an SBOM for every application and service, including direct and transitive dependencies, so teams can identify what is actually in production.
- Enforce ingestion controls on third-party code Set approval rules for new packages and block non-compliant or malicious dependencies before they enter the codebase or pipeline.
- Prioritise by reachability and exploitability Use reachability analysis, exploit intelligence, and business criticality to decide which vulnerabilities get fixed first.
- Treat AI-generated code like external input Apply SCA and SAST to AI-assisted code, require human security review before merge, and label generated content so it can be tracked through the SDLC.
- Harden CI/CD and developer workflows Embed scanning, policy checks, and build gates into IDEs, pull requests, and pipeline stages so risk is intercepted before release.
Key takeaways
- Software supply chain risk in 2026 is being driven less by isolated dependency hygiene issues and more by exploited code that enters production through third-party and AI-assisted pathways.
- The evidence shows a large and growing exposure problem, including unresolved security debt, critical third-party vulnerabilities, and a rising share of breaches that begin with vulnerability exploitation.
- The effective response is continuous inventory, reachability-based prioritisation, and pipeline-enforced verification of every code source before it reaches production.
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 NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0001 — Credential Access; Initial Access | The article centres on exploitation as the dominant initial access path into software supply chains. |
| Recommendation — Map supply chain exploitation to TA0001 and TA0006, then prioritise detections around exposed dependency entry points. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The topic is secure software delivery, dependency control, and code verification. |
| Recommendation — Apply CIS-16 to enforce software assurance checks across the build and release pipeline. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity of Information and Software | The article is about protecting software integrity across the supply chain. |
| Recommendation — Use PR.DS-10 to verify software integrity from dependency intake through deployment. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | The article repeatedly stresses testing, scanning, and validation before release. |
| Recommendation — Apply SA-11 to make security testing mandatory for third-party and AI-generated code. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | CI/CD and dependency controls fail when pipeline or ingestion settings are misconfigured. |
| Recommendation — Use API8-style configuration discipline to prevent unsafe build and ingestion paths. | ||
Key terms
- Software Supply Chain Risk: Software supply chain risk is the chance that code, build, deployment, or dependency paths are altered in ways that affect downstream systems. For AI code assistants, this risk rises when the tool can change source, trigger pipelines, or influence infrastructure definitions.
- 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 Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
- AI-generated code: Software produced wholly or partly by an AI model or agent rather than a human developer. The security concern is not authorship alone, but whether the resulting logic, access control, and dependency choices have been independently verified before release.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org