Software supply chain risk in 2026 is shifting toward exploited code

At a glance

What this is: This is a practitioner guide to managing software supply chain risk, with the key finding that third-party code, AI-generated code, and delayed remediation now dominate exposure.

Why it matters: It matters to IAM and NHI practitioners because software supply chains increasingly carry secrets, service integrations, and delegated access paths that intersect with identity control, privilege, and pipeline governance.

By the numbers:

• 82% of organizations are now carrying security debt.
• 66% of the most critical, long-lived vulnerabilities originate from third-party code.
• Only 26% of critical vulnerabilities listed in CISA’s Known Exploited Vulnerabilities catalog were fully remediated.

👉 Read Veracode's 6 best practices for managing software supply chain risks

Context

Software supply chain risk is the exposure created when code, dependencies, build tools, and AI-assisted development all influence what reaches production. The first-order problem is not just vulnerable code, but the loss of visibility and control over what came from outside the organisation and how quickly that risk changes after release. In identity-heavy environments, the same pipelines often also move secrets, tokens, certificates, and service credentials.

The article frames a real governance gap: point-in-time scanning, reactive patching, and treating AI-generated code as trustworthy all fail once the attack surface becomes continuous. That matters for IAM and NHI because build pipelines and application delivery paths often become the place where non-human identities, secret material, and delegated access controls are created, reused, or exposed. For teams working on NHI lifecycle management, the supply chain is now part of the identity boundary.

One useful lens here is to treat the software factory itself as a governed trust chain. If dependencies, CI/CD runners, package registries, and AI coding assistants can introduce code or credentials, then security teams need control over provenance, approval, and runtime impact rather than only after-the-fact vulnerability review.

Key questions

Q: How should security teams reduce the impact of CI/CD supply chain compromise?

A: Treat build systems as privileged identity infrastructure, not just delivery tooling. Pin dependencies to immutable references, separate build from publish rights, and rotate every secret reachable from the affected pipeline. Then add runtime monitoring for runner behaviour and repository creation so compromise is detected as an identity event, not only as a malware alert.

Q: Why do third-party dependencies create more supply chain risk than first-party code?

A: Third-party dependencies expand trust beyond the team’s direct control. The risk comes from unknown maintainers, transitive packages, and update mechanisms that can change between releases. Attackers exploit that trust chain because one poisoned component can affect many downstream applications, especially when teams lack complete SBOM coverage and continuous monitoring.

Q: What breaks when organisations treat AI-generated code as automatically trusted?

A: Automated trust breaks because AI-generated code can introduce known security flaws that look legitimate at review time. If teams do not scan, label, and review that code like any other external input, they create a path for insecure logic and hidden dependencies to enter production without the usual controls.

Q: Which frameworks should guide software supply chain security programmes?

A: NIST SSDF and SLSA are the most useful starting points because they connect secure development practices to build integrity and provenance. Teams should map dependency governance, release attestation, and remediation SLAs to those frameworks, then use continuous monitoring to prove the controls are working in production.

Technical breakdown

Why point-in-time scanning misses modern supply chain exposure

Software composition analysis helps, but only at a moment in time. A library can be clean when imported and become dangerous later if a new CVE, malicious version, or compromised maintainer appears. That is why continuous third-party risk management needs a living dependency inventory, real-time threat intelligence, and policies that govern what can enter the codebase. The problem is not just missing vulnerabilities. It is that the code path from repository to runtime keeps changing after the scan completed.

Practical implication: maintain an always-current software bill of materials and alerting for newly disclosed or malicious dependencies.

How reachability analysis changes remediation priorities

Traditional severity scoring treats every critical issue as equally urgent, but exploitable risk depends on whether the vulnerable code path is actually reachable in your application. Reachability analysis checks whether the flawed function can be invoked in the runtime context, which is often a better predictor of exposure than a raw CVSS score. When combined with exploitability signals and business context, it helps teams decide which findings deserve immediate engineering effort and which are lower priority.

Practical implication: use reachability and business impact to triage vulnerabilities before assigning remediation SLAs.

Why AI-generated code should be treated as an untrusted dependency

AI-assisted development changes the trust model because generated code can introduce known flaw patterns even when it compiles and passes review. The issue is not whether the code looks plausible, but whether it has been security-tested under the same controls as human-written or third-party code. In practice, AI output belongs in the same governance lane as imported dependencies: scanned, tracked, reviewed, and blocked if it violates policy. The security control failure is assuming generation method equals assurance.

Practical implication: apply SCA, SAST, and policy checks to AI-generated code with no special exemption.

Threat narrative

Attacker objective: The attacker aims to turn trusted software delivery into an entry point for application compromise, credential exposure, or downstream compromise of connected systems.

1. Entry occurs through vulnerable third-party code, a transitive dependency, or AI-generated code that introduces a flaw into the build or application path.
2. Escalation happens when the vulnerable path is reachable in production and the issue is not prioritised because scan-only controls miss exploitability and runtime context.
3. Impact is exploitation of the application or pipeline, leading to unauthorised access, code execution, data exposure, or wider supply chain compromise.

NHI Mgmt Group analysis

