Skip to content

Draft Policy

This is a draft policy that has been published for feedback and discussion. The policy may be implemented as is, substantially rewritten, or abandoned based on subsequent feedback.

Central Approved Remediation for Emergencies (CARE) Policy⚓︎

1. Purpose⚓︎

Maven Central exists to serve the Java and broader JVM ecosystem as a trusted distribution point for open source and other software components. In ordinary circumstances, artifacts published to Maven Central are released by the maintainers or authorized publishers of the relevant namespace.

Strong namespace protections are a hallmark of Maven Central. Central validates namespace ownership and enforces those protections as part of the publication process. Coordinates are not just labels; they are part of the trust model. Users, build tools, security scanners, repository managers, and downstream ecosystems rely on the assumption that control over a namespace is meaningful, durable, and not casually reassigned. This has long set Maven Central apart from many other registries.

That trust model remains essential. It is also the model this policy is designed to preserve.

The security landscape around open source is changing. AI-accelerated vulnerability discovery is increasing the speed and scale at which vulnerability candidates can be found, validated, and in some cases exploited. Efforts such as Akrites reflect a broader recognition that the scarce resource is no longer discovery alone, but coordinated triage, validation, remediation, publication, and deployment. The ecosystem's ability to respond safely will depend not only on finding vulnerabilities, but on getting trustworthy fixes to users through the dependency graph.

There are exceptional circumstances where strong namespace protections can come into tension with the need to respond to urgent ecosystem risk. A serious vulnerability may affect a dormant, abandoned, end-of-life, or otherwise unavailable project. The original maintainer path may be unavailable or too slow for the risk involved. At the same time, forcing downstream users to move immediately to a new namespace can delay remediation, break transitive dependency graphs, create version collisions, and leave users exposed.

This policy establishes a controlled and transparent mechanism for Sonatype, as the operator of Central, to approve narrowly scoped emergency remediation releases into existing Maven Central coordinates when doing so is necessary to protect the ecosystem.

This mechanism is called the Central CARE Program.

CARE stands for Central Approved Remediation for Emergencies.

2. Scope⚓︎

This policy applies to emergency remediation releases published into existing Maven Central coordinates where the release is not published through the ordinary maintainer-controlled process.

A CARE release may be considered when:

  • a vulnerability or security defect presents material ecosystem risk;
  • a component is end-of-life, dormant, abandoned, or otherwise lacks timely maintainer response;
  • an original maintainer is reachable but unable to publish a fix quickly enough for the risk involved;
  • a trusted remediation actor can provide a validated remediation;
  • publication under the existing coordinate materially improves remediation outcomes for downstream users;
  • Central determines that the release can be reviewed, validated, attributed, and published consistently with repository integrity.

This policy does not create a general right for third parties to publish into another maintainer's namespace. It does not create an adoption process for abandoned projects. It does not replace ordinary maintainer publication, namespace transfer, or project fork mechanisms.

3. Definitions⚓︎

Maven Central or Central means the repository operated by Sonatype for the publication and distribution of JDK artifacts, and the team doing the administration.

Sonatype means Sonatype, as operator of Central and administrator of this policy.

Original Maintainer means the person, project, organization, or publisher with ordinary authority over the affected namespace or artifact.

Original Coordinate means the existing groupId:artifactId affected by the vulnerability or emergency remediation.

CARE or CARE Program means the Central program for Central Approved Remediation for Emergencies.

CARE release means a Central Approved Remediation for Emergencies release authorized by Central under this policy.

Trusted remediation actor means a pre-approved person or organization working in coordination with Central to prepare, validate, and publish an emergency remediation.

Emergency remediation means a narrowly scoped fix, backport, mitigation, or corrective release intended to reduce material security or ecosystem risk.

Successor coordinate means a new namespace or artifact coordinate used for ongoing maintenance, future development, or a longer-term fork.

Project security team means a person, team, committee, or process designated by the original maintainer, project, foundation, or publisher to receive, triage, coordinate, remediate, or disclose security issues for the affected artifact or project.

Foundation-supported project means a project hosted by, governed by, sponsored by, or formally supported through a recognized open source foundation or similar stewardship organization that provides security coordination, vulnerability handling, project governance, or maintainer support.

4. Guiding Principles⚓︎

Central will apply this policy according to the following principles.

Ecosystem safety⚓︎

The primary purpose of CARE is to reduce material risk to the Central ecosystem and its downstream users.

Maintainer respect⚓︎

Original maintainers do not lose ownership, authorship, namespace rights, or normal publishing rights merely because a CARE release is authorized. Every effort will be made to include the maintainer(s) in any such disclosure and remediation.

