Software supply chain attacks are becoming AI-driven and harder to contain

At a glance

What this is: Veracode’s year-in-review says software supply chain attacks are becoming more automated, more obfuscated, and more likely to target build systems and upstream dependencies.

Why it matters: This matters because CI/CD pipelines, dependency health, and artifact provenance are now security controls, not just engineering concerns, and identity-bound access in those pipelines can become the first compromise point.

By the numbers:

• 2025 saw 206,632 packages flagged as containing critical malware, an increase of 86.8% compared to the same time last year.

Context

Software supply chain attacks now exploit the gap between what teams think they are reviewing and what actually executes inside dependency and build workflows. In practice, code review, static SBOMs, and periodic scans miss the dynamic behaviours that matter most, especially when package install hooks, external downloads, and obfuscation are used to hide payloads.

The identity angle is increasingly direct: compromised maintainer accounts, CI/CD tokens, and other non-human identities are becoming the control plane for propagation. Once an attacker owns a package account or build credential, they can push malicious artifacts through trusted channels and turn ordinary automation into a distribution mechanism.

Veracode’s 2025 review makes that pattern hard to ignore. The article’s examples are consistent with a broader shift from one-off malicious packages to repeatable compromise paths that weaponise developer trust and pipeline access.

Key questions

Q: What breaks when package publishing identities are compromised?

A: When publishing identities are compromised, the attacker can release malicious packages that inherit the trust of a real project. That breaks provenance, invalidates normal review assumptions, and can turn a routine dependency update into code execution. Teams should treat registry accounts, publish tokens, and CI bindings as privileged identities with lifecycle controls and alerting.

Q: Why does supply chain compromise now depend so much on CI/CD and build tokens?

A: CI/CD tokens and build identities matter because they turn infrastructure trust into distribution trust. If an attacker steals those credentials, they can produce signed or otherwise trusted artifacts from compromised runners, which makes the malicious output look legitimate even when the source repository has not obviously changed.

Q: What are the warning signs that a package or build workflow is hostile?

A: Look for obfuscated code, install-time downloads, unusual outbound requests, maintainer-account changes, and packages that modify behaviour only during installation. Those signals indicate that the real payload may not be present in the reviewable source and that execution is being deferred until the package lands in a pipeline or developer machine.

Q: Should teams prioritise SBOMs or build provenance against AI-driven supply chain attacks?

A: Build provenance should come first when the threat is active compromise of runners, tokens, and publishing identities. SBOMs remain useful for inventory and response, but they are retrospective. Provenance, isolation, and identity controls help stop malicious artifacts from being created or accepted in the first place.

Technical breakdown

Why install-time execution is now a primary attack surface

Package managers do more than fetch code. They also execute lifecycle hooks, post-install scripts, and other logic that runs before a human reviewer can inspect the final runtime behaviour. That makes install time a high-value interception point for attackers, especially when the payload is fetched from an external URL or generated dynamically. Obfuscation raises the cost of static analysis, while precompiled binaries reduce visibility into what will actually run. The key technical issue is that trust is granted upstream, but execution happens downstream inside developer and build environments.

Practical implication: Treat package installation as an execution event and block or sandbox packages that fetch external code during install.

How account compromise turns a dependency into a propagation channel

Worm-like supply chain attacks use a legitimate publishing identity to amplify reach. Once a maintainer token or package account is stolen, the attacker can update trusted packages, publish new versions, and spread laterally through downstream consumers without needing to break each target individually. In the Shai-Hulud pattern described by Veracode, the initial compromise was not the end state. It became a distribution mechanism that could exfiltrate secrets, publish internal repositories, and continue spreading through affected accounts and ecosystems. This is classic trust abuse, but at machine speed.

Practical implication: Bind package publishing to tightly controlled non-human identities and revoke any token that can publish without strong approval gates.

Why AI-driven attacks are moving toward build-system compromise

Veracode’s 2026 prediction is that adversaries will use AI agents to map dependency graphs, find weak upstream components, and generate exploits at scale. The more consequential shift is not simply better reconnaissance. It is the move from source tampering to build tampering, where compromised runners, scripts, and base images produce signed artifacts that still look trustworthy. That collapses the traditional assurance model because the artifact inherits legitimacy from the build pipeline, not just from the source repository. Continuous provenance, not static inventory, becomes the deciding control.

Practical implication: Instrument CI/CD with provenance enforcement, isolated runners, and approval controls for build identities and signing steps.

Threat narrative

Attacker objective: The attacker wants to turn trusted software distribution and build automation into a repeatable channel for secret theft, downstream compromise, and broader ecosystem propagation.