Software supply chain security is now an identity governance problem as much as a code security problem. Build systems, package registries, CI/CD runners, and AI coding assistants all introduce non-human trust relationships that must be governed, not merely scanned. When those systems can create or move secrets, tokens, and deployment credentials, identity and supply chain risk converge. Practitioners should treat provenance and privilege as one control plane, not separate disciplines.

Continuous visibility is the new baseline because the risk surface changes after code review ends. A dependency that was safe on Monday may be exploited on Friday, and static scans do not capture that shift. The field needs to move from periodic assurance to continuous trust management, especially where third-party packages and AI-generated code are entering the same pipeline. Security teams should measure exposure as a living inventory problem, not a quarterly audit.

Risk-based triage should replace equal-treatment vulnerability queues. The article’s data shows why raw volume is not the issue alone. Reachability, exploitability, and business criticality define whether a finding is a real production risk or background noise. That means supply chain governance matures when security and engineering agree on which flaws can actually hurt the business, and which can wait.

AI-generated code widens the governance gap unless organisations can prove the code is security-reviewed, tracked, and constrained. The important shift is not whether AI writes code, but whether the organisation can identify where that code entered, what controls reviewed it, and what dependencies it introduced. That is where NHI and secrets governance re-enter the picture, because assistants and pipelines frequently touch credentials and service integrations. Practitioners should assume AI-assisted development increases governance burden unless explicit controls reduce it.

Structured frameworks such as SSDF and SLSA matter because they turn supply chain security into an operating model. Without a framework, teams end up with a collection of tools and a vague sense of coverage. With one, they can define ownership, evidence, and build integrity requirements across the delivery chain. The practical conclusion is that supply chain security scales when it becomes a managed programme, not a series of isolated checks.

What this signals

Secret sprawl becomes a supply chain control problem once build systems, repositories, and AI assistants all move credentials. If code delivery paths can introduce or expose secrets, then teams need a governance model that covers provenance, rotation, and offboarding in the same workflow. The relevant internal reference is the Guide to the Secret Sprawl Challenge, and the broader identity question is how quickly exposed credentials can be rendered useless.

NHI lifecycle discipline now has to extend into the software factory. Secrets, tokens, and certificates that enter through pipelines should be treated as short-lived operational identities, not static artefacts. That is why the NHI Lifecycle Management Guide matters here: identity lifecycle controls are increasingly the difference between a contained exposure and an exploitable one.

Build integrity and identity governance are converging around the same trust question. If an assistant, dependency, or CI runner can introduce code and credentials, the programme needs a way to prove what was trusted, when it changed, and who can revoke it. For teams working against that problem, the OWASP Non-Human Identity Top 10 helps frame the control gaps that software supply chains routinely expose.

For practitioners

• Implement continuous dependency inventory Maintain a complete software bill of materials for every application and service, including direct and transitive dependencies, and update it whenever builds or packages change. Pair that inventory with alerting for newly disclosed vulnerabilities and malicious package activity.
• Prioritise by reachability and business impact Score findings by whether the vulnerable function is actually reachable in your runtime and whether the affected application is business-critical. Use that combined signal to set remediation SLAs instead of treating every critical CVE as equally urgent.
• Enforce pipeline gates for untrusted code Block builds or require reviewer approval when packages violate policy, when critical vulnerabilities are introduced, or when AI-generated code has not been scanned and labelled. Treat package firewalls and CI/CD gates as preventive controls, not just reporting tools.
• Apply security controls to AI-generated code Subject AI-written functions to the same SCA, SAST, and human review as any imported dependency. Do not exempt code because an assistant generated it, and track where AI tools are approved in development workflows.
• Align delivery controls to SSDF and SLSA Use SSDF and SLSA as the backbone for build integrity, dependency governance, and evidence collection. Map current practice to a target maturity level and close the highest-risk gaps first, especially where supply chain paths touch secrets or deployment credentials.

Key takeaways

• Software supply chain risk is no longer just about vulnerable libraries. It now includes AI-generated code, pipeline trust, and the movement of secrets through delivery systems.
• The evidence shows a widening control gap, with most critical long-lived vulnerabilities originating in third-party code and remediation still lagging far behind exposure.
• The practical response is continuous inventory, reachability-based prioritisation, and governance that treats build pipelines as part of the identity and trust boundary.

Key terms

• 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.
• 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.
• Package Firewall: A package firewall is a policy control that blocks disallowed, untrusted, or non-compliant software packages before they enter a codebase or build pipeline. It shifts security left by enforcing trust rules at ingestion, rather than waiting to detect problems after deployment.
• Build Integrity: Build integrity is the assurance that the software assembled and delivered to production is the software the team intended to build. It depends on controlled dependencies, tamper-resistant pipelines, and traceable provenance so that attackers cannot silently alter artefacts on the path to release.

What's in the full article

Veracode's full guide covers the operational detail this post intentionally leaves for the source:

• Step-by-step SCA, SAST, and secret-scanning integration patterns for developer workflows and CI/CD gates
• Practical examples of reachability analysis and risk-based triage for vulnerability prioritisation
• Implementation guidance for package firewall policies and remediation automation across development pipelines
• Framework alignment detail for SSDF, SLSA, and related supply chain maturity assessments

👉 Veracode's full post covers the remediation model, prioritisation logic, and framework alignment in more operational depth

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of real-world control design. It gives practitioners a shared foundation for connecting identity, privilege, and operational risk across the programmes they run.