Vulnerability Management
This page describes how a vulnerability in the platform is reported, assessed, and disclosed. See Secure Development for how security is built into development itself, and Supply Chain for how dependencies and published artifacts are scanned.
Reporting a vulnerability
One security policy is published for the project and serves as the security policy of every public repository. Private vulnerability reporting is enabled per repository.
Where a vulnerability is reported depends on whether it is already public:
- A vulnerability that is not yet public goes through the private reporting channel on the affected repository — the preferred route, since it keeps the report, the discussion, and the fix together. The security address published in that policy is for when that channel cannot be used, or when the issue affects the platform as a whole rather than one repository. Never report it in a public issue, pull request, or discussion.
- The public Vulnerability issue template is only for a vulnerability that is already public — for example, a CVE surfaced by dependency or container image scanning.
The project publishes the following commitments:
| Commitment | Target |
|---|---|
| Acknowledgment | Within 3 business days |
| Initial assessment, including whether the issue is reproducible and how its severity is rated | Within 10 business days |
A useful report includes:
- a clear description of the vulnerability,
- the affected components, including version,
- steps to reproduce it, or a proof of concept,
- the impact you believe it has,
- a link to the CVE description, if one already exists,
- any other context that helps assess it.
Coordinated disclosure
Reporters are asked to allow time for a fix before disclosing a vulnerability publicly, and an advisory is targeted within 90 days of the report, or sooner once a fix is available. Where a vulnerability is already being exploited, the project moves as quickly as it can and coordinates the announcement with the reporter. The project keeps the reporter informed while it works on a fix, and credits them in the advisory that discloses it unless they prefer otherwise.
Assessment and remediation
A vulnerability, however it arrives, is recorded and confirmed: is it reproducible, and which components and versions are affected? Severity is assessed on impact, exploitability, and exposure. Remediation goes through the ordinary change flow, with priority matching severity: a critical vulnerability triggers a patch release rather than waiting for the next feature release, while lower-severity fixes may be batched.
Disclosure
A handled vulnerability is disclosed in an advisory identifying the affected components and versions, published in the affected repository's advisory list. Security fixes are identified in the release notes of the release that ships them, in a dedicated security category — see Publication.
Regulatory reporting
Regulatory reporting obligations that apply to the manufacturer of a product are distinct from those that apply to an operator of a service built on it.