Software supply chain attacks are shifting toward deceptive package compromise

At a glance

What this is: This is Veracode’s Spring 2026 analysis of software supply chain threats, finding a sharp rise in typosquatting, malicious URLs, obfuscation, and suspicious install-time behaviour.

Why it matters: It matters because developer package trust is now an identity and access problem as much as a code quality issue, with malicious dependencies able to reach build systems, secrets, and downstream environments.

By the numbers:

• NPM is growing the fastest and accounts for 65.9% of the packages we see.
• 4,708 packages were identified as typosquats, indicating a concerted effort by attackers to trick developers into installing malicious versions of popular packages.

👉 Read Veracode’s Spring 2026 threat research on software supply chain attacks

Context

Software supply chain security fails when trusted package selection, build-time execution, and dependency provenance are treated as separate problems. In practice, attackers exploit the gap between what developers intend to install and what actually executes during the build, especially in high-velocity ecosystems such as NPM. This is also where identity governance starts to matter, because package trust, developer entitlements, and build-system access form a single control surface.

Veracode’s analysis shows attackers are leaning into deception, not just technical exploitation. Typosquatting, malicious URLs, obfuscated payloads, and install-time scripts turn ordinary package workflows into delivery channels for malware and command-and-control activity. That starting position is now typical for modern supply chain risk, not an edge case.

The identity angle is broader than human logins. Build pipelines, automation tokens, service accounts, and secrets stored for CI/CD all become part of the attack path once a malicious package lands in the environment. That means software supply chain risk now intersects directly with NHI governance, secrets management, and least-privilege controls.

Key questions

Q: What breaks when malicious package installs are allowed to execute code by default?

A: Malicious packages can run before review, harvest tokens from the local environment, and create persistence through repositories or automation paths. The break point is not just endpoint compromise. It is the collapse of trust between dependency installation and identity governance, because secrets become reachable during package acceptance rather than after deployment.

Q: Why do typosquatted packages create outsized supply chain risk?

A: Typosquats succeed because developers and automation often trust package names more than provenance. A single mistaken install can place malicious code inside a high-trust workflow, where it may execute automatically and persist through downstream builds. The risk is amplified when package managers, registries, and CI systems do not enforce namespace validation and approval controls.

Q: What do security teams get wrong about software supply chain risk?

A: They often focus on known vulnerabilities inside dependencies and miss the trust path that delivers the software. Signed artifacts, build integrity, and separation of duties matter because attackers frequently abuse the pipeline rather than the package itself. Supply chain governance has to cover provenance, promotion, and update trust.

Q: How should teams govern secrets in infrastructure as code pipelines?

A: Teams should keep secrets out of code and move them into a dedicated runtime secrets service, then enforce policy that prevents repository storage and console exposure. The goal is to make credential lifecycle controls independent from the IaC repository, so revocation, rotation, and access review can happen without editing infrastructure templates.

Technical breakdown

How typosquatting turns package trust into an access problem

Typosquatting works by exploiting human selection error in package managers. An attacker publishes a lookalike package name, and the developer or build process installs it instead of the legitimate dependency. Once trusted by the pipeline, the package can execute code, fetch a second-stage payload, or probe the environment for secrets and internal endpoints. The security failure is not just malicious code. It is the assumption that package names alone are a reliable trust signal.

Practical implication: enforce package allowlists and namespace controls before a dependency reaches the build path.

Why install-time code execution is the critical exposure window

Packages that run suspicious code during installation can execute before static review, production scanning, or runtime monitoring has any chance to intervene. That makes the build stage a privileged execution environment, not a passive staging area. Attackers use this window to pull additional content, establish external connections, or inspect the local environment for credentials and configuration data. In identity terms, the build agent becomes a high-value non-human identity with excessive trust if it can execute arbitrary install hooks.

Practical implication: treat build-time execution as privileged and restrict install hooks, outbound network access, and secret exposure in CI/CD.

Why obfuscation and malicious URLs defeat conventional scanning

Obfuscation raises the cost of detection by hiding payload logic behind packing, encoding, or layered scripts. Malicious URLs extend that by making the initial package only a delivery mechanism for remote code or stolen data. Together, they create a multi-stage chain that is harder for simple signature-based scanners to catch. The control problem is therefore not just malware detection. It is provenance, behavioural analysis, and network restriction across the software delivery path.

Practical implication: combine provenance checks with behavioural detection and outbound network controls for package install activity.

Threat narrative

Attacker objective: The attacker wants to use trusted package workflows to execute code inside development and build environments, steal credentials, and deliver downstream compromise at scale.

1. Entry occurs when developers or automated pipelines install a typosquatted or otherwise deceptive package from a public registry.
2. Escalation happens when install-time code executes, reaches malicious URLs, or runs obfuscated payloads that inspect the environment for secrets and internal connectivity.
3. Impact follows when attackers gain access to build credentials, inject secondary malware, or propagate compromise into downstream applications and users.

