Application security has reached a crossroads between velocity and security. In the past, teams focused on the risks of outdated dependencies, which tend to accumulate known vulnerabilities, and prioritized upgrading as quickly as possible. Over the past year, we’ve seen the risks on the other side. Newly released dependencies can be malicious, turning rapid upgrades into a potential attack vector rather than a safeguard.
Datadog’s 2026 State of DevSecOps report, released in February, found that updating to new software versions within a day of release comes with its own risks. Half of the organizations in scope used at least one dependency within a day of its release, with JavaScript applications slightly above average at 54%. A single malicious dependency is enough to compromise an organization.
What happened
At this point, what hasn’t happened? Axios is the latest in a series of compromised npm packages delivering malicious software. Axios was a particularly impactful target, as it has over 100 million weekly downloads, and 174,000 other npm packages depend on it. Before that, we saw s1ngularity and both Shai-Hulud attacks, compromising over 1,300 npm packages in total.
Supply chain compromises have not been limited to JavaScript. Attackers have also targeted ecosystems like GitHub Actions and Python. For example, TeamPCP used compromised credentials to publish malicious versions of Trivy, which impacted both GitHub Actions workflows and Docker images. As part of the same campaign, attackers also released two compromised versions of LiteLLM on PyPI, embedding malicious code as part of a broader supply chain attack.
A look into npm
Npm is the most popular JavaScript package manager, with over 17 million developers relying on it. At first glance, npm looks like a success story: massive ecosystem, incredible reuse, and unparalleled developer velocity. Those same strengths create the ideal conditions for supply chain attacks to spread faster and further than in almost any other language ecosystem.
Modern JavaScript applications rarely depend on just a handful of packages. Instead, they pull in hundreds or thousands of transitive dependencies, most of which developers never review or even see. When you install a package, you install its entire supply chain. Even if you don’t use a dependency directly, one of your other dependencies probably does. The blast radius of a single malicious package is effectively unbounded. This is exacerbated by the rise of vibecoding, as it is difficult to track which library versions a coding agent is using.
Most npm packages are maintained by a single developer or a small team. Attackers only need to compromise one account to gain access to a package’s release pipeline, which is exactly what happened in the Axios compromise. Attackers have increasingly targeted high-profile maintainers, indicating that major compromises are likely to continue. GitHub, the owners of npm, has recommendations for npm maintainers, but those measures alone are not always sufficient.
Npm is optimized for speed: Publishing a new version takes seconds, and the version is instantly available worldwide. CI/CD pipelines also often pick it up immediately. This speed is what makes npm uniquely dangerous. In other ecosystems, friction exists, usually due to slower adoption cycles, more manual dependency management, or organizational gates that create natural checkpoints. Npm has none of that. A malicious version can propagate within minutes, with no human interaction.
Semantic versioning
Semantic versioning in npm is designed to make dependency management safer and more predictable, but in practice it expands the trust boundary in ways developers rarely consider. By allowing version ranges like ^ and ~, npm applications can automatically accept future updates that are assumed to be non-breaking. The problem is that non-breaking doesn’t mean non-malicious. When you specify a range instead of a pinned version, you’re implicitly trusting future code. In a world where attacker-controlled releases are the new reality, semantic versioning becomes a mechanism for silently introducing untrusted code into your application.
// package.json
"dependencies": {
"dep_1": "^1.0.0", // accept any compatible minor version
"dep_2": "~2.2.0", // accept any compatible patch version
"dep_3": "3.2.2", // pinned: only accept this exact version
},Dependency cooldowns
A dependency cooldown is an intentional delay before a newly published package version is eligible for installation. This practice has gained traction after recent incidents. Cooldowns preserve the benefits of staying current while reducing the risk of pulling in a freshly published malicious package. A cooldown of one week, or at minimum one day, would have blocked the spread of malicious versions in the Axios compromise.
Cooldowns are especially important for JavaScript. Npm recently added a minimum release age configuration (available starting in version 11.10.0, released in February of 2026), delaying installation until a version has been available for a defined period.
# .npmrc
min-release-age=7In September 2025, months ahead of npm’s feature addition, Yarn and pnpm released configurations that enforce a minimum package age.
# pnpm-workspace.yaml
minimumReleaseAge: 10080 # 7 days, in minutes# .yarnrc.yml
npmMinimalAgeGate: "7d"Dependabot also offers a cooldown setting that postpones automated dependency updates. It provides the most configurability of the three options: You can set different cooldown lengths by semantic version type (patch, minor, or major) and apply it across all supported package ecosystems, including npm, Yarn, and pnpm, as well as GitHub Actions and Python.
# dependabot.yml
- package-ecosystem: "npm"
cooldown:
default-days: 7How cooldowns would have helped
The Axios malicious versions were discovered roughly three hours after release. In the s1ngularity attack, the compromised packages were live for around four hours, with an additional hour required to revoke attacker access. In both cases, a cooldown of 12 hours would have blocked the spread entirely. Twelve hours is an aggressive lower bound; one week is the commonly recommended guidance.
What cooldowns cannot protect against
Dependency cooldowns are not foolproof. As cooldowns become widespread, patient attackers may delay malware execution to survive the waiting period. Code that doesn’t execute on install takes longer to discover. GuardDog and similar tools can detect malicious packages, but only when detection rules exist for the specific indicators an attacker uses.
Cooldowns also do not protect against traditional dependency vulnerabilities, such as cases where code is unintentionally insecure, as with Spring4Shell. Those vulnerabilities exist in already-published packages and would clear any cooldown window.
How Datadog can help
Datadog Code Security customers can use Software Composition Analysis (SCA) to identify hosts, containers, and build environments that have compromised packages installed. The emerging threats feed surfaces newly identified malicious packages so that teams can assess exposure quickly.
Datadog has also released two open source tools to defend against supply chain attacks. GuardDog analyzes npm and PyPI packages for malicious indicators before installation. Supply-Chain Firewall blocks installation of known malicious or vulnerable packages at the developer workstation.
