respond-to-a-critical-open-source-maintainer-compromise

name	respond-to-a-critical-open-source-maintainer-compromise
category	code
description	Respond to a critical open-source maintainer compromise through human protection, independent project containment, source and release reconstruction, ecosystem notification, governance recovery, and verified trust replacement. Use when a maintainer identity, repository, package, signing key, or community channel may be malicious.

respond-to-a-critical-open-source-maintainer-compromise

Protect people and the ecosystem without treating one account as the whole project.

When to use

• Use for stolen maintainer accounts, coerced access, malicious releases, repository takeover, signing compromise, or impersonated project communication.
• Activate security, project governance, registry, hosting, signing, legal, privacy, safeguarding, communications, downstream, and funder authority.

Preconditions

• Establish independent incident authority, safe maintainer contact, trusted out-of-band communication, evidence custody, publication stop, and ecosystem protection.
• Inventory people, identities, repositories, mirrors, packages, registries, signing, CI, websites, domains, funding, channels, releases, consumers, and governance.

Procedure

Complete human and project containment, source and release reconstruction, ecosystem protection and clean recovery, and governance reestablishment.

1. Open a maintainer compromise timeline for identities, access, source, releases, communications, coercion or harm, decisions, and distribution.
2. Protect affected maintainers from retaliation, doxxing, coercion, account-lockout harm, and unsafe public speculation through verified private channels.
3. Preserve hosting, repository, review, CI, registry, signing, domain, communication, funding, credential, artifact, download, and downstream evidence.
4. Fence compromised accounts, sessions, keys, publishers, workflows, domains, bots, and mirrors through independently verified authority.
5. Before host or registry emergency control, create a time-limited custody charter recording why normal governance cannot act, custodian conflicts and relationships, neutral oversight, narrow allowed actions, prohibited permanent changes, signed transparency, expiry, renewal, appeal, access log, and handback.
6. Limit emergency custody to preservation, release freeze, credential fencing, malicious-version containment, authenticated safety communication, and clean recovery preparation; prohibit feature releases, relicensing, fund or trademark transfer, permanent membership, and governance amendment.
7. Reconstruct every material change and release from source, reviewers, build inputs, artifacts, signatures, registry events, and downstream execution.
8. Distinguish authorized disputed change, malicious change, vulnerable code, impersonation, and unresolved action without assuming account possession proves authorship.
9. Trace transitive packages, distributions, vendors, applications, images, caches, installations, execution, credentials, and customer impact.
10. Establish a clean project root through independently corroborated source, governance, hosting, builders, registry authority, and multiparty signing.
11. Rebuild on separate trusted infrastructure, compare artifacts, revoke old trust, issue precise advisories, and verify consumer remediation.
12. Restore maintainers and contributors through consented identity and role review; prevent emergency control from becoming permanent capture.
13. Reform quorum, succession, least privilege, review, release, signing, transparency, funding conflicts, conduct, safety, backups, and response.

Failure plan

• If a maintainer may be under coercion, prioritize safety and do not demand public proof.
• If project governance cannot establish legitimate authority, preserve state and use registry or host emergency mechanisms transparently.
• If source or bootstrap trust is unresolved, do not attest a replacement release as safe.

Worked example

A widely used cryptographic library loses two maintainer accounts to a targeted takeover while one maintainer is being extorted, a malicious version reaches package registries and Linux distributions, release signing is compromised, project chat is impersonated, and downstream vendors demand an immediate safe release. The response protects people, reconstructs source and artifacts, contains project trust, reaches consumers, rebuilds independently, rotates governance and signing, and verifies ecosystem recovery.

Done

• A maintainer compromise timeline verifies people, identities, access, source, releases, evidence, distribution, harm, decisions, and communications
• A project, source, review, builder, artifact, signature, registry, channel, and downstream reconciliation proves authorized and malicious scope, consumer exposure, trust limits, and unresolved state
• An ecosystem recovery and governance report demonstrates human protection, time-limited emergency custody, clean rebuild, advisories, consumer remediation, trust replacement, maintainer restoration, signed handback, anti-capture governance, monitoring, and independent closeout