Skip to content

Commit

Permalink
Merge pull request #54 from andreslucena/patch-1
Browse files Browse the repository at this point in the history 
Fix format in maintainer guide
  • Loading branch information
@SecurityCRob
SecurityCRob authored May 31, 2024
2 parents 1ec7e18 + a97dc7b commit da8a22a
Showing 1 changed file with 22 additions and 22 deletions.
44 changes: 22 additions & 22 deletions maintainer-guide.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -237,60 +237,60 @@ To assess if an issue is a vulnerability, you will need:

3 **Discuss embargo period with vulnerability reporter**

Vulnerability reporters will typically state the embargo period they're willing to accept. The "embargo period" is when the vulnerability report is kept from the public, enabling the project to respond, fix, and publicly disclose the vulnerability themselves. This may or may not be the embargo period requested by the project. There are different recommendations and norms about embargo periods among different groups:
Vulnerability reporters will typically state the embargo period they're willing to accept. The "embargo period" is when the vulnerability report is kept from the public, enabling the project to respond, fix, and publicly disclose the vulnerability themselves. This may or may not be the embargo period requested by the project. There are different recommendations and norms about embargo periods among different groups:

- The [distros mailing list](https://oss-security.openwall.org/wiki/mailing-lists/distros) prefers less than 7 days, with an absolute maximum period of 14 days.
- [CERT/CC discloses vulnerabilities to the public 45 days after the report](https://vuls.cert.org/confluence/display/Wiki/Vulnerability+Disclosure+Policy), even if no fix is available, with a few exceptions.
- [The CERT® Guide to Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf) (August 2017) says that "an acknowledgement timeframe of 24-48 hours is common for vendors and coordinators, while 45-90 days seems to be the normal range for disclosures these days."
- [Google's application security policy uses a 90-day deadline](https://www.google.com/about/appsecurity/)
- The [distros mailing list](https://oss-security.openwall.org/wiki/mailing-lists/distros) prefers less than 7 days, with an absolute maximum period of 14 days.
- [CERT/CC discloses vulnerabilities to the public 45 days after the report](https://vuls.cert.org/confluence/display/Wiki/Vulnerability+Disclosure+Policy), even if no fix is available, with a few exceptions.
- [The CERT® Guide to Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf) (August 2017) says that "an acknowledgement timeframe of 24-48 hours is common for vendors and coordinators, while 45-90 days seems to be the normal range for disclosures these days."
- [Google's application security policy uses a 90-day deadline](https://www.google.com/about/appsecurity/)

Note that 90 days is the _longest_ embargo period entertained by various groups as a default; many default embargo periods are shorter. More or less time may be appropriate depending on the issue's complexity, whether or not the issue is being actively exploited, or problems in patch rollout. If you believe the vulnerability reporter has not given your project enough time, now is the time to make the case to the vulnerability reporter about _why_ a longer embargo time is needed. [The CERT® Guide to Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf) recommends that both suppliers and reporters "treat policy-declared disclosure timeframes as the starting point of a negotiation process rather than a hard deadline."
Note that 90 days is the _longest_ embargo period entertained by various groups as a default; many default embargo periods are shorter. More or less time may be appropriate depending on the issue's complexity, whether or not the issue is being actively exploited, or problems in patch rollout. If you believe the vulnerability reporter has not given your project enough time, now is the time to make the case to the vulnerability reporter about _why_ a longer embargo time is needed. [The CERT® Guide to Coordinated Vulnerability Disclosure](https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_503340.pdf) recommends that both suppliers and reporters "treat policy-declared disclosure timeframes as the starting point of a negotiation process rather than a hard deadline."

What's critical is that the embargo time is agreed on by all parties (if possible). It's also essential that there be ongoing communication with the vulnerability reporters. Most vulnerability reporters are happy to provide some extra time if there is clear ongoing evidence of effort, continuous communication, and a good rationale for that extra time.
What's critical is that the embargo time is agreed on by all parties (if possible). It's also essential that there be ongoing communication with the vulnerability reporters. Most vulnerability reporters are happy to provide some extra time if there is clear ongoing evidence of effort, continuous communication, and a good rationale for that extra time.

Embargo periods (aka "days of risk") represent a trade-off. Every day in embargo is another day where attackers may discover the vulnerability and exploit users of the software. In contrast, the users and public remain unaware of the dangers of the vulnerability. However, once the embargo ends, attackers who might not have learned of the vulnerability can now quickly learn of the vulnerability and exploit it. The shorter the time between the vulnerability discovery and a proper fix, the better. Past bitter experience has shown that many suppliers simply leave their users exposed to dangerous vulnerabilities without a deadline, so having no deadline suggests to many vulnerability reporters that the project is actively opposed to securing the software they supply.
Embargo periods (aka "days of risk") represent a trade-off. Every day in embargo is another day where attackers may discover the vulnerability and exploit users of the software. In contrast, the users and public remain unaware of the dangers of the vulnerability. However, once the embargo ends, attackers who might not have learned of the vulnerability can now quickly learn of the vulnerability and exploit it. The shorter the time between the vulnerability discovery and a proper fix, the better. Past bitter experience has shown that many suppliers simply leave their users exposed to dangerous vulnerabilities without a deadline, so having no deadline suggests to many vulnerability reporters that the project is actively opposed to securing the software they supply.

4 **Create a patch for the issue**

Let the reporter know you have confirmed the issue, begin developing a patch, and request a [CVE entry](https://cve.mitre.org/about/index.html) if they have not. **Ask the reporter if they would like to be involved in the patch development process.** Using your private development and testing tooling, develop a patch and prepare (but do not cut) a release.
Let the reporter know you have confirmed the issue, begin developing a patch, and request a [CVE entry](https://cve.mitre.org/about/index.html) if they have not. **Ask the reporter if they would like to be involved in the patch development process.** Using your private development and testing tooling, develop a patch and prepare (but do not cut) a release.

In your assessment process, you should have identified what versions are affected. As you prepare your patch, note backward compatibility and upgrade requirements (for example, v1.0.0 is affected, but the patch is not compatible, and users will need to upgrade to v1.7.0 or above to apply the patch). You will need to communicate these details in your disclosure announcements.
In your assessment process, you should have identified what versions are affected. As you prepare your patch, note backward compatibility and upgrade requirements (for example, v1.0.0 is affected, but the patch is not compatible, and users will need to upgrade to v1.7.0 or above to apply the patch). You will need to communicate these details in your disclosure announcements.

When creating a patch, it is _vital_ that it be _easy_ to users to update (at least for the users who are using the most recent release of the software). Your change should not require the users to use a different API, or eliminate user functionality unless that is _absolutely_ necessary. Where practical, the change should involve a simple update. If such changes are _absolutely_ necessary to fix the vulnerability fully, minimize the user impact, and look for ways to mitigate the vulnerability without applying the change (since many users will be unable to install such changes in a timely way).
When creating a patch, it is _vital_ that it be _easy_ to users to update (at least for the users who are using the most recent release of the software). Your change should not require the users to use a different API, or eliminate user functionality unless that is _absolutely_ necessary. Where practical, the change should involve a simple update. If such changes are _absolutely_ necessary to fix the vulnerability fully, minimize the user impact, and look for ways to mitigate the vulnerability without applying the change (since many users will be unable to install such changes in a timely way).

For issues in patching, see the [Troubleshooting](#troubleshooting-the-process) section of the guide.
For issues in patching, see the [Troubleshooting](#troubleshooting-the-process) section of the guide.

5 **Get a CVE for the issue**

**Ask the reporter if they would like to be involved in writing the CVE entry and if they would like to be credited in the entry.** Recognition is one of the many ways we thank reporters! It is _inappropriate_ to omit credit to vulnerability reporters unless the reporter does not want the credit.
**Ask the reporter if they would like to be involved in writing the CVE entry and if they would like to be credited in the entry.** Recognition is one of the many ways we thank reporters! It is _inappropriate_ to omit credit to vulnerability reporters unless the reporter does not want the credit.

Go through your [identified CNA](#establish-a-cna-contact) to have a CVE number reserved and submit a description. Let your CNA know you are working on a patch and, if applicable, will be doing embargoed notifications before public disclosure. Keep your CNA up to date on your public disclosure date so they can coordinate listing your CVE entry.
Go through your [identified CNA](#establish-a-cna-contact) to have a CVE number reserved and submit a description. Let your CNA know you are working on a patch and, if applicable, will be doing embargoed notifications before public disclosure. Keep your CNA up to date on your public disclosure date so they can coordinate listing your CVE entry.

6 **Decide the date of public release**

The advantage of getting a CVE for a vulnerability is that it provides a path to notify users of the vulnerability and verify that it is fixed. Many organizations specifically track CVEs, so that even if they don't see your vulnerability announcement, they'll see the CVE report.
The advantage of getting a CVE for a vulnerability is that it provides a path to notify users of the vulnerability and verify that it is fixed. Many organizations specifically track CVEs, so that even if they don't see your vulnerability announcement, they'll see the CVE report.

We also recommend creating a JSON entry using the [OSV schema](https://ossf.github.io/osv-schema/) and publishing this somewhere accessible over HTTP. This schema enables encoding machine readable version information that makes it easier for users to match the vulnerability to their versions of your project.
We also recommend creating a JSON entry using the [OSV schema](https://ossf.github.io/osv-schema/) and publishing this somewhere accessible over HTTP. This schema enables encoding machine readable version information that makes it easier for users to match the vulnerability to their versions of your project.

7 # **(If applicable) Notify providers under embargo**

In many countries people often have days off on Fridays, Saturdays, and/or Sundays. So if the vulnerability is not publicly known (e.g., it's not being exploited), it's often better to make the public release on Monday, Tuesday, or Wednesday. In addition, try to avoid releasing a vulnerability fix on a widely-observed holiday. This gives people some time to do the update during their workday.
In many countries people often have days off on Fridays, Saturdays, and/or Sundays. So if the vulnerability is not publicly known (e.g., it's not being exploited), it's often better to make the public release on Monday, Tuesday, or Wednesday. In addition, try to avoid releasing a vulnerability fix on a widely-observed holiday. This gives people some time to do the update during their workday.

8 **(If applicable) Notify providers under embargo**

Embargo notifications are sent anywhere from 1-30 workdays before the intended date of public disclosure. This timeframe depends on the severity and exploitability of the issue, the complexity of the patch, and the type of providers your project is used by (can the providers feasibly qualify and patch in 5 days? 10 days?). Also consider holidays and significant events that could impact the provider's ability to prepare and adjust your dates accordingly (e.g., if retailers heavily use your project, don't expect them to be able to prepare over the [US Black Friday shopping days](<https://en.wikipedia.org/wiki/Black_Friday_(shopping)>)).
Embargo notifications are sent anywhere from 1-30 workdays before the intended date of public disclosure. This timeframe depends on the severity and exploitability of the issue, the complexity of the patch, and the type of providers your project is used by (can the providers feasibly qualify and patch in 5 days? 10 days?). Also consider holidays and significant events that could impact the provider's ability to prepare and adjust your dates accordingly (e.g., if retailers heavily use your project, don't expect them to be able to prepare over the [US Black Friday shopping days](<https://en.wikipedia.org/wiki/Black_Friday_(shopping)>)).

Your notification should include the CVE id, issue description, reporter credit (if applicable), affected versions, how the patch will be made available, and the public disclosure date. See corresponding [template](#communication-templates) examples in the guide.
Your notification should include the CVE id, issue description, reporter credit (if applicable), affected versions, how the patch will be made available, and the public disclosure date. See corresponding [template](#communication-templates) examples in the guide.

9 **Cut a release and publicly disclose the issue**

On the day of public disclosure, publish your disclosure announcement ([see templates](#communication-templates)). If using GitHub Security Advisories, "publishing" your private Security Advisory will add it to the "Security" tab. If you are not using GitHub Security Advisories, publish the announcement to your release notes or security bulletins. If you have CVE ids for the vulnerabilities fixed, include the CVE id(s) of the vulnerabilities that were fixed in this release.
On the day of public disclosure, publish your disclosure announcement ([see templates](#communication-templates)). If using GitHub Security Advisories, "publishing" your private Security Advisory will add it to the "Security" tab. If you are not using GitHub Security Advisories, publish the announcement to your release notes or security bulletins. If you have CVE ids for the vulnerabilities fixed, include the CVE id(s) of the vulnerabilities that were fixed in this release.

It's also recommended to send the announcement to appropriate mailing lists for your community (i.e., a security-announce@ list and even a general mailing list for high-impact vulnerabilities).
It's also recommended to send the announcement to appropriate mailing lists for your community (i.e., a security-announce@ list and even a general mailing list for high-impact vulnerabilities).

10 **Disclose quickly**

You might choose to briefly withhold details about how the vulnerability can be exploited, hoping that this will give users a little more time to update before attackers begin exploiting the vulnerability. This only makes sense if it's not obvious to attackers how the vulnerability can be exploited, and in most cases, attackers will find it obvious. In addition, attackers can usually review changes made to software (in source or executable form) and easily determine an attack. Thus, withholding detailed information can only be helpful for a few days at most, even in the few cases where it helps at all.
You might choose to briefly withhold details about how the vulnerability can be exploited, hoping that this will give users a little more time to update before attackers begin exploiting the vulnerability. This only makes sense if it's not obvious to attackers how the vulnerability can be exploited, and in most cases, attackers will find it obvious. In addition, attackers can usually review changes made to software (in source or executable form) and easily determine an attack. Thus, withholding detailed information can only be helpful for a few days at most, even in the few cases where it helps at all.

## Troubleshooting common challenges to Coordinated Vulnerability Disclosure

Expand Down

0 comments on commit da8a22a

Please sign in to comment.