NHI Mgmt Group analysis

Deceptive package compromise is now a governance problem, not just a malware problem. The article shows attackers increasingly rely on typosquatting, malicious URLs, and obfuscation to exploit developer trust at install time. That means the control failure is upstream of production security. Security teams need package provenance, policy enforcement, and build-system hardening in the same conversation.

Build pipelines behave like non-human identities and should be governed that way. When install hooks can run with access to secrets, tokens, and internal services, the pipeline itself becomes a high-privilege actor. That creates a direct NHI governance issue: over-scoped automation can transform one malicious dependency into broad access. The right lens is lifecycle control, not just malware detection.

Package ecosystem concentration creates an attack surface that is both technical and behavioural. NPM’s scale makes it attractive, but the article’s numbers also show attacker selection of user error as the main entry point. Dependency trust drift: this is the gap between what a team believes it is installing and what actually executes. Practitioners should reduce that drift through allowlists, provenance checks, and restricted installation paths.

Malicious install-time activity compresses detection and response windows. If code executes during installation, the traditional assumption that review happens before execution no longer holds. That forces a shift toward pre-install policy, network containment, and secrets exposure controls. For identity teams, the practical conclusion is that CI/CD entitlements and secret access must be audited as aggressively as human privilege.

Software supply chain security now depends on identity governance across developers, automation, and workloads. The article’s findings reinforce that compromise often enters through trusted packages but persists through privileged execution contexts. The result is an identity problem distributed across people, service accounts, and tooling. Practitioners should align supply chain controls with IAM, PAM, and NHI oversight rather than treating them as separate programs.

What this signals

Software supply chain risk is converging with identity governance because build systems, automation tokens, and service accounts now sit inside the attack path. The practical response is to treat dependency resolution as a privileged workflow and apply policy before execution, not after compromise is already visible.

Dependency trust drift: the gap between intended packages and executed code is becoming a measurable control problem. Teams should expect more attacks that blend human typo exploitation with automation abuse, which means provenance, secret scoping, and pipeline isolation need to be managed as a single programme. That is where identity controls and supply chain controls finally meet.

A useful external reference point is the OWASP Non-Human Identity Top 10, because the same governance weaknesses that affect service accounts and API keys also affect CI/CD tooling. When build agents can reach secrets and production paths, they function as non-human identities that require lifecycle control and least privilege.

For practitioners

• Implement package provenance controls Require package signing, registry allowlists, and namespace validation before dependencies can enter build pipelines. Pair this with internal mirrors for critical ecosystems so developers do not resolve packages directly from the public internet. This reduces the impact of typosquatting and malicious package substitution.
• Restrict install-time execution in CI/CD Disable or tightly constrain install hooks where possible, and isolate build jobs so package installation cannot freely reach secrets stores or internal services. Treat CI runners as privileged non-human identities with scoped, time-bound access rather than shared automation infrastructure.
• Separate build credentials from production secrets Use distinct service accounts and short-lived tokens for build jobs, and ensure build environments cannot read production secrets by default. If a malicious package executes, the blast radius should stop at the pipeline boundary instead of extending into downstream systems.
• Add behavioural detection for dependency activity Monitor install-time network calls, obfuscation patterns, and unexpected file creation or script execution during package installation. Signatures alone will miss many of these cases, so detection should focus on abnormal behaviour in the dependency resolution and build stages.

Key takeaways

• Software supply chain compromise is shifting toward deceptive package selection, install-time execution, and obfuscation rather than older misconfiguration-only attacks.
• The evidence shows scale and acceleration, with 555,258 obfuscated packages, 42,313 malicious-URL packages, and 4,708 typosquats in the reported period.
• Practical defence now depends on provenance, restricted build privileges, and treating CI/CD automation as governed non-human identity.

Key terms

• Typosquatting: Typosquatting is the practice of publishing a package name that closely resembles a legitimate dependency so developers or automation install it by mistake. In software supply chain attacks, the goal is to place malicious code inside a trusted workflow and execute before the error is detected.
• 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.
• Dependency Trust Drift: Dependency trust drift is the gap between the package a team believes it is approving and the code that actually executes in the build pipeline. It emerges when names, registries, and automation are treated as sufficient trust signals, even though attackers can manipulate each layer.

What's in the full report

Veracode’s full report covers the operational detail this post intentionally leaves for the source:

• Quarter-by-quarter package behaviour breakdowns across malicious URLs, obfuscation, suspicious install code, and typosquats.
• Campaign-level examples showing how attackers shift from dependency confusion to human-error-driven compromise.
• The article’s discussion of the OpenClaw-related package spike and how it changes malware hunting.
• Context on the Axios npm account compromise and why high-trust dependencies amplify downstream exposure.

👉 Veracode’s full report covers the package behaviour trends, campaign examples, and OpenClaw-related ecosystem shift in more detail.

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 helps practitioners connect identity governance to the operational realities of automation, privilege, and access risk.