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

At a glance

What this is: This is Veracode’s year-in-review on software supply chain threats, showing that malicious package activity, obfuscation, and install-time execution all increased in 2025.

Why it matters: For IAM, PAM, and NHI teams, the key issue is that compromised tokens, CI/CD access, and exposed secrets are increasingly the entry point for supply chain compromise.

👉 Read Veracode's year-in-review on 2025 supply chain threats and 2026 predictions

Context

Software supply chain security fails when organisations treat dependency risk as a one-time review problem instead of a live operational control problem. In JavaScript and TypeScript ecosystems especially, attackers can hide malicious behaviour in package metadata, install hooks, and obfuscated payloads that evade shallow scanning.

The identity angle is direct: compromised NPM tokens, leaked secrets, CI/CD permissions, and over-privileged build systems give attackers a path from package compromise to account takeover and worm-like propagation. That makes this a governance problem for NHI, secrets management, and build pipeline access, not just a malware detection problem.

Key questions

Q: What breaks when software supply chains rely on static package review alone?

A: Static review misses the behaviours attackers use most often, including install hooks, external payload fetches, obfuscated scripts, and credential theft from build systems. A package can look harmless in its archive while still executing malicious code during installation. Security teams need runtime-aware controls, provenance checks, and secrets governance, not just signature or source inspection.

Q: Why do compromised CI/CD credentials make supply chain attacks much worse?

A: CI/CD credentials often sit at the centre of publish, build, and deployment workflows, so one stolen token can reach many repositories and environments. If those credentials are not scoped, rotated, and monitored like privileged identities, attackers can use them to publish malicious packages, access secrets, and spread laterally across trusted automation.

Q: How do security teams know whether package installation risk is under control?

A: Look for three signals: scripts are blocked or tightly governed during install, runner memory and local secrets are minimized, and package provenance is checked before deployment. If developers can still install arbitrary lifecycle hooks with broad credentials present, the risk is not under control. Strong secrets hygiene alone is not enough if execution itself remains trusted.

Q: Which controls matter most when malware spreads through trusted build tooling?

A: Prioritise isolated build runners, short-lived credentials, artifact signing, and policy enforcement on dependency installation and publishing. That combination limits both secret theft and propagation when a package or workflow is compromised. Teams should also ensure that pipeline secrets cannot be reused across environments without explicit approval and review.

Technical breakdown

Why install-time code execution is so hard to judge

Modern package managers can execute code during install through preinstall, install, or postinstall hooks. That means the malicious behaviour may not live in the visible package contents and can instead be fetched dynamically from an external URL. Security tools that only inspect the static package tarball miss the runtime path, especially when the code path changes after publication. This is why attackers increasingly hide logic behind benign-looking files and dependency chains rather than shipping obvious payloads.

Practical implication: treat install hooks as execution surfaces and inspect outbound fetches, not just package contents.

How obfuscation and malware delivery work together

Obfuscation does not create maliciousness, but it makes malicious intent harder to prove quickly. In the supply chain, that matters because defenders need to decide whether a package is safe before it lands in developer systems or build runners. Heavily obfuscated code, especially when paired with suspicious network calls, binary blobs, or encoded strings, reduces analyst confidence and buys attackers time. In practice, obfuscation is often used to conceal credential theft, environment reconnaissance, or downloader logic.

Practical implication: elevate heavily obfuscated packages for manual review when they also show network, install, or secret-access behaviour.

Why compromised NHI credentials turn package attacks into propagation events

Package compromise becomes materially worse when the attacker can use NPM authentication tokens, GitHub actions, or CI/CD secrets to spread further. Those secrets are non-human identities in practice: machine credentials that authorize publish, build, and release actions without direct human oversight. Once stolen, they can be replayed across repositories, pipelines, and package namespaces. The Shai-Hulud pattern shows that supply chain attacks now depend as much on identity abuse as on code tampering.

Practical implication: scope, rotate, and monitor NHI credentials that can publish, build, or deploy code.

Threat narrative

Attacker objective: The attacker wants trusted build and distribution channels to become a repeatable path for secret theft, account takeover, and wider malware propagation.

1. Entry begins with malicious packages, poisoned dependencies, or compromised maintainer accounts that place code into trusted repositories and build workflows.
2. Escalation occurs when install hooks, obfuscated scripts, or stolen NPM and GitHub credentials let the attacker fetch payloads, exfiltrate secrets, or publish to additional packages.
3. Impact is worm-like spread across ecosystems, plus developer workstation compromise, secret theft, and downstream supply chain contamination.

NHI Mgmt Group analysis

AI-assisted supply chain compromise is becoming an identity problem before it is a malware problem. The article shows attackers using installation hooks, obfuscation, and stolen credentials to move through trusted build paths. That means the decisive governance question is who or what is allowed to publish, build, and deploy under machine identity. Practitioners should treat package ecosystems as identity-bearing execution environments, not just software repositories.