Narrow scope⚓︎

CARE is for emergency remediation, not feature development, project modernization, commercial product extension, or general maintenance. Please follow the project's published processes for these scenarios.

Transparency⚓︎

CARE releases must be identifiable and accompanied by metadata describing the remediation, authority, scope, and relevant security information.

Validation⚓︎

CARE releases must be reviewed and validated by Central before publication.

Traceability⚓︎

CARE releases must include sufficient provenance, source, build, advisory, and VEX information to support downstream users, security tools, and repository integrity.

Discretion⚓︎

Central retains discretion to approve, reject, delay, supersede, annotate, or revoke CARE activity based on ecosystem risk, legal considerations, maintainer rights, technical validity, and repository integrity.

5. When CARE May Be Used⚓︎

Central may authorize a CARE release when, in Central's judgment, coordinated emergency publication into an existing coordinate is necessary or appropriate to reduce material ecosystem risk.

Severity will be considered, but no fixed severity threshold is required. A vulnerability rated low or medium may still justify CARE treatment where context, reachability, exploitability, ecosystem prevalence, transitive exposure, or public safety considerations warrant action.

Relevant factors may include:

  • vulnerability severity;
  • exploitability;
  • evidence of active exploitation;
  • prevalence of the affected component;
  • transitive dependency impact;
  • availability of existing mitigations;
  • maintainer responsiveness;
  • project dormancy or end-of-life status;
  • downstream disruption caused by moving to a new coordinate;
  • confidence in the proposed remediation;
  • licensing and redistribution considerations;
  • whether the artifact is open source, proprietary, commercial, or source-available;
  • availability of a trusted remediation actor;
  • ability of Central to validate the patch and artifact.

CARE is an exceptional mechanism. Original maintainer publication remains the preferred path.

6. Relationship to Original Maintainers⚓︎

Central will make reasonable efforts to contact original maintainers or to work with trusted remediation actors who have done so, before authorizing a CARE release.

Where maintainers are responsive and able to publish a timely fix, the ordinary maintainer-controlled process should be used.

Where maintainers are unavailable, unresponsive, or unable to act quickly enough relative to the risk, Central may authorize a CARE release.

Where ecosystem safety requires urgent action, Central may authorize a CARE release before maintainer approval or response, but this will be done as a last resort, and efforts to continue pushing fixes upstream will continue despite an emergency release.

A CARE release does not:

  • transfer namespace ownership;
  • remove or suspend maintainer publishing rights;
  • appoint the trusted remediation actor as project maintainer;
  • grant ongoing release authority;
  • imply endorsement by the original maintainer;
  • authorize feature development under the Original coordinate.

Original maintainers may continue to publish normal releases, including releases that incorporate or supersede a CARE fix.

7. Commercial and Company-Published Artifacts⚓︎

Artifacts published by identifiable commercial entities, product vendors, or companies may require different handling.

For commercial, proprietary, restricted, or company-published artifacts, Central will generally seek publisher participation or authorization before permitting third-party CARE publication into the existing coordinate.

Exceptions may be considered only where Central determines that ecosystem safety requires action and the proposed remediation can be handled consistently with applicable legal, licensing, trademark, user-confusion, and repository-integrity considerations.

Where CARE publication is not appropriate, Central may pursue other actions, including advisory metadata, VEX information, coordination with the publisher, warnings, or other repository-level measures.

8. Projects with Security Teams or Foundation Support⚓︎

Some projects have defined security teams, vulnerability handling processes, or foundation-supported governance structures capable of coordinating remediation.

Where an affected artifact is associated with a project security team or a foundation-supported project, Central will generally defer to that team or foundation-supported process for decisions about remediation, disclosure, timing, publication, and whether a CARE release is appropriate.

In these cases, CARE may still be available as a coordinated mechanism where the project security team, foundation-supported process, trusted remediation actor, and Central determine that publication under the existing coordinate is the safest or most effective path for the ecosystem.

Central may also assist with validation, metadata, VEX information, advisory coordination, or emergency publication, where requested or where doing so supports the project's chosen remediation path.

If a project security team or foundation-supported process is unable to act, cannot act in a timely manner, or requests Central assistance, Central may evaluate CARE publication under this policy.

Nothing in this section limits Central's discretion to act where ecosystem safety requires urgent intervention. Still, Central will give substantial weight to established project security teams and foundation-supported security processes.

9. Trusted Remediation Actors⚓︎

CARE releases may be prepared only by trusted remediation actors working in coordination with Central.

