A provenance attestation is a statement the builder makes about itself. It binds the artifact to a workflow identity and to the repository that workflow lives in, and both of those bindings were accurate here [4]. Nothing in it binds the source tree, so a job that checks out the head of a forked pull request emits an attestation that is honest about the builder and says nothing about the code [2]. That leaves the trigger as the only thing between an outsider and a signed release, and in this repository the trigger was a comment [2]. The access control on the publish credential was a comment box.
Put the defence on the same calendar. A consumer with `min-release-age=5` in `.npmrc` would not have resolved the August 28 versions until September 2 [16]. The dispatch's case for that number is empirical: across its taxonomy of seven Shai-Hulud campaigns, every one was identified within five days [8]. The window works because other people are busy inside it, unpacking payloads and getting tarballs pulled from the registry [9].
For five days to transfer to your build, that activity has to happen for your dependency. Popularity is doing the work: a package with enough downstream weight attracts researchers and gets maintainers to deprecate fast [9], while a quiet one gives you the same five days of calendar and much less scrutiny. The dispatch is straight about the other limit. Five days buys detection time and does not make an old package safe, and a payload that sleeps past the window is untouched by the clock, which is why it presents the cooldown as a first defence rather than the plan [10].
Worth noting who is vouching for what. The taxonomy that sizes the window and the SIP plan that packages it are both the dispatch author's own work, SIP having been published on August 16 after an August 6 SafeDev Talks appearance on AI agents installing dependencies [8][12]. The outside assessment is Xygeni's npm Worm Playbook of August 21, which compared three npm supply-chain incidents and singled out the pairing of the five-day cooldown with disabled lifecycle scripts as a "genuinely sound, low-effort control", on the grounds that it attacks the detection lag every fast worm depends on [11].
Of everything in place around that workflow on August 28, the control that would have kept those ten versions out of a build decides on publication date and never opens the tarball [1][6].
