wg-vulnerability-disclosures
wg-vulnerability-disclosures copied to clipboard
ossf
Project Idea - OSSF Official Outgoing Vulnerability Disclosure Policy
Note This issue is about outgoing vulnerability reports discovered and needing to be disclosed by Alpha Omega staff, as well as other representatives of the Open Source Security Foundation. Not incoming reports against OSSF repositories/projects.
The Alpha Omega project needs a formal Vulnerability Disclosure Policy for outgoing vulnerability reports to other companies, organizations, or OSS maintainers.
Policy Components
- [x] Disclosure Timeline
- [x] Disclosure Timeline for vulnerabilities under active exploitation
- [x] Policy Rationale
- [x] Location where previously published vulnerability disclosures can be found
Example Policies
Here are a collection of policies that other organizations in the industry have already come up with and are actively using:
- Google Project Zero (GPZ): 90 + 30 days - https://about.google/appsecurity/
- 90 days to fix the vulnerability
- 30 days from the fix being released to when GPZ will fully disclose details
- Zero Day Initiative (ZDI): 30 to 90 days (severity dependent) - https://www.zerodayinitiative.com/advisories/disclosure_policy/
- Facebook: 90 days - https://www.facebook.com/security/advisories/Vulnerability-Disclosure-Policy
- CERT/CC: 45 days - https://vuls.cert.org/confluence/display/Wiki/Vulnerability+Disclosure+Policy
- Linux Kernel: 7 days - https://www.kernel.org/doc/html/v4.10/admin-guide/security-bugs.html
Other Resources
Originally, my disclosure policy was the following:
This vulnerability disclosure follows Google's 90-day vulnerability disclosure policy (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first.
This is the policy that I've been using more recently. https://github.com/jlleitschuh/security-research
Personally, I have a particular affinity to Google Project Zero's disclosure policy because I find the rationale they communicate in their FAQ to be particularly compelling.
- linux-distros: 14 days - https://oss-security.openwall.org/wiki/mailing-lists/distros
How does Project Zero’s policy apply to open-source projects? The verbiage in the policy and FAQ seems specifically targeted at vendors and “patches”.
For example, does the bug being fixed in the open-source repository, count as a “patch”? Does that mean the details would be made public 30 days after the fix is in the repo? As this does not seem to be typical.
Jason Keirstead Distinguished Engineer, CTO - IBM Security Threat Management | www.ibm.com/securityhttps://www.ibm.com/security
Assistant - Mauricio Durán Cambronero @.***) Co-Chair - Open Cybersecurity Alliance, Project Governing Board www.opencybersecurityalliance.org
From: Jonathan Leitschuh @.> Date: Wednesday, January 18, 2023 at 5:03 PM To: ossf/wg-vulnerability-disclosures @.> Cc: Subscribed @.***> Subject: [EXTERNAL] Re: [ossf/wg-vulnerability-disclosures] Project Idea - OSSF Official Outgoing Vulnerability Disclosure Policy (Issue #122) Originally, my disclosure policy was the following: This vulnerability disclosure follows Google's 90-day vulnerability disclosure policy (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd
Originally, my disclosure policy was the following:
This vulnerability disclosure follows Google's 90-day vulnerability disclosure policyhttps://www.google.com/about/appsecurity/ (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first.
This is the policy that I've been using more recently. https://github.com/jlleitschuh/security-researchhttps://github.com/jlleitschuh/security-research
Personally, I have a particular affinity to Google Project Zero's disclosure policy because I find the rationale they communicate in their FAQhttps://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html to be particularly compelling.
— Reply to this email directly, view it on GitHubhttps://github.com/ossf/wg-vulnerability-disclosures/issues/122#issuecomment-1396083761, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB5535PFXXSIT5IEHTPERADWTBK73ANCNFSM6AAAAAAT7RRFIE. You are receiving this because you are subscribed to this thread.Message ID: @.***>
How does Project Zero’s policy apply to open-source projects? The verbiage in the policy and FAQ seems specifically targeted at vendors and “patches”.
As far as I can tell, they don't have different disclosure timelines between OSS and projects maintained by large organizations. They apply this policy consistently and uniformly.
For example, does the bug being fixed in the open-source repository, count as a “patch”? Does that mean the details would be made public 30 days after the fix is in the repo? As this does not seem to be typical.
From their FAQ:
Project Zero follows a 90+30 disclosure deadline policy, which means that a vendor has 90 days after Project Zero notifies them about a security vulnerability to make a patch available to users.
I believe there was prior wording that stated something about the patch is made "widely available". In general, I believe this is the point where a software package can actively be consumed by downstream users. This can vary widely by ecosystem. For a Java project, I'd consider this only once a release is published on Maven Central. For a Go project, or a project that uses git as a distribution mechanism, this may be as soon as a commit hits the release branch. While I agree "patch" is vague, this is most likely a requirement because software release ecosystems are so diverse.
Personally, I don't think we need to be specific about what it means as, in a majority of cases, it will be either be clear or the OSS maintainer can tell us, when a patch is widely available to downstream users.
The CERT/CC uses the 45 day as a starting point, to "encourage" the vendors to complete their updates/fixes in a timely manner. There are times that our embargo is broken and the vulnerability becomes public. There's not much we can do about a broken embargo. We do alert the affected vendors and may publish earlier than expected with vendor support. There are other times where the vulnerability cannot be mitigated or remediated in 45 days (e.g., ATMs) and publishing doesn't occur until the vendors can repair their systems (or devices).
ATM vulnerability: https://kb.cert.org/vuls/id/815655 Initially reported: 2018 Published: 2020
Supply chain is an important consideration as well. For example, Dell, Lenovo, HP, or other manufacturers cannot determine if they are vulnerable until self-encrypting hard drive manufacturers determines their status. (https://kb.cert.org/vuls/id/395981)
At CERT/CC, our goal is to coordinate with the various stakeholders and make sure the vulnerability is addressed accordingly and that the correct information reaches the public.
I think that if we’re making a policy we have to come up with some more clarity here than that Project Zero has, because we are specifically targeting a more complex scenario in open-source. For example, let’s say you uncover a bad 0day in a Python library that we know is widely deployed. It is worth considering if one should wait until the major Linux distributions have had a chance to issue a security patch, as opposed to just releasing it whenever the fix is out on Pypi, which could leave a lot of people exposed. It is complex…
Jason Keirstead Distinguished Engineer, CTO - IBM Security Threat Management | www.ibm.com/securityhttps://www.ibm.com/security
Assistant - Mauricio Durán Cambronero @.***) Co-Chair - Open Cybersecurity Alliance, Project Governing Board www.opencybersecurityalliance.org
From: Jonathan Leitschuh @.> Date: Wednesday, January 18, 2023 at 11:43 PM To: ossf/wg-vulnerability-disclosures @.> Cc: Jason Keirstead @.>, Comment @.> Subject: [EXTERNAL] Re: [ossf/wg-vulnerability-disclosures] Project Idea - OSSF Official Outgoing Vulnerability Disclosure Policy (Issue #122) How does Project Zero’s policy apply to open-source projects? The verbiage in the policy and FAQ seems specifically targeted at vendors and “patches”. As far as I can tell, they don't have different disclosure timelines between OSS and projects ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd
How does Project Zero’s policy apply to open-source projects? The verbiage in the policy and FAQ seems specifically targeted at vendors and “patches”.
As far as I can tell, they don't have different disclosure timelines between OSS and projects maintained by large organizations. They apply this policy consistently.
For example, does the bug being fixed in the open-source repository, count as a “patch”? Does that mean the details would be made public 30 days after the fix is in the repo? As this does not seem to be typical.
From their FAQ:
Project Zero follows a 90+30 disclosure deadline policy, which means that a vendor has 90 days after Project Zero notifies them about a security vulnerability to make a patch available to users.
I believe there was prior wording that stated something about the patch is made "widely available". In general, I believe this is the point where a software package can actively be consumed by downstream users. This can vary widely by ecosystem. For a Java project, I'd consider this only once a release is published on Maven Central. For a Go project, or a project that uses git as a distribution mechanism, this may be as soon as a commit hits the release branch. While I agree "patch" is vague, this is most likely a requirement because software release ecosystems are so diverse.
Personally, I don't think we need to be specific about what it means as, in a majority of cases, it will be either be clear or the OSS maintainer can tell us, when a patch is widely available to downstream users.
— Reply to this email directly, view it on GitHubhttps://github.com/ossf/wg-vulnerability-disclosures/issues/122#issuecomment-1396401040, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB5535JNELJLUSFB7UFL4BLWTCZ4XANCNFSM6AAAAAAT7RRFIE. You are receiving this because you commented.Message ID: @.***>
Jonathan, I'd like to get your thoughts on 2: ii which states: If the maintainer chooses not to accept the vulnerability disclosure via GHSA, the vulnerability is automatically publicly disclosed and a CVE will be requested.
So if the maintainer does not accept it, therefor suggesting it is not valid, or maybe they just don't feel like fixing it or ????, but it would seem the vulnerability has the possibility of just sitting out there for ever, and the policy should probably address what happens long term.
While we're working on a disclosure policy for A-O, it would also be useful to collaborate on a stock SECURITY.MD file for use across all foundation projects. that way, we might have two useful things to share with our peers.
I agree, but that should be broken out into an independent issue dedicated to that topic specifically. While those two problems look to be the same, they really aren't unfortunately.
Well, it has to be covered under disclosure policy some how so we don't get automated CVE generation in the case of "maintainer will not fix" (or what ever term covers that.
Just to be clear, Google Project Zero definitely includes open source software. A quick look at their blog https://googleprojectzero.blogspot.com/ shows discussions about things like the Linux kernel, etc.
@david-a-wheeler If someone has a contact at Project Zero it would be good to get them to directly weigh in on how they interpret their own policy for open-source. Right now it is unnecessarily ambiguous. I think we should be more clear when we create ours.
What do you mean by ambiguous? What wording do you think has this characteristic? AFAIK, they don't have a specific policy that's different for OSS. From what I've heard, they consider both companies, and OSS projects to be "vendors", and their policy is consistently applied to all.
As I sad in above (https://github.com/ossf/wg-vulnerability-disclosures/issues/122#issuecomment-1396245208) it's the terms "vendor" and "patch" that are very unspecific in the policy, and the definition of them is important because they scope the windows. To me it is needlessly ambiguous. We can be much clearer what we mean by these things.
Please see the proposed policy and leave any review comments:
https://docs.google.com/document/d/1W2Xfw9i5pSA-0XbIw3a4kcW2o4PByxDbjcnWe9mlQwA/edit?usp=sharing
Submitted to the LF Legal team for review: (internal/private link): https://legaljira.linuxfoundation.org/servicedesk/customer/portal/1/LR-1447
FYI, there's also a proposed inbound policy, noting here for clarity/constrast: https://github.com/ossf/wg-vulnerability-disclosures/issues/122
There was concern expressed in the lack of search-ability/SEO for straight code documents in repositories in last weeks' meeting
This issue is for people with opinions to share if there is a strong preference for github pages, wordpress, other, or none for things we want to be easily located
Specific first example "Outgoing Vulnerability Disclosure Policy"
but it was also a more general concern
Testing incognito mode i was able to find our github issue easily. I also was able to easily find github page content for other projects. - I feel like a github page would stay more current and also be easily searchable? However if we were able to post this, or a link to this, on the parent/main wordpress site it may be found more organically by those looking at the website in addition to those searching (seo).
i'm indifferent in all cases but there was also mention of a n iframe on the wordpress which could be it's own separate item.
And to note boundaries were brought up in the safe harbor discussion and some (not all) policies seem to reference so it seems a good diea to include in ours if possible?
This is published on the website, but is this yet in the source control?