TL;DR: Vulnerabilities now account for 31% of initial access vectors, while 82% of organisations carry security debt and 66% of the most critical long-lived flaws originate in third-party code, according to Veracode and the 2026 Verizon DBIR. That makes software supply chain security a governance problem, not a scanning problem.
At a glance
What this is: Veracode argues that software supply chain security is moving from patch-driven defence to governance-led control because vulnerabilities, third-party code, and AI-assisted development have outgrown reactive remediation.
Why it matters: For IAM, NHI, and broader security teams, this matters because software supply chains now carry identity, dependency, and provenance risk that cannot be managed with scanning alone.
By the numbers:
- Exploitation of vulnerabilities now accounts for 31% of all initial access vectors, according to Veracode.
- 82% of organisations now carry security debt, according to Veracode.
- 66% of the most critical, long-lived vulnerabilities originate in third-party code, according to Veracode.
Context
Software supply chain security is the set of controls that governs code, packages, build pipelines, and the provenance of the components that end up in production. The core governance gap is that most organisations still treat supply chain risk as a scanning problem, even though modern applications are assembled from dependencies, third-party services, and AI-assisted code.
That creates a direct identity and trust issue as well as a software assurance issue. Dependency provenance, package integrity, and pipeline controls now determine whether the code entering production is trustworthy, while service accounts, tokens, and automated build identities often become the path through which compromised components are introduced. The article’s position is that this is a structural governance problem, not a one-off remediation problem.
Key questions
Q: What breaks when supply chain security relies on patching alone?
A: Patch-only programs miss the paths attackers actually use. A supplier can be fully patched against known vulnerabilities and still expose a reachable management interface, identity integration or privileged connection that leads into customer systems. The failure is not just weak hygiene, but the lack of path-based prioritisation across organisational boundaries.
Q: When should organisations prioritise governance over more vulnerability scans?
A: They should prioritise governance when dependencies are numerous, third-party code dominates risk, and remediation already lags behind discovery. In that situation, the bottleneck is not detection volume but control over what enters the pipeline, how it is approved, and how exposure is measured over time.
A: A common warning sign is that teams still depend on outdated practices, like static testing alone, while third-party components are entering production more quickly than security can review them. Another signal is poor visibility into asset relationships and weak monitoring of vendor or library changes. In that state, hidden dependencies become easy to exploit and hard to investigate.
Q: How should teams govern software build identities in a supply chain programme?
A: Treat build service accounts, tokens, and deployment credentials as production identities with lifecycle ownership, scope limits, and revocation rules. If those identities are overprivileged or poorly inventoried, they can become the path by which malicious code, compromised packages, or unsafe automation reaches production.
Technical breakdown
Why dependency visibility is now the first control layer
Software composition analysis, or SCA, maps the direct and transitive libraries that flow into an application. The key failure mode is that developers usually see only the top-level package, while the real risk often sits several layers deeper in inherited dependencies, malicious packages, or compromised maintainer accounts. A package firewall and provenance tracking extend visibility from inventory to trust, which is the difference between knowing what is present and knowing what should be allowed to enter the build.
Practical implication: treat dependency intake as a controlled trust decision, not just a vulnerability scan.
How AI-generated code changes the supply chain attack surface
AI coding assistants accelerate delivery, but they also amplify insecure code patterns when the model produces syntactically correct yet vulnerable output. That changes the control problem from only checking third-party dependencies to validating machine-generated code before it becomes part of the release path. The governance question is no longer whether AI is used, but whether the pipeline can distinguish acceptable output from code that introduces authentication, injection, or secret-handling flaws.
Practical implication: add automated security testing to AI-assisted development workflows before code reaches merge or deployment.
Why governance and auditability are now part of software security
A software bill of materials, remediation evidence, and trend reporting turn supply chain security from a series of ad hoc fixes into a governed capability. Without those artefacts, teams cannot show which dependencies were approved, which risks were accepted, or how quickly high-risk issues were reduced. That is why governance is central: it creates accountability for what enters the build, what remains exposed, and how risk is measured over time.
Practical implication: make SBOM generation and remediation reporting standard outputs of the release process.
Threat narrative
Attacker objective: The attacker’s objective is to insert or exploit trusted software components so compromise reaches production through legitimate build and dependency paths.
- Entry begins when an attacker exploits a vulnerable dependency, malicious package, or compromised maintainer path inside the software build chain.
- Escalation occurs when transitive dependencies, trusted libraries, or AI-generated code introduce flaws that bypass normal review and become embedded in production builds.
- Impact follows when those flaws are deployed at scale, expanding exposure across applications and making remediation slower than attacker exploitation cycles.
Breaches seen in the wild
- Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
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
Governance is now the control plane for software supply chain security. The article is right to move the conversation away from reactive patching, because patching only addresses known flaws after they are already in circulation. The real problem is that software is assembled from dependencies, build automation, and AI-generated code, which means trust decisions happen before a vulnerability is even visible. Practitioners should treat provenance, approval, and auditability as first-class security controls.
Dependency sprawl creates a hidden trust problem, not just a vulnerability problem. Transitive dependencies, package confusion, and maintainer compromise show that the most important risk is often not the package developers intentionally chose. That is why supply chain control has to include intake governance, inventory, and provenance verification, not only vulnerability detection. The practical conclusion is that organisations need a governed dependency lifecycle, not a longer scan backlog.
AI-assisted development adds a new source of security debt. When code can be generated at machine speed, the old assumption that insecure code is mostly a human error problem no longer holds. AI introduces scale, repetition, and inconsistent security quality, which means the control point shifts to validation and workflow gating. Teams should build governance around AI-generated output the same way they govern third-party code: verify before trust, and measure before release.
Software supply chain security now intersects with identity governance through build and automation credentials. Build systems, repository tokens, and service accounts are the identities that move code from source to production, so governance gaps around those credentials can become supply chain breaches. That makes NHI lifecycle control part of software assurance, not a separate discipline. Organisations should inventory and govern every non-human identity that can approve, pull, sign, or deploy code.
The named concept here is dependency trust debt. It describes the accumulation of unverified libraries, inherited risk, and delayed remediation that turns software composition into persistent exposure. The article shows that this debt is now operational, measurable, and hard to unwind once embedded in production. The practical takeaway is that teams should manage trust debt continuously rather than waiting for a major remediation campaign.
From our research library:
- Credential abuse across the entire attack chain, not just initial access, appears in 39% of all breaches, according to the 2026 Verizon Data Breach Investigations Report.
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: Secrets Management Buyer's Guide
What this signals
Dependency trust debt: software supply chain risk now accumulates when organisations keep inheriting components faster than they can verify provenance, approve changes, and retire exposure. The practical shift is from periodic scanning to continuous trust governance across code, packages, and build identities.
The identity angle is not optional here: CI/CD service accounts, API keys, and release automation credentials decide what reaches production, which makes NHI governance part of software assurance. Teams that cannot inventory those non-human identities cannot credibly claim control over their supply chain.
This is why frameworks such as the OWASP Non-Human Identities Top 10 and NIST SSDF matter together: one addresses the trust surface of machine identities, the other the software development process that those identities operate inside. Practitioners should align both rather than treating supply chain security and identity security as separate programmes.
For practitioners
- Implement dependency intake governance Require approval and provenance checks for direct and transitive dependencies before they enter the build pipeline.
- Gate AI-generated code with security tests Run automated security validation on AI-assisted code before merge, especially for injection, authentication, and secret-handling failures.
- Generate SBOMs on every release Produce machine-readable software bills of materials for each build so teams can trace what shipped, what changed, and what remains exposed.
- Track third-party risk as a measurable programme Set reduction targets for dependency-related security debt and review them against remediation progress, not just scan volume.
- Govern build and deployment identities Inventory the service accounts, tokens, and automation credentials that move code through CI/CD so they are treated as controlled production identities.
Key takeaways
- Software supply chain security has become a governance problem because third-party code, AI-assisted development, and build automation now shape production risk as much as traditional vulnerabilities do.
- The strongest evidence in the article is the persistence of third-party exposure, security debt, and delayed remediation, which makes reactive patching structurally insufficient.
- Organisations need provenance controls, SBOMs, AI code validation, and governed build identities if they want a supply chain programme that scales beyond manual scanning.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party packages and compromised maintainers are the article's core supply chain risk. |
| NHI-02 — Secret Leakage | The article links supply chain exposure to secrets in tooling and build pipelines. | |
| NHI-05 — Overprivileged NHI | Build identities and automation credentials can become overprivileged paths into production. | |
| Recommendation — Map supplier and package trust decisions to NHI-03 and block unverified third-party dependencies from release paths. Scan build and development tooling for exposed secrets and revoke any credentials that can affect release flow. Reduce the privilege scope of build and deployment identities so pipeline credentials cannot approve or ship beyond need. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes attacker paths through trusted software and compromised pipeline identities. |
| Recommendation — Map supply chain abuse to TA0006 and TA0008 to prioritise detection around credential theft and movement through trusted tooling. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Pipeline and deployment identities need explicit authorization boundaries in the supply chain. |
| Recommendation — Apply PR.AA-05 to govern who and what can approve, build, sign, and deploy software. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle and privilege control are central to CI/CD and package trust. |
| Recommendation — Use account management controls to inventory, review, and retire the non-human accounts that move code into production. | ||
Key terms
- 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.
- 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.
- 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.
- Dependency Provenance: Evidence that a package release came from the expected source, build pipeline, and repository state. Provenance matters because version numbers alone do not prove trust, and malicious actors can use legitimate-looking releases to hide harmful code.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It is designed for practitioners who need to connect identity control to broader security and delivery programmes.
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