AWS prescribes 24-hour cooldown for npm and pip packages
Amazon Linux's advice targets direct installs only, transitive dependencies pulled by pinned packages get no such guard, and the post is silent on whether Inspector's malicious-package detections make the window redundant.
TL;DR
AWS published a Security Blog post recommending that npm and pip users configure a 24-hour dependency cooldown, telling the package manager to skip versions published in the last day. The rationale: recent supply-chain attacks on npm were all detected and removed within hours, so a one-day lag would have neutralized them. The post shows how to override the cooldown for security patches and acknowledges that the approach leaves transitive dependencies unguarded.
The post is a vendor source giving operational advice, not a regulator issuing guidance, so the baseline is skepticism. AWS packages it as "a one-line configuration," but the mechanics are worth examining.
The cooldown works through npm's --prefer-offline flag combined with a before filter that excludes versions newer than 24 hours. For pip, it's a --index-url constraint that similarly filters by publication date. The effect: if a package version hasn't existed on the registry for at least a day, the install command won't touch it. AWS argues this would have sidestepped every recent npm supply-chain event, including the axios compromise (2 (3 hour exposure window in March 2026), the TanStack incident (30 minutes in May 2026), and the Nx s1ngularity campaign (4) 5 hours in August 2025).
What the cooldown doesn't cover
The post is candid about limits that matter. The cooldown only governs new installations triggered directly by the user or CI pipeline. If a pinned dependency is past the cooldown, the guard doesn't inspect what that dependency fetches transitively. A package that's been on the registry for a week can still pull in a malicious sub-dependency published five minutes ago, and the cooldown won't stop it.
AWS also declines to prescribe severity-based SLAs for overriding the cooldown to apply security fixes, calling that question out of scope. That's a real gap, practitioners need to decide when a CVE warrants bypassing the cooldown, and the post offers no framework for making that call.
Inspector's absence
Amazon Inspector Security Research identifies malicious packages across npm and PyPI (188,538 npm packages flagged as of May 2026, plus 12 PyPI packages) and feeds detections into Inspector findings automatically. The cooldown post doesn't mention Inspector at all. The practical question for AWS-native shops is whether Inspector's detection pipeline is fast enough to make a manual cooldown redundant. The Security Research team publishes advisories and has contributed to the OpenSSF Malicious Packages Repository since at least late 2025, but the blog offers no data on mean time-to-detection or how that compares to the 24-hour window it recommends.
None of this makes the cooldown bad advice. It's cheap, it's simple, and the threat data makes a clear case for it. But the post is best read as a partial control, one that addresses direct installs while leaving transitive risk and detection-timing questions for the practitioner to fill in.
Published ·Deep Fathom