TL;DR: Obfuscation attempts, malicious URLs, typosquats, and ecosystem concentration are shaping the latest package threat landscape, according to Veracode’s Spring 2026 Threat Research Review. The review shows 555,258 packages attempted obfuscation, 42,313 contained malicious URLs, and 4,708 were typosquats, while NPM remained the most active ecosystem at 65.9% of packages, and the pattern is moving from misconfiguration abuse to human-error-driven dependency compromise, which makes build-time trust and package governance the real control point.
NHIMG editorial — based on content published by Veracode: Spring 2026 Threat Research on key trends in software supply chain security
By the numbers:
- 4,708 packages were identified as typosquats, indicating a concerted effort by attackers to trick developers into installing malicious versions of popular packages.
Questions worth separating out
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.
Q: Why do typosquatted packages create outsized supply chain risk?
A: Typosquats succeed because developers and automation often trust package names more than provenance.
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.
Practitioner guidance
- Implement package provenance controls Require package signing, registry allowlists, and namespace validation before dependencies can enter build pipelines.
- 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.
- 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.
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.
👉 Read Veracode’s Spring 2026 threat research on software supply chain attacks →
Software supply chain attacks are shifting toward deceptive package compromise?
Explore further
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.
A question worth separating out:
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.
👉 Read our full editorial: Software supply chain attacks are shifting toward deceptive package compromise