Topic starter
02/08/2026 12:12 pm
TL;DR: 2025 saw 206,632 packages flagged as critical malware, 1,062,697 packages using obfuscation, and 160,959 packages executing suspicious install code, according to Veracode Threat Research. The operational lesson is that dependency monitoring, build integrity, and secrets governance now need to be continuous, not periodic, while Shai-Hulud showed worm-like propagation through compromised NPM accounts and CI/CD paths.
Editorial analysis by NHI Mgmt Group, based on content published by Veracode: “Threat Research Year In Review – 2025”.
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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Software supply chain attacks are becoming more automated, more obfuscated, and more dependent on compromised identities inside publishing and build workflows.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:15 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Software supply chain attacks are becoming AI-driven and harder to contain