The 14-day rule that runs orthogonal to your code audit

You can read every line of a package and still miss the attack.

Not because you read poorly. Because the attack you’re worried about isn’t living in this version’s code. It’s living in the gap between publish and detection, and your audit doesn’t measure that gap.

I learned this rebuilding my own install discipline last week. The artifact was a new gate, sitting in front of everything else. Hard 14-day wait on every third-party install. No exceptions. Not Anthropic, not Google, not Microsoft. Tier-1 publisher status doesn’t exempt you, because tier-1 publisher status isn’t what the gate measures.

Let me walk through why.

i.The gap audits don’t catch

I had a five-gate audit running for any third-party code coming into my system. Provenance (who published it, can I verify), install-time execution (does the installer run arbitrary code on my machine), runtime surface (what does it actually do once running), dependency tree (what does it depend on, transitively), reproducibility (could I rebuild this from source and get the same thing).

Five gates. Solid coverage. Each one examines THIS version’s content.

That’s the hole.

A code audit examines what exists in front of you right now. Provenance asks who signed this. Install-time exec asks what this installer does. Runtime surface asks what this binary does. None of those gates can examine the question that actually matters for a class of attacks I started catching in the historical record:

Has anyone else looked at this yet?

Because some attacks aren’t in the code. They’re in the publication. They’re in the credentials of whoever published it. They’re in a maintainer account that got compromised three days ago. The code looks clean because the audit is reading what the attacker wanted you to read. The signal that the attack exists doesn’t live in the code at all. It lives in the post-publication community detection cycle.

That cycle takes time.

ii.The pattern in the historical record

I went looking for cases. Three came back in five minutes.

xz utils, 2024. A maintainer (“Jia Tan”) spent two years building trust on an open-source compression library shipped in nearly every Linux distribution. In February 2024 they pushed a malicious update that backdoored sshd authentication. Detected within five weeks by a Microsoft engineer who noticed unusual CPU usage during ssh logins. Wide-scale damage averted because of the catch. The malicious version had been published, signed, and was sitting in distribution feeds for weeks.

event-stream npm package, 2018. Maintainer transfer (the original maintainer handed the package off to someone who’d offered to help). New maintainer pushed a malicious dependency that targeted Bitcoin wallet code in downstream applications. Detected within about eight days when a developer flagged the suspicious dependency on GitHub. Millions of weekly downloads in the window.

ua-parser-js, 2021. Maintainer credentials compromised. Attacker published three malicious versions that ran a coin miner and a credential stealer on install. Detected within about four hours of publish by community automated scanners, but downloads of the malicious versions had already happened.

Three different mechanisms. One time-window where each was detectable. None of these would have been caught by reading the code at install moment. The provenance gates would have passed (legitimate publishers, valid signatures). The install-time exec gate would have either caught some (ua-parser-js, where the harm WAS in the install script) or missed others (xz, where the harm was in the binary library it shipped). The audit-the-content approach is necessary and not sufficient.

What stops these attacks is detection time. Other people read the code, ran the binaries, noticed the anomalies. The defense isn’t in the inspection. The defense is in the waiting.

iii.The rule

Hard 14-day maturity gate. No third-party install touches my system until the version has been publicly available for at least 14 days.

The window covers the detection cycle that caught all three cases above and most others I found in research. Most supply-chain compromises that get caught in modern open-source land get caught within 5 to 10 days of publish. Fourteen days gives that cycle a comfortable buffer. Not exhaustive, not perfect, just statistically generous.

No exemptions. Not for urgent bug fixes (the urgent bug fix is when the attacker is counting on you to skip the wait). Not for tier-1 publishers (Anthropic’s npm token could get phished; Google’s signing infrastructure could get compromised; the attack vector isn’t “publisher legitimacy,” it’s “publisher credentials at the moment of this specific release”). Not for “I’ve been using this library for years” (you’ve been using the trusted previous versions; this new version is a different artifact).

The rule applies to the release, not the project.

iv.Why tier-1 doesn’t exempt

This is the part that took a beat to sit with.

I keep a list of trusted publishers. Anthropic, Google, Microsoft, Apple, GitHub, Cloudflare, HashiCorp, Mozilla, Python Software Foundation, Node, Rust, Go, npm itself. Tier-1 publishers get a fast-path through the content gates: G1 (provenance) and G2 (install-time exec) get expedited because their signing infrastructure is more trustworthy and their releases are more reviewed. That’s a content-trust calculation.

Maturity isn’t a content-trust calculation. Maturity is a credentials-and-time calculation.

The attack mechanism is: legitimate publisher, compromised credentials, malicious release. The publisher tier doesn’t matter to the attacker. What matters to the attacker is that the credentials work for long enough to push the malicious version before the credentials get rotated. The credentials work the same way for Anthropic’s npm account as they would for a random hobbyist’s npm account. The signature is valid either way. Tier-1 status means the publisher is who they say they are. It says nothing about whether the publisher’s credentials are currently in someone else’s hands.

The 14-day wait is checking a different thing entirely: whether enough people have run this version that a compromise would have surfaced by now. Tier-1 actually makes the gate more useful, not less. More people install tier-1 releases on day one. More instrumentation watches tier-1 releases. The 14-day window for a tier-1 release is denser with eyes than the same window for a niche package. You’re getting more detection-value per day of wait.

So the rule is: tier-1 fast-paths the content gates and runs the same 14-day clock as everything else.

v.What to do with this

If you’re building any kind of install discipline, the move is: don’t conflate content audit with publication audit. They catch different attacks.

A content audit asks is this artifact safe. A publication audit asks has the community had enough time to find out if this artifact is safe. The first is necessary because some attacks live in the code. The second is necessary because some attacks live in the credential gap. You need both, running orthogonally, because the same gate can’t measure both questions.

Cost of the discipline is small. You wait two weeks before installing any new third-party release. Two-week-old releases are usually better-tested anyway. The cost of not running it is what the historical record shows: you become a downstream victim of a compromise the community will catch a week from now, and your machine is part of the attack surface in the interim.

Two weeks isn’t a lot to give up. It’s not even a velocity tradeoff for most install patterns. It’s a habit shift, nothing more. And it closes a class of attack that no amount of code reading would have caught.

The discipline isn’t reading harder. It’s waiting longer.

Drafted with Bishop, my AI partner.
Words picked, edited, and approved by me.