Update Outbound Vuln Disclosure Policy

These are proposed changes to clarify the readability and flow of
the OpenSSF Outbound Vulnerability Disclosure Policy.

These changes were proposed as Chainguard was looking to adopt this policy
as it's own Outhbound policy. Chainguard is looking to upstream these changes
back to the OpenSSF.

Signed-off-by: Jonathan Leitschuh <[email protected]>

docs/Outbound_Vulnerability_Disclosure_Policy_template.md

@@ -1,6 +1,6 @@
 # OpenSSF Outbound Vulnerability Disclosure Policy Template
 
-The OpenSSF adheres to the Model Outbound Vulnerability Disclosure Policy, Version 0.1.
+The OpenSSF adheres to the Model Outbound Vulnerability Disclosure Policy, Version 0.2.
 
 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)._
 
@@ -14,7 +14,7 @@ The OpenSSF Vulnerability Disclosure WG Autofix SIG is working on an update to t
 
 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
+# Model Outbound Vulnerability Disclosure Policy: Version 0.2
 
 ## Manual Disclosure Policy
 
@@ -23,9 +23,9 @@ We believe that vulnerability disclosure is a collaborative, two-way street. All
 - 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.
+- 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.