Software supply chain attacks are shifting toward deceptive package compromise

At a glance

What this is: Veracode’s Spring 2026 Threat Research Review says package attackers are moving away from dependency confusion and toward typosquatting, malicious URLs, and obfuscated install-time malware.

Why it matters: This matters because software supply chain defence is now as much about package trust decisions and build-time controls as it is about post-install detection.

By the numbers:

• Veracode identified 4,708 typosquats in the latest review.
• Veracode said NPM accounted for 65.9% of the packages it saw.

Context

Software supply chain security is increasingly shaped by how packages are discovered, trusted, and installed, not just by whether code is signed or scanned after the fact. In this review, Veracode argues that attackers are exploiting developer behaviour, package ecosystem concentration, and installation-time execution to reach build systems before production controls can intervene.

The identity angle is indirect but real: package compromise often turns trusted third-party dependencies into delivery channels for malicious code, secrets theft, or downstream compromise. That makes software supply chain governance a problem of trust boundaries, not simply a code-quality issue.

Key questions

Q: What breaks when package trust is based only on name similarity and repository popularity?

A: Teams lose the ability to distinguish a legitimate dependency from a deceptive clone before installation. That allows malicious packages to enter build systems, execute install-time code, and reach secrets or network resources before scanners or reviewers can intervene. The failure is trust at intake, not just malware detection after the fact.

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 are the signs that a package ecosystem compromise is underway?

A: Warning signs include unexpected changes to package metadata, new postinstall scripts, suspicious external downloads during installation, and secrets exfiltration from developer config files such as .npmrc. A sudden maintainer lockout or account recovery issue can also be an early indicator. Teams should treat any unexplained dependency change as a potential compromise until verified.

Q: Should teams prioritise provenance controls or malware scanning for package supply chain risk?

A: Provenance controls should come first because they reduce the set of packages that can enter the pipeline at all. Malware scanning still matters, but it is downstream and can miss fast-moving or low-noise campaigns. If the source is not trustworthy, scanning a malicious package after the fact is not enough to prevent installation risk.

Technical breakdown

Typosquatting and malicious dependency delivery

Typosquatting works because developers and automation trust package names that look familiar enough to pass a quick review. A deceptive package can be installed before deeper inspection, then fetch a second-stage payload from a malicious URL or execute code during install. The real technical risk is that package registries and build tooling often treat retrieval as routine, while the attacker treats it as the entry point. Once the wrong dependency is pulled into a pipeline, downstream controls inherit that trust decision. This is why package provenance matters as much as static scanning.

Practical implication: verify package identity and provenance before installation, especially for high-reach dependencies.

Install-time execution and build pipeline exposure

Many ecosystems allow package lifecycle hooks or scripts to run during installation, which means code can execute before the application ever reaches runtime. That gives attackers a narrow but powerful window to harvest credentials, reach internal services, or stage additional payloads from the build environment. Obfuscation makes these scripts harder to flag because scanners may see benign-looking wrappers rather than explicit malicious intent. The mechanism is especially dangerous in automated CI/CD flows, where a compromised package can influence multiple builds before detection. Build systems need a stronger trust model than end-user package consumption.

Practical implication: restrict install scripts and isolate build environments so package code cannot freely reach secrets or network resources.

Why ecosystem concentration increases blast radius

When one ecosystem dominates package consumption, attacker effort naturally concentrates there because a single deceptive package can affect a broad population of builders and applications. Veracode’s data shows NPM remains the most active target, which means a compromise pattern that succeeds there can scale rapidly across teams that reuse common tooling and libraries. Concentration does not create the threat, but it does amplify the impact of package compromise and makes governance failures easier to exploit at scale. The lesson is that package risk is partly a dependency graph problem, not just a malware problem.

Practical implication: map high-impact dependency paths and apply stricter controls to packages that sit near shared build and release workflows.

Threat narrative

Attacker objective: The attacker wants to insert trusted-looking malicious code into developer workflows so it can steal secrets, deliver payloads, and propagate compromise through the software supply chain.

1. Entry begins when an attacker publishes a typosquatted or otherwise deceptive package that developers mistake for a legitimate dependency.
2. Credential access or payload delivery follows when the package runs installation code, fetches malicious URLs, or communicates with attacker infrastructure.
3. Impact occurs when the compromised package reaches build environments, enabling secret theft, secondary malware delivery, or downstream compromise of users and applications.

