Merge pull request #150 from JLLeitschuh/patch-1

Create Outbound_Vulnerability_Disclosure_Policy.md

docs/Outbound_Vulnerability_Disclosure_Policy_template.md

@@ -0,0 +1,42 @@
+# OpenSSF Outbound Vulnerability Disclosure Policy Template
+
+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](https://github.com/ossf/wg-vulnerability-disclosures/issues), or ask in the [OpenSSF Slack](https://slack.openssf.org/) 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 involved, including but not limited to maintainers[^1], 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)  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.
+- We may offer an exception for cases where we determine that there will be less overall harm to users if more than 7 days are granted. This would typically be because there is evidence that widespread exploitation is unlikely. Maintainers merely requiring more time to fix the vulnerability is not an adequate justification, since every day users are unwarned will lead to additional harm. Under this exception, the original Time Limit remains in effect.
+- The reason for this special 0-day designation is that for each day an actively exploited vulnerability remains undisclosed to the public and unpatched, more devices or accounts will be compromised. Seven days is an aggressive time limit and may be too short for some maintainers to update their software, but it should be enough time for maintainers to publish advice about possible mitigations, such as temporarily disabling a service, restricting access, or contacting the maintainer for more information. As a result, if 7 days have elapsed without a remediation or advisory, we will generally support researchers making the full details available so that users can take steps to protect themselves. We believe it’s important that maintainers disclose that there is evidence to suggest that the 0-day vulnerability is under active exploitation.
+- 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.
+
+[^1]: Including, but not limited to: open source software maintainers, vendors, suppliers, not-for profits, and corporations.
+
+## 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](https://vuls.cert.org/confluence/display/Wiki/Vulnerability+Disclosure+Policy), [Facebook](http://facebook.com/security/advisories/Vulnerability-Disclosure-Policy), [Google](https://about.google/appsecurity/), [Rain Forest Puppy](https://dl.packetstormsecurity.net/papers/general/rfpolicy-2.0.txt), & [The Zero Day Initiative (ZDI)](https://www.zerodayinitiative.com/advisories/disclosure_policy/).
+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.