Publishing & Disclosure

Trusted publishing lets a registry accept a release from one specific CI workflow by verifying a short-lived OIDC identity token, instead of a long-lived API token stored as a CI secret. No reusable credential exists to steal.

Deprecating leaves the version fully installable and only attaches a message the registry shows at install time. Unpublishing removes the version so it can no longer be downloaded. One is a signal, the other is a withdrawal.

Name the package identity in its ecosystem, the version where the vulnerable code was introduced, and the first fixed version on every release line you maintain. Ranges must be structured data, not prose like 'all earlier versions'.

Coordinated disclosure means the finder reports privately and gives the maintainer an agreed window to ship a fix before details go public. That window is the embargo. Full disclosure publishes the details straight away, with no window.

Because the patch describes the bug. A public diff, its commit message, linked issue and new test show an attacker exactly what was broken and how to trigger it, while every user is still running the unfixed version.

Revoking stops future publishes but changes nothing about what already went out. Anything published while the token was valid sits in consumers' caches and lockfiles, released under your name. You still have to find those versions, distrust them, and tell users.

Because the package already ran code on every machine that installed it. Removing it only changes what the next install resolves. Treat those environments as compromised: rotate every credential they could read, and rebuild what they built.

Agree a specific calendar date early, justified by real engineering work rather than convenience. When the window expires the reporter is free to publish whatever they have, fix or no fix, so an unagreed overrun becomes full disclosure.

Safe harbour authorises the testing described in the policy and promises the publisher will not pursue legal action over good-faith, in-scope research. It cannot bind prosecutors, other customers, or your own service providers.

All five, until evidence from outside the compromised credential clears them. Signatures prove the credential signed, not who authored the content, so every release verifies. Default to the whole window from your last corroborated release to the cutoff, and narrow it only with independent proof.

Usually all three in order: freeze to stop further drift, pin or override the bad transitive package as the interim fix, then roll forward to a version you can justify trusting. Order by what is fastest to undo.

security.txt is a plain-text file, standardised by RFC 9116, that tells a researcher how to report a vulnerability to you. Serve it over HTTPS at /.well-known/security.txt with at least one Contact URI and an Expires date.

A single personal account is both the availability risk and the compromise risk: nobody else can publish a fix, and one takeover owns the name. An organization spreads publishing across separately revocable identities.

The registry validates the OIDC token's signature against the issuer's keys, checks the audience names this registry, and matches the run's repository and workflow claims against the publisher a project owner registered. Only then is a package-scoped token minted.

Yanking stops the version being chosen by any new dependency resolution, but it deletes nothing: the files stay downloadable, projects that already pin it keep building, and nobody is notified. It prevents new adoption; it is not a recall.

A version range answers 'which builds contain the vulnerable code', not 'who can be hurt by it'. Keep it accurate to the code, and put the configuration precondition in the advisory text and structured fields beside the range.

Develop it out of public view: a private fork with a per-issue access list, branched from the released tag, landing as one squashed commit with a neutral message and a test that proves the fix without shipping a payload.

There is no consumer list to reach — a registry gives download counts, not identities. The only channel that reaches machines is the ecosystem's advisory feed, which flows into the scanners and update bots consumers already run. Everything else reaches humans who happen to be watching.

Not from the current lockfile, which describes today's intent. Reconstruct it from lockfile history across the exposure window, from the deployed inventory of running artifacts and their manifests, and from registry or caching-proxy pull records.

Build an inventory of every namespace you publish to, list the humans and the machine credentials that can publish to each, then revoke on current need rather than past contribution. Nothing expires on its own.

Trusted publishing authenticates which workflow published, not what it published. A malicious change merged to the release branch, a compromised step using the credential inside the job, or an owner re-pointing the registration all still produce a legitimate release.

No. Treat the token as public from the moment it was published and revoke it first. Deletion never reaches mirrors, caching proxies, local caches or anyone who already downloaded the file, and the filename can never be reused.

Both can be right. A base score is only as good as its trust-boundary assumptions, so publish the full vector and name the configuration you scored; a consumer whose product self-serves that admin role will legitimately score it higher.

Usually yes. An embargo is only worth keeping while the details are secret; once they circulate, holding protects the attackers' head start and nobody else. Confirm what leaked, tell every embargoed party the date has moved, then publish.

Pre-notify only parties who must rebuild and re-ship the affected code so their own users are protected on publication day. Operators who merely deploy it can wait for the advisory. Every extra recipient raises leak risk.

Publish the fixed artifact first, confirm consumers can actually fetch it, then make the fix public: advisory, commits, tag and notes together. Audit everything the release automation triggers, because a docs or notes job can announce the fix hours early.

Authorise isolation testing only between tenants the researcher controls: let them self-register a second trial account and probe across their own two. Real customer data stays out of scope, with an explicit stop-and-report rule.

Anything that lets an attacker back in or ship code: deploy roles, publish and registry tokens, signing keys. Then data-plane credentials ranked by what they reach. Rotation alone is not remediation — also audit what the stolen credentials already did.

A change of publishing hands is a change of trust that lockfiles cannot see. You owe a public, attributable statement of the handover, an unchanged verification path, and a deliberately boring first release with no new behaviour or dependencies.