Breaches seen in the wild

• GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

Deceptive package compromise is replacing older supply-chain plays because attackers get more value from human trust than from noisy technical exploits. Dependency confusion becomes less attractive when package scoping improves, but typosquats and malicious URLs still succeed because they target the moment a developer or pipeline decides a package is legitimate. The control problem is shifting from detection after download to trust decisions before installation. Practitioners should treat package identity as a governance boundary, not a convenience.

Build-time execution is the overlooked identity layer in software supply chains. When package managers run scripts during installation, a dependency becomes an execution principal with access to the build context, secrets, and network. That makes the pipeline itself part of the attack surface, and it is why secret exposure and package provenance must be managed together. The practical conclusion is that pipeline policy needs to constrain what untrusted packages can do at install time.

Package trust boundary: the real failure mode is not merely malicious code, but the assumption that a package can be installed before it is trusted. This review shows how obfuscation, typosquatting, and install-time behaviours combine to defeat that assumption. Once that boundary collapses, scanning alone cannot restore it. Organisations should harden provenance, approval, and sandboxing around dependency intake.

NPM concentration makes package governance a scale problem, not just a threat-intelligence problem. High-volume ecosystems create more opportunities for deception, faster propagation of bad packages, and a larger blast radius when a trusted dependency is abused. That means software supply-chain defence has to focus on the few dependencies that can influence many systems. Security teams should prioritise the packages that sit closest to shared build and release paths.

For identity and NHI governance, package compromise is a credential-adjacent problem as much as a malware problem. Build systems, registries, and CI jobs often hold tokens and secrets that are attractive to attackers once code executes during installation. The governance lesson is to treat those credentials as high-risk NHIs with narrow scope and strong lifecycle control. If the build environment can be reached by package code, the identity model is already too permissive.

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

Package trust is becoming the decisive control point in software supply-chain defence. Obfuscation and typosquatting succeed because they move risk upstream into the build and intake process, where teams often assume the dependency list is already trustworthy. Security teams need stronger provenance gates, tighter install policies, and narrower build-time permissions if they want to reduce the blast radius of deceptive packages.

Supply-chain compromise now intersects with identity governance through build credentials and automation tokens. When package code runs during installation, it can interact with CI secrets and other non-human identities that were never meant to be broadly reusable. That is why NHI scoping and lifecycle discipline belong in software supply-chain controls, not just IAM programmes.

For practitioners

• Harden package intake controls Require provenance checks, scoped registries, and allowlists for high-risk dependencies before packages can enter development or build workflows.
• Restrict install-time execution Disable or tightly constrain package install scripts wherever possible, and isolate builds so untrusted dependencies cannot reach secrets or internal services.
• Prioritise shared dependency paths Identify packages used across many repositories or products and apply enhanced review, monitoring, and replacement plans to the most central ones.
• Treat build credentials as high-risk NHIs Scope CI tokens, rotation, and offboarding so build-time compromise cannot be reused across pipelines or third-party package interactions.

Key takeaways

• Software supply-chain attacks are increasingly succeeding through deceptive package intake, not just overt malware delivery or classic dependency confusion.
• Veracode’s review shows large-scale obfuscation, malicious URLs, and typosquats, which indicates that attacker tradecraft is optimised for developer trust and install-time execution.
• The most effective response is to harden provenance, restrict build-time execution, and treat CI credentials and package trust boundaries as linked governance problems.

Key terms

• Typosquatting: Typosquatting is the practice of naming a malicious package so it looks like a legitimate dependency with a small spelling change. In software supply chains, the goal is to get developers or automation to install attacker code before provenance or behaviour checks catch the deception.
• 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.
• Package provenance: Package provenance is the ability to prove where software came from, who published it, and whether it has been modified before installation. In MCP sprawl, weak provenance means installation can happen faster than trust can be established, which increases secret exposure risk.
• Build-Time Trust Boundary: A build-time trust boundary is the line that separates dependency installation and compilation from access to sensitive credentials or production systems. When that boundary is weak, malicious packages can turn routine automation into a path for broader compromise.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It helps security and IAM teams translate governance concepts into controls for secrets, workload identity, and machine access.