CrowdStrike announced a control this week that sits between a developer typing `npm install` and the package manager doing it. If the package is known-bad, it does not install, and its embedded scripts do not run.
The product is straightforward and probably useful. What is worth examining is the position it occupies, because a defence placed at the moment of installation is a statement about every defence placed earlier.
Installation is execution
Here is the fact that makes this entire category of attack possible, and it is a design decision rather than a flaw.
When you install a package from npm, its lifecycle scripts run. When you install from PyPI in the older style, `setup.py` executes. This is deliberate: packages need to compile native extensions, detect platforms, and configure themselves, and running code at install time is how that was solved.
The consequence is that fetching a dependency and executing untrusted code are the same action. There is no window between "the package arrived" and "the package ran" in which anybody could inspect it. A poisoned package does not wait to be imported by your application. It runs when you install it, with the privileges of whoever typed the command — often a build agent with credentials to everything.
Which is why the control has moved here
For a decade the answer to supply chain risk has been to know more about packages: bills of materials, signatures, provenance attestation, dependency scanning, pinned lockfiles. All of that is good, and all of it operates in the space before install.
It works when the intake is slow enough to review. CrowdStrike's own threat report puts the current intake rate plainly: it attributes 131 poisoned AI framework packages to one state-linked actor, and the compromise of more than three hundred dependencies in a single day to another. Those are the vendor's numbers and its attributions, and this paper has not verified either — but the order of magnitude matches what everybody in the field has been describing.
Three hundred in a day is not a review problem. It is a rate problem. And it is getting worse in a specific way, because coding agents now assemble applications by pulling packages from public registries faster than any human process ever inspected them. The reviewing layer runs at human speed and the intake runs at machine speed, and when those diverge the only remaining place to intervene is the last one.
That is the same shape as everything else this desk has written about constraints this week. The binding stage is the slowest one, and relieving the others does not help.
The pattern in where defences end up
Attackers go where the leverage is, and defenders end up wherever attackers went. This paper wrote on Friday that everybody audits the package and nobody audits the shelf it sits on, after a flaw in JFrog Artifactory let an unauthenticated attacker take administrative control of the repository every build pulls from — and was being exploited four days after disclosure.
Put the two together and the picture is uncomfortable. The repository that hands you the package can be compromised; the package itself can be poisoned; and the act of installing it is the act of running it. Signing and provenance answer the middle problem and neither of the other two.
It is the same reason firmware is the layer nobody audits and the reason organisations that cannot audit code end up auditing the vendor instead. Each control gets placed where the last one failed, and the sequence keeps moving closer to the machine.
What an endpoint control can and cannot do
It can stop a known-bad package from running on a machine that has the agent. That is real, and the visibility half — telling you where a compromised package is already installed — may matter more than the blocking half, because the expensive part of these incidents is not the initial run but finding every host that got it.
It cannot know about a package nobody has identified yet. Blocking is a detection problem wearing a prevention product's clothes: it works against the packages in the feed, on the timeline of the feed, and the window between publication and identification is exactly the window these actors operate in.
And it does nothing for machines without the agent, which on a modern build fleet is a real number.
What would actually fix it
Not another layer. Separate installation from execution.
Package managers could fetch, verify and stage a dependency without running anything, and require an explicit, auditable step for packages that need to run code at install. That would break some builds and annoy a lot of maintainers, and it would remove the mechanism the whole attack class depends on.
Nobody is going to do it, because the convenience is load-bearing for a very large amount of existing software. So the industry will keep buying controls positioned closer and closer to the moment of execution, and the honest measure of whether any of them is working is not blocked-package counts. It is the interval between a malicious package being published and being identified — because everything sold as prevention here is really a bet on that number staying small.
The announcement of CrowdStrike Real-Time Supply Chain Attack Protection at Fal.Con on 2 September 2026, its interception of package manager transactions including npm install and pip install across Windows, macOS and Linux, its blocking of packages before embedded scripts execute, and its visibility and remediation features are from CrowdStrike's own announcement and reporting by Cyber Daily and DevOps.com in September 2026. The figures of 131 poisoned AI framework packages attributed to STARDUST CHOLLIMA and more than 300 dependencies compromised in a single day attributed to ALTERED SPIDER are from CrowdStrike's 2026 Threat Hunting Report; both attributions and both counts are the vendor's own and have not been independently verified by this publication. The JFrog Artifactory vulnerability referred to here is as reported on 2 September 2026. The analysis is our own.
Topics technologysecuritysoftware supply chainopen sourcedevops