Trusted remediation actors must be preapproved by Central and may be approved generally, conditionally, or for a specific remediation.

Approval as a trusted remediation actor does not grant general publishing rights into third-party namespaces. Authority is limited to the specific remediation activity approved by Central.

Central may require trusted remediation actors to provide:

  • verified organizational identity;
  • secure account and signing practices;
  • vulnerability handling processes;
  • source, patch, and build materials;
  • license and provenance information;
  • SBOM and VEX materials;
  • confidentiality commitments for embargoed issues;
  • cooperation with Central validation;
  • representations about scope, provenance, and absence of hidden functionality;
  • agreement to revocation or limitation of trusted status.

Central may suspend or revoke trusted remediation actor status at any time.

10. CARE Versioning⚓︎

CARE releases must use a version identifier that clearly distinguishes the release as a Central Approved Remediation for Emergencies while preserving logical version sequencing.

The standard CARE version format is:

<base-version>.<care-sequence>-care

For example:

1.2.3          original maintainer release
1.2.3.1-care   first CARE release based on 1.2.3
1.2.3.2-care   follow-up CARE release based on 1.2.3
1.2.4          later normal maintainer release

The -care suffix is reserved for Central-approved emergency remediation releases under the Central CARE Program.

The care suffix means:

Central Approved Remediation for Emergencies

CARE versions form a controlled emergency remediation branch from a specific base version. They do not consume the original maintainer's next normal version number.

A CARE version should not include vendor names, company names, competing publisher labels, marketing identifiers, or unrelated build metadata. The identity of the remediation actor must be recorded in accompanying metadata, not encoded as a competing version label.

Publishers must not use the -care suffix unless the release has been approved by Central under this policy.

Central may approve an alternate version form only where required for compatibility, repository integrity, or ecosystem safety.

11. Metadata, VEX, and Advisory Information⚓︎

Each CARE release must be accompanied by metadata sufficient to inform maintainers, consumers, security tools, repository managers, and downstream compliance processes.

CARE metadata should identify, as applicable:

  • that the release is a CARE release;
  • the base version;
  • the CARE version;
  • the trusted remediation actor;
  • Central approval status;
  • maintainer approval, objection, unreachability, or coordination status;
  • relevant vulnerabilities, advisories, CVEs, GHSAs, OSV records, or Sonatype advisories;
  • VEX status;
  • scope of the emergency remediation;
  • compatibility impact;
  • dependency changes;
  • license review status;
  • reproducibility or validation status;
  • superseding or superseded versions.

Some metadata may be delayed, limited, or redacted where necessary for coordinated vulnerability disclosure, embargo handling, legal obligations, or ecosystem safety.

Central may expose CARE metadata through services, repository metadata, APIs, advisory feeds, VEX documents, user interfaces, or other appropriate mechanisms.

12. Submission and Validation Requirements⚓︎

Before publication, Central must be able to review and validate the proposed CARE release.

The trusted remediation actor must provide materials sufficient for Central to reproduce, inspect, and validate the patch and resulting artifact.

Required materials may include:

  • affected coordinates and versions;
  • vulnerability or advisory details;
  • exact base version;
  • source archive or source repository reference;
  • patch diff;
  • build instructions;
  • build environment details;
  • dependency resolution information;
  • generated artifact hashes;
  • tests and validation results;
  • SBOM;
  • VEX document or equivalent security metadata;
  • license and provenance information;
  • maintainer contact history, where applicable;
  • disclosure and embargo information, where applicable.

The patch must be reproducible by Central to Central's satisfaction before publication.

For older projects, strict bit-for-bit reproducibility may not always be feasible. In such cases, Central must still be able to reproduce, inspect, and validate the patched artifact sufficiently to determine that publication is appropriate.

Central may reject any proposed CARE release that cannot be adequately validated.

13. Scope of Permitted Changes⚓︎

CARE releases should be limited to the changes necessary or appropriate to remediate the identified risk.

CARE releases should preserve, to the greatest extent practical:

  • binary compatibility;
  • source compatibility;
  • public API behavior;
  • dependency shape;
  • runtime behavior;
  • licensing posture;
  • artifact identity.

Compatibility preservation is a priority but not an absolute rule. Where remediation requires compatibility-impacting changes, those changes must be justified and disclosed in CARE metadata.

CARE releases should not include:

  • unrelated feature additions;
  • commercial integrations;
  • telemetry or new external communication behavior unless expressly justified and approved;
  • unnecessary dependency changes;
  • broad modernization unrelated to the remediation;
  • rebranding;
  • roadmap changes;
  • changes intended to establish a new project direction under the Original coordinate.

