TL;DR
Someone finally ran the obvious test: sit between twenty-five package managers and the registries they trust, change the bytes of a legitimate package, and see who notices. Two noticed. One checks signatures without being asked. Meanwhile the controls the ecosystem is actually adopting this autumn are not cryptographic at all, they are clocks: wait a day, wait a week, let an unvalidated config expire. That is quarantine, a public health measure from 1377, and it has two preconditions that software is quietly breaking.
The test nobody runs on their own pipeline
On 14 October 2026 Trail of Bits published the result of an experiment that sounds too dull to matter. They put themselves between twenty-five popular package managers and the registries those managers trust, modified a legitimate package in transit, and recorded which installs failed.
Two noticed: Go and vcpkg. Narrow it to signature verification with default settings and the count drops to one. Go.
The rest need a lockfile, an extra flag, a separate command, or a configuration that nobody writes on a Friday. npm checks a lockfile hash when a lockfile is there. It does not check the registry signature during install, that is a different command you have to remember. Their own conclusion is the honest one: package signing sits roughly where HTTPS sat ten years ago.
Two out of twenty-five is not a gap in adoption. It is a verdict on the whole approach.
What shipped instead of identity
Look at what the ecosystem is actually putting into production this autumn. pnpm has a setting that refuses any version published less than N minutes ago. .NET 11 RC2 added a flag that writes a minimum publish age into your NuGet config. npm 12 made install scripts opt-in. And GitHub's fix for the npm Trusted Publishing flaw, announced on 2 October 2026, is that unvalidated configurations expire 48 hours after creation.
None of these verify anything. They wait.
That flaw is worth the detour, because it explains why identity lost. Trusted Publishing was the answer to stolen long-lived tokens: your CI workflow gets a short-lived credential instead. npm bound each configuration to the repository slug, owner and name, rather than to the permanent numeric IDs GitHub puts in the identity token. Rename the repo, transfer it, delete the owner account, and the old name becomes claimable by anyone with a matching workflow file.
Bloom Security reported it on 6 June 2026. GitHub validated it three days later. The last reply they got was 8 July. Six follow-ups, including a mediation request, went unanswered until the fix appeared on 2 October: 118 days, more than 1.500 packages exposed, over 10 million downloads behind them. A release published through that hole carried a valid provenance attestation naming the attacker's repository.
Ragusa, 1377
In 1377 Ragusa, today Dubrovnik, wrote into law a thirty day isolation period for arrivals from plague ports. They called it trentino. Other cities stretched it to forty days and gave us the word we still use.
Quarantine never required knowing what the pathogen was. It bought the time for the disease to declare itself, and it worked.
This is precisely what a minimum release age does. It does not inspect the package, it does not verify the publisher, it waits for a stranger to report the poison. The current detection window for malicious npm versions runs between one and twenty-four hours after publication, so a one day delay catches most opportunistic attacks. As security goes, it is unglamorous and effective, which in my experience is the only combination that survives contact with a real pipeline.
Why this matters for your business
Quarantine has two preconditions, and software is breaking both.
The first is that someone outside has to be watching, because the clock only buys time if a human reports the sample. That watching is done by unpaid maintainers and a handful of vendor research teams, and it is the one line item nobody puts in a security budget.
The second is that the clock has to be slower than the attack. Bruce Schneier, writing on 10 September 2026, put the problem in one line: "Give an AI agent a mere rumor of an exploit, and it's enough for them to find it."
Then there is who installs packages now. Bloom's telemetry puts agent-driven installs at roughly seventy packages a month on a typical endpoint and around three hundred and fifty on a developer machine, dependencies excluded. An agent that has to wait a week before it can use a dependency is not an agent. It is a ticket.
So the board question is not whether your SBOM is clean. It is this: what is your minimum release age, who exactly are you counting on to notice first, and what do your agents do while they wait?