Five releases went out under your identity the week your publishing service was breached — which do consumers distrust?

## Why "it verifies" is worthless evidence here A signature answers one question: *who vouched for this artifact*. During the breach the answer was, truthfully, "whoever held the publishing identity", and that was the attacker as well as you. Every release in the window therefore verifies, and a consumer running strict verification would have installed all five happily. The same applies to any attestation produced with the same identity — an SBOM or a provenance statement generated by the compromised pipeline tells you what the attacker's build claimed, not what happened. Non-repudiation is the asset that was actually stolen: you can no longer prove which statements made in your name were yours. ## Build the window from corroborated endpoints The window has two ends and only one of them is easy. - **The late end** is when the credential stopped working: revocation time, confirmed by testing that a publish now fails. - **The early end** is the last release you can independently corroborate. Not the last release you *remember* making — the last one for which evidence exists outside the compromised system. Everything between those points is suspect by default. Investigators consistently underestimate the early end, because the first malicious action is usually quiet: an attacker who obtains publishing rights often does nothing for a while, or publishes something benign to test the path. ## What counts as independent evidence Rank evidence by whether the attacker could have produced or altered it: | Evidence | Independent of the compromised credential? | | --- | --- | | A rebuild from the tagged source that reproduces the published artifact | Yes — strongest available | | Your build system's run records, with the commit each ran on | Usually, if the build system is outside the breach | | Signed commits and tags from developer keys | Yes, if those keys were not in scope | | Ticket, approval and release-checklist trail | Yes, and cheap | | The publishing service's own audit log | **No**, when the publishing service is what was breached | | The signature or attestation on the artifact | No — the attacker held the key | The last two rows are where responses go wrong. Using a breached system's logs as your source of truth means the attacker's own view of events defines your incident boundary. Where the compromise is of a managed publishing service you do not operate, you also have a vendor-trust problem: their timeline is an input to your decision, not a substitute for it, and you should ask specifically what parts of their logging sit inside or outside the compromised component. ## The asymmetry that sets the default The two errors do not cost the same. Distrusting a version that was actually fine costs your consumers an unnecessary upgrade and costs you credibility. Trusting a version that was actually malicious costs them a compromise inside their own systems, in code you asked them to run. That asymmetry is why the professional default is wide-then-narrow: publish the whole window as suspect, then clear versions individually as evidence arrives, and say publicly when you do. The opposite order — announcing a narrow set and widening it twice — is the pattern that destroys trust, because each widening tells consumers your first answer was a guess. ## Narrowing honestly A reproducible rebuild is the cheapest genuine clearance: rebuild the tagged source and compare the digest of your output against the digest of the published artifact. If they match, the published bytes came from that source, regardless of who pressed publish. Where builds are not reproducible, you fall back to weaker corroboration — matching commit to build run to publish timestamp — and you should describe that as "consistent with" rather than "cleared". ## Give people a forward path, not a backward one The reflex advice "pin to the last known-good version" fails here, because the last known-good version is often inside the window too. The remediation is a set of freshly published versions built from corroborated source under a credential you now control, each superseding one of the suspect releases, so consumers move forward rather than backwards. State the suspect set as an explicit version list and range, because that list is what goes into the advisory data their tooling consumes. ## What you owe downstream afterwards When you are the upstream, the deliverable is not just a fix but the evidence trail: which versions were published in the window, which have been cleared and on what basis, what the replacement version is for each, and the digest of every artifact you now assert is yours. Consumers with their own regulated customers will be asked these questions in turn, and the quality of your list determines whether their answer is hours of work or weeks.