Dependency changes may be allowed where necessary or appropriate to remediate the vulnerability, but must be reviewed and disclosed.

14. Licensing and Provenance⚓︎

A CARE release may be authorized only where Central determines that the proposed patched artifact can be published consistently with applicable licensing, provenance, and redistribution requirements.

Central may require evidence regarding:

  • original artifact license;
  • source availability;
  • third-party or embedded code;
  • shaded or bundled dependencies;
  • attribution and notice obligations;
  • license compatibility of new or modified code;
  • trusted actor rights to contribute the patch;
  • commercial or proprietary restrictions;
  • trademark or user-confusion concerns.

Public availability of an artifact in Central does not by itself establish permission for modification or redistribution by a third party.

Where licensing or provenance cannot be resolved, Central may decline CARE publication and pursue other measures, including advisory metadata or coordination with the original publisher.

15. Embargo and Coordinated Disclosure⚓︎

CARE remediation may be prepared under embargo.

Trusted remediation actors must comply with applicable embargo, confidentiality, and coordinated vulnerability disclosure requirements.

Central may validate, stage, coordinate, or publish CARE releases in connection with an embargoed vulnerability where Central determines that doing so is appropriate.

Publication timing, metadata visibility, VEX publication, and advisory disclosure may be coordinated to reduce unnecessary risk while supporting timely remediation.

16. Original Coordinates and Successor Coordinates⚓︎

CARE is designed to support emergency remediation under existing coordinates where coordinate continuity materially improves downstream safety.

Use of an Original coordinate for CARE does not make that coordinate available for general future development by the trusted remediation actor.

Ongoing feature development, project modernization, strategic maintenance, or continuation of a project by a new organization should generally occur under a successor coordinate unless Central approves a separate namespace transfer or other appropriate process.

An Original coordinate may continue to be used for CARE releases where emergency backports or security remediation remain necessary.

17. Supersession, Correction, and Revocation⚓︎

A CARE release may later be superseded by:

  • a normal maintainer release;
  • a follow-up CARE release;
  • a successor-coordinate release;
  • an advisory or metadata correction;
  • another remediation approved by Central.

Central may annotate, supersede, flag, or otherwise update CARE metadata where new information becomes available.

If a CARE release is found to be incorrect, incomplete, incompatible, legally problematic, or otherwise inappropriate, Central may take corrective action consistent with applicable integrity and ecosystem safety procedures.

Corrective action may include:

  • publishing updated metadata;
  • marking a CARE release as superseded;
  • coordinating a follow-up release;
  • notifying affected parties;
  • revoking trusted remediation actor status;
  • taking repository-level measures where necessary.

18. Disputes and Objections⚓︎

Central may receive objections or competing claims from maintainers, trusted remediation actors, commercial publishers, vulnerability reporters, downstream consumers, or other stakeholders.

Central will consider relevant evidence, including maintainer rights, ecosystem safety, technical validity, licensing, provenance, user impact, and repository integrity.

Central may approve, reject, delay, supersede, annotate, or revoke CARE activity at its discretion.

Where appropriate, Central may work with stakeholders to transition from CARE remediation to normal maintainer publication, successor-coordinate publication, or namespace transfer.

19. Public Transparency⚓︎

CARE releases should be visible as CARE releases.

Central will make reasonable efforts to provide public information about CARE releases, subject to embargo, legal, security, and operational constraints.

Public CARE information may include:

  • affected coordinate;
  • base version;
  • the CARE version;
  • relevant advisory identifiers;
  • the trusted remediation actor;
  • scope of remediation;
  • compatibility notes;
  • VEX status;
  • supersession information;
  • maintainer coordination status, where appropriate.

Some information may be withheld, delayed, or summarized where disclosure would increase risk or violate coordinated disclosure obligations.

20. No Warranty or Guarantee⚓︎

A CARE release is a Central-approved emergency remediation release for Central distribution purposes.

A CARE release does not guarantee that:

  • all vulnerabilities are fixed;
  • the artifact is suitable for every use case;
  • the artifact is fully compatible with all downstream environments;
  • the original maintainer endorses the release;
  • future maintenance will occur;
  • the trusted remediation actor has become the project maintainer.

Users remain responsible for evaluating, testing, and deploying dependencies appropriately for their own environments.

21. Policy Administration⚓︎

Sonatype administers this policy as operator of Central.

Sonatype may update this policy over time as ecosystem needs, regulatory expectations, vulnerability-disclosure practices, repository capabilities, and software supply chain norms evolve.

Questions about CARE, trusted remediation actors, or emergency publication should be directed through the channels designated by Central.