Your developers work for cyber gangs
In-house software built in March with open-source components may include malware placed there by criminals. This isn’t a developer problem. It’s a corporate risk problem.
Well, not deliberately. But if they’re building software with open-source components, there’s a chance that what they shipped last month included code placed there by criminals. And neither they nor you may know.
If your organisation builds or customises software consuming open-source components (and lots of in-house dev teams do just that) then your developers may pull packages from public registries like npm and PyPI every time they run a build. Those packages have dependencies of their own, which have dependencies of their own again. The tree goes deep, and in March 2026, three separate threat actor groups demonstrated what happens when that tree is poisoned at the root.
This is not a techie developer problem. This is a corporate risk-management issue.
Three campaigns, one month
We’ve all heard of supply-chain issues, but many people think of that concept in the physical world: Fuel, hardware and medical equipment. Most businesses are equally reliant on software and services however, and supply-chain security is just as relevant there.
And last month, that chain was broken:
TeamPCP exploited a single stolen access token from Aqua Security’s Trivy vulnerability scanner and cascaded through Checkmarx’s GitHub Actions and the LiteLLM AI gateway library, spanning five ecosystems in six days. Each compromise yielded the credentials needed to execute the next. Mandiant reported over 1,000 compromised cloud environments, with estimates that the number could reach 10,000.
GlassWorm force-pushed invisible Unicode payloads into 433 components across GitHub, npm and VS Code extensions, apparently using LLM-generated commits to blend malicious code in with realistic documentation tweaks and minor refactors.
And on 31 March, a North Korean state actor (tracked by Google as UNC1069) hijacked the maintainer account for axios, the most popular JavaScript HTTP client with over 100 million weekly npm downloads, and published two backdoored versions containing a cross-platform Remote Access Trojan. The malicious versions were live for approximately three hours before removal.
Two of the three campaigns used blockchain-based command-and-control infrastructure (Solana and ICP) that cannot be shut down through conventional domain seizure or hosting provider takedowns, because the C2 instructions are stored on immutable, globally distributed ledgers. A detailed analysis of all three campaigns is available on our blog.
The corporate risk
The uncomfortable reality for CIOs and risk officers: your organisation may have built and deployed production software during March 2026 that contains attacker-placed code. If your CI/CD pipeline ran without lockfiles, without pinned dependencies, and without suppressed install scripts, the malware executed silently, stole credentials, cleaned up after itself, and left no trace in standard audit tools.
This matters beyond the development team because of how dependency trees work. When a developer runs npm install, they install not just the package they asked for but its entire dependency chain, potentially hundreds of packages maintained by different individuals with varying security postures. The axios compromise propagated through transitive dependencies into unexpected places, including AI coding assistants and deeply nested WordPress modules. Anthropic confirmed that developers who installed Claude Code via npm during the compromise window may have pulled in the malicious version.
Test your pipeline before you ship
The integrity of your build pipeline is now a first-order security concern. Your penetration testing program should extend beyond “test the running application” to include the CI/CD pipeline itself: whether dependencies are pinned to immutable references, whether lifecycle scripts are suppressed in automated builds, whether secrets on runners are scoped to the minimum necessary, and whether you maintain a Software Bill Of Materials that lets you answer “are we running axios 1.14.1 anywhere?” in minutes rather than days. If you haven’t tested these controls, you don’t know whether they work.
Detect what prevention misses
Prevention will not catch everything. The axios malware was live for three hours, the LiteLLM compromise for a similar window. A properly configured SIEM with visibility across your endpoints, network egress and CI/CD infrastructure gives you the ability to spot indicators of compromise after the fact: unexpected outbound connections from build runners, anomalous process execution during package installation, or credential access patterns that don’t match normal activity. The axios RAT made outbound connections to its C2 server within seconds of installation. That’s detectable, but only if you’re watching.
For organisations that build software, the question is no longer whether your dependency tree contains risk. It does. The question is whether you have the visibility to know when that risk materialises, and the controls to contain it before it reaches production. Read the full technical analysis on our blog.
dotSec helps Australian organisations assess and manage software supply chain risk through penetration testing, managed SOC and SIEM services, and governance and compliance services. If you’d like to discuss your organisation’s exposure, get in touch.