1. Entry occurs through compromised maintainer accounts, malicious package submissions, or stolen CI/CD credentials that give attackers a trusted publishing path.
2. Credential access and abuse let the attacker use package tokens, build secrets, or install-time hooks to steal additional secrets and modify downstream artifacts.
3. Escalation happens when the malicious package or compromised pipeline propagates into other packages, repositories, or environments through trusted automation.
4. Impact is wide-scale secret theft, dependency poisoning, and persistent exposure across consumers who treat the artifact as legitimate.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• 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

Software supply chain security is becoming an identity problem as much as a code problem. Veracode’s review shows that the most dangerous paths now run through maintainer accounts, package tokens, and CI/CD identities rather than only through source vulnerabilities. That means governance has to cover who can publish, who can sign, and which non-human identities can move artifacts across trust boundaries. Practitioners should treat pipeline identities as part of the software control plane.

Pipeline identity abuse is the named failure mode behind this year’s supply chain incidents. The common thread is not just malicious code, but compromised credentials that let attackers act as legitimate publishers or build actors. Once that happens, normal review and dependency controls are too late because the trusted channel has already been used. The practical lesson is to govern non-human identity lifecycle, not just scan packages after publication.

AI-driven recon makes static assurance increasingly incomplete. Veracode’s prediction that agents will map dependency graphs and weak upstream components at scale is credible because the attacker workflow is now becoming automated, repeatable, and adaptive. Static SBOMs and periodic reviews cannot keep pace with that operating model. Build provenance, runtime detection, and non-human identity governance have to move together.

Compromise is shifting from the package itself to the build system that vouches for it. Signed artifacts are only as trustworthy as the runners, scripts, and credentials that produced them. That is a governance change, not just a tooling change, because it elevates CI/CD from a delivery concern to a security boundary. Practitioners should assume that trusted output can still be hostile if the issuing identity was abused.

AI agents will widen the asymmetry between attacker speed and defender review cycles. The article’s 2026 outlook describes systematic reconnaissance and exploit generation, which will compress the time between upstream weakness and downstream exposure. That reinforces a shift from periodic inspection to continuous control of identities, provenance, and artifact movement. Teams that still govern supply chain risk as a quarterly review problem will remain exposed.

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.
• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Build provenance is becoming the governance boundary that static SBOMs could never fully provide. Once adversaries can use AI agents to map dependency graphs and compromised identities to publish malicious artifacts, the security question shifts from what is listed to what was actually built and by whom. That is why provenance, isolated runners, and signer identity control now matter more than one-time inventory.

Continuous dependency visibility is now an operational requirement, not a maturity goal. Static review cycles are too slow for obfuscated packages, install-time execution, and worm-like spread across ecosystems. Teams need live detection of suspicious install behaviour, outbound calls, and package-account changes so that trust decisions happen as close as possible to execution.

Third-party package exposure is already broad enough to make supplier governance unavoidable, with 92% of organisations exposing NHIs to third parties according to the Ultimate Guide to NHIs. In this environment, the boundary between software supply chain security and NHI governance has effectively disappeared for build and publish workflows.

For practitioners

• Harden publishing identities in package ecosystems Restrict package publishing to named, short-lived non-human identities with enforced MFA, scoped permissions, and explicit ownership review before transfer or release.
• Block install-time code paths that fetch external payloads Detect and quarantine packages that download code during pre-install or post-install hooks, especially when the payload comes from a mutable URL or obfuscated source.
• Move CI/CD to provenance-first controls Require isolated runners, signed provenance, and policy checks on build outputs so a compromised build identity cannot silently produce trusted artifacts.
• Continuously monitor dependency health and package behaviour Track obfuscation, malicious URLs, suspicious install code, and maintainer-account changes as live signals rather than waiting for periodic SBOM refreshes.
• Review secret exposure paths inside developer tooling Assume environment variables, build logs, and local developer machines may contain API keys or tokens that become useful once a package or build identity is compromised.

Key takeaways

• Software supply chain attacks are becoming more automated, more obfuscated, and more dependent on compromised identities inside publishing and build workflows.
• The scale of the problem is visible in the 206,632 critical-malware packages and the 1,062,697 packages that attempted obfuscation during 2025.
• The practical response is continuous provenance and identity control, because static SBOMs and periodic reviews do not stop malicious artifacts from being built or published.

Key terms

• Software Supply Chain Attack: A software supply chain attack targets the path software takes from source code to production. The attacker corrupts code, dependencies, build steps, or artifacts so that trusted delivery mechanisms spread malicious logic into environments that would otherwise reject direct intrusion.
• Build provenance: Build provenance is the evidence chain showing where a software artefact came from, how it was assembled, and which identities and keys were used. It is essential when teams need to prove that an embedded release was produced from trusted source and controlled inputs.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, IAM, and secrets management. It helps practitioners align identity controls with the operational realities of modern software supply chains.