Build systems are now high-value NHI territories, and that changes the control model. Veracode’s year-in-review points to CI/CD tokens, GitHub actions, and NPM authentication as the real enablers of propagation. Those credentials behave like privileged service accounts, which means PAM-style lifecycle controls, secret scoping, and continuous monitoring belong in the build trust model. Practitioners should stop separating application security from NHI governance when pipelines can self-replicate malicious code.

Obfuscation fatigue is becoming a practical defender problem. When more than a million packages use obfuscation, analysts cannot rely on manual review of every suspicious artifact. The named concept here is dependency trust dilution: the point at which the volume and similarity of risky packages reduces the signal value of one-off reviews. Practitioners should shift from static inspection alone to layered telemetry, behavioural detection, and provenance validation.

Continuous provenance is replacing episodic package review as the governance baseline. Veracode’s future-looking warning is that static SBOMs cannot keep pace with AI-driven dependency abuse and build compromise. That aligns with the broader market shift toward live attestation, isolated runners, and policy-enforced release paths. Practitioners should prepare for a model where trust is re-established on every build, not assumed after procurement.

Secrets exposure remains the accelerant that turns supply chain events into enterprise incidents. The article repeatedly shows environment variables, API keys, and auth tokens as the data attackers want most. That is where NHI governance, secrets rotation, and developer access controls intersect directly with software supply chain resilience. Practitioners should assume that compromised build credentials will be targeted as aggressively as source code itself.

What this signals

Software supply chain defence is moving toward continuous trust evaluation, because package ecosystems now behave like live attack surfaces rather than static source libraries. For identity teams, the next control boundary is the build pipeline itself, where privileged tokens, secrets, and release automation create the conditions for rapid propagation. That makes secret governance and provenance assurance part of the same programme, not separate workstreams.

Dependency trust dilution: the more obfuscated and behaviourally noisy the ecosystem becomes, the harder it is to distinguish malicious packages from routine developer tooling. Practitioners should expect more false positives, more time pressure on reviews, and more pressure to automate behavioural baselines using telemetry from build systems and dependency scanners. The practical response is to harden the path from package install to artifact release, not to rely on manual triage alone.

The identity signal is straightforward: if a token can publish code, trigger workflows, or access secrets, it is an NHI with meaningful blast radius. Teams should align pipeline access with least privilege, short-lived issuance, and continuous monitoring, and they should use the OWASP Non-Human Identity Top 10 as a reference point for policy gaps and control coverage.

For practitioners

• Constrain publish and build credentials Limit NPM, GitHub, and CI/CD tokens to the smallest possible scope, separate publish rights from build rights, and remove persistent access where ephemeral credentials will do the job. Review whether any token can still publish packages, trigger workflows, or access secret stores without an explicit business need.
• Inspect install-time behaviour, not just package contents Add detection for preinstall, install, and postinstall hooks, especially when they fetch code from external URLs or touch environment variables. Build pipeline policy should flag unexpected outbound requests, encoded payloads, and script execution during dependency installation.
• Harden CI/CD with provenance and isolation Use isolated runners, signed artifacts, and build provenance checks so a compromised dependency or workflow cannot silently alter release outputs. Require that build scripts run in segregated environments with restricted secret access and no unnecessary network egress.
• Rotate developer and pipeline secrets on exposure signals Treat leaked credentials, suspicious package behaviour, and workflow tampering as rotation triggers for API keys, tokens, and certificates used in development and release pipelines. Pair rotation with offboarding checks so stale credentials do not remain valid in downstream systems.
• Baseline package trust with behavioural telemetry Track installation-time execution, obfuscation density, malicious URL references, and unusual network destinations as part of a continuous package health model. Use those signals to prioritise manual review for packages that look benign at first glance but behave like loaders or credential harvesters.

Key takeaways

• Software supply chain attacks increasingly exploit build-time behaviour, obfuscation, and stolen machine credentials rather than obvious source-code malware.
• The 2025 data shows a scale problem, with more than 200,000 packages flagged as critical malware and over a million using obfuscation.
• Practitioners should move from periodic package review to continuous provenance, credential scoping, and runtime-aware dependency controls.

Key terms

• SaaS Supply Chain Attack: A SaaS supply chain attack is an intrusion path that uses trusted integrations, tokens, or third-party services to reach a target environment indirectly. The attacker relies on inherited trust between applications rather than breaking the main system first, which makes detection and containment harder.
• 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.
• 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.
• Provenance: Provenance is the traceable history of where a software artifact came from, who approved it, and what controls were applied along the way. In container security, provenance supports trust decisions because it links delivery steps to accountable identities and review points.

What's in the full report

Veracode's full year-in-review covers the operational detail this post intentionally leaves for the source:

• Per-campaign package naming patterns and indicators of compromise that help security teams tune detections.
• Detailed examples of malicious install hooks, obfuscated loaders, and exfiltration paths seen in 2025.
• The Shai-Hulud propagation chain, including how compromised authentication tokens were used to spread further.
• Veracode's 2026 predictions on build compromise, live provenance, and AI-driven supply chain attacks.

👉 The full Veracode article covers campaign details, package-level indicators, and future attack patterns.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need to connect identity governance to real operational risk across modern security programmes.