Skip to content

Latest commit

 

History

History
55 lines (27 loc) · 5.77 KB

vulnerability-disclosure-policy.md

File metadata and controls

55 lines (27 loc) · 5.77 KB
Raw

OpenSSF Outbound Vulnerability Disclosure Policy

The OpenSSF adheres to the Model Outbound Vulnerability Disclosure Policy, Version 0.1.

IMPORTANT: This policy is not about how Open Source Security Foundation (OpenSSF) handles vulnerabilities disclosed to the OpenSSF for its software projects (i.e., incoming disclosures). Instead, it refers to how the OpenSSF publicly discloses vulnerabilities it finds in all projects (i.e., outgoing disclosures).

Future Automated Disclosure+Fix

Certain classes of vulnerabilities are common, widespread, easily detectable, and fixed with automated tooling. The distribution of fixes can be automated, helping maintainers - at scale. In these cases, the scope of the vulnerability class is often beyond what can be reasonably reported to each maintainer manually.

The OpenSSF Vulnerability Disclosure WG Autofix SIG is working on an update to the Model Policy for automated disclosures with fixes. We will update this policy when the results of that effort are released.

Questions?

Open an issue under the OpenSSF Vulnerability Disclosure Working Group Repository, or ask in the OpenSSF Slack under the WG Vulnerability Disclosure channel.

Model Outbound Vulnerability Disclosure Policy: Version 0.1

Manual Disclosure Policy

We believe that vulnerability disclosure is a collaborative, two-way street. All parties, maintainers1, as well as researchers, must act responsibly. This is why we adhere to a maximum 90-day public disclosure time limit, the “Time Limit”. We immediately privately report to maintainers when we discover vulnerabilities within their software, the “Notice Date”. If a project responds to the private report within 21 calendar days, the details will be publicly disclosed (shared with the defensive community) after 90 days after the Notice Date, on the “Publication Date”, or sooner if the maintainer releases a fix prior to the Publication Date. That Publication Date can vary in the following ways:

  • If a Time Limit is due to expire on a weekend or major public holiday, the Publication Date will be moved to the next normal work day. We are a global community and if there is a conflict, we kindly request that maintainers communicate these conflicts up-front.
  • We expect maintainers to respond within 21 calendar days of the Notice Date to let us know how the issue is being mitigated to protect impacted end-users. If we do not receive any engagement from the maintainers within 35 days of the Notice Date, that affirms their intention to fix the vulnerability within the Time Limit, we reserve the right to fully publicly disclose the vulnerability at that point.
  • Before the Time Limit has expired, if maintainers let us know that remediation publication is scheduled for release or publication on a specific day that will fall within 14 days following the Publication Date, we will delay the Publication Date until the availability of the remediation. If the remediation is not published within 14 days, a publication will only be delayed if it is an extreme circumstance (as defined below).
  • When we observe a previously unknown (to the public) and unpatched vulnerability in software under active exploitation (a “0-day”), we believe that more urgent action is appropriate. The Publication Date for a 0-day will be accelerated to within 7 days of the Notice Date, with one exception. \
  • If it is before the Publication Date, but the vulnerability is observed under active exploitation, it moves to the 0-day policy (above).
  • If the maintainers communicate that the reported vulnerability will not be fixed, or state it is not a vulnerability, then the details may be immediately released.

As always, we reserve the right to bring the Publication Date forwards or backwards based on extreme circumstances (e.g., the maintainers live in a country hit by an earthquake, or a new class of vulnerabilities is being reported as in Spectre and Meltdown). Changes to the Publication Date will be explicitly communicated to the maintainers.

Rationale

This policy is primarily designed to minimize harm to downstream users, both in its application on the micro-scale, for individual disclosures, and the macro-scale, across all disclosures. We believe this policy does so, while also respecting the needs of both maintainers and researchers.

This policy is strongly aligned with the desire to shorten the remediation time for security vulnerabilities and, where possible, support maintainers by providing fixes. We expect this to reduce harm to the ecosystem and downstream users, while softening landings for remediations marginally over the time limit. This policy was inspired by the policies from CERT/CC, Facebook, Google, Rain Forest Puppy, & The Zero Day Initiative (ZDI). We call on all researchers to adopt disclosure time limits in some form, as appropriate, and welcome you to use this policy verbatim. We expect that all parties will benefit from more reasonably-timed remediations resulting in smaller windows of opportunity for attackers to abuse vulnerabilities. Vulnerability disclosure policies such as this result in greater overall safety for users of technology and the internet.

Notes

Footnotes

  1. Including, but not limited to: open source software maintainers, vendors, suppliers, not-for profits, and corporations. ↩