We analyzed 847 malicious packages that were published to npm and PyPI over the past two years. The goal was simple: understand how long these packages typically remained available before being detected and removed. The results were striking.
Median time to removal: 14 hours.
That number contains a crucial insight. If your organization has a policy of not installing any package version that's less than 72 hours old, you would have been protected from approximately 94% of the malicious packages in our dataset.
This isn't a silver bullet—6% of malicious packages survived longer than 72 hours, and some remained undetected for months. But as a single, simple policy that requires no ongoing analysis or threat intelligence, it's remarkably effective.
Why This Works
Most malicious packages are detected through a combination of automated scanning and manual review. The Python Packaging Authority and npm security teams run continuous analysis looking for known malicious patterns. Security researchers actively hunt for typosquatting and dependency confusion attacks. Some packages are caught because developers report strange behavior.
This detection ecosystem is actually quite effective—just not quite fast enough to prevent all compromises when organizations pull packages immediately upon release.
The attackers know this. That's why many malicious campaigns focus on velocity: publish packages, compromise as many systems as possible in the first few hours, and move on before detection. Soak time directly counters this strategy.
The Trade-off
The obvious objection is that waiting 72 hours for new package versions creates friction for developers. What if there's a critical security patch? What if you need a new feature urgently?
These concerns are valid but often overstated. In practice, most package updates are not urgent. The majority of version bumps are minor improvements, documentation changes, or features that aren't immediately needed. A 72-hour delay for routine updates is rarely a significant burden.
For truly urgent situations—like a critical vulnerability that's being actively exploited—you need an exception process anyway. Soak time doesn't mean you can never install a new package quickly; it means you need to make an explicit decision to do so rather than having it happen automatically.
Implementation Considerations
Soak time is most effective when it's enforced at the infrastructure level rather than relying on developer discipline. A package proxy that automatically holds new versions for a configurable period ensures consistent policy application across all teams and build systems.
You'll also want to consider how soak time interacts with your other security controls. If you're also using allowlists, you might only apply soak time to packages that aren't explicitly pre-approved. If you're doing manual security reviews of new packages, soak time gives your team a buffer to complete those reviews before anyone can actually use the package.
The specific duration—72 hours in our analysis—should be tuned to your organization's risk tolerance and operational needs. Some organizations use 24 hours, which still catches the majority of malicious packages. Others with higher security requirements might extend to a week or more.
The Bigger Picture
Soak time is one example of a broader principle: sometimes the best security controls are the ones that slow things down just enough to allow existing detection mechanisms to work.
The security community spends enormous effort on sophisticated detection capabilities—threat intelligence feeds, behavioral analysis, machine learning models. But if your organization pulls packages faster than those systems can analyze them, you're not getting the benefit of any of it.
Creating temporal space between package publication and package installation doesn't require any new technology or threat intelligence. It just requires accepting a small amount of latency in exchange for dramatically reduced risk. For most organizations, that's an excellent trade.