search

ossf / wg-vulnerability-disclosures

The OpenSSF Vulnerability Disclosures Working Group seeks to help improve the overall security of the open source software ecosystem by helping mature and advocate well-managed vulnerability reporting and communication.
https://openssf.org
Apache License 2.0
175 stars 40 forks source link

Project Idea - OSSF Official Outgoing Vulnerability Disclosure Policy #122

Open JLLeitschuh opened 1 year ago

JLLeitschuh commented 1 year ago

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

Example Policies

Here are a collection of policies that other organizations in the industry have already come up with and are actively using:

Other Resources

JLLeitschuh commented 1 year ago

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.

Foxboron commented 1 year ago
JasonKeirstead commented 1 year ago

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: @.***>

JLLeitschuh commented 1 year ago

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.

laurie-tyz commented 1 year ago

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.

JasonKeirstead commented 1 year ago

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: @.***>

Grunbok commented 1 year ago

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.

SecurityCRob commented 1 year ago

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.

JLLeitschuh commented 1 year ago

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.

Grunbok commented 1 year ago

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.

david-a-wheeler commented 1 year ago

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.

JasonKeirstead commented 1 year ago

@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.

JLLeitschuh commented 1 year ago

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.

JasonKeirstead commented 1 year ago

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.

JLLeitschuh commented 1 year ago

Please see the proposed policy and leave any review comments:

https://docs.google.com/document/d/1W2Xfw9i5pSA-0XbIw3a4kcW2o4PByxDbjcnWe9mlQwA/edit?usp=sharing

JLLeitschuh commented 1 year ago

Submitted to the TAC: https://github.com/ossf/tac/issues/149

JLLeitschuh commented 1 year ago

Submitted to the LF Legal team for review: (internal/private link): https://legaljira.linuxfoundation.org/servicedesk/customer/portal/1/LR-1447

david-a-wheeler commented 1 year ago

FYI, there's also a proposed inbound policy, noting here for clarity/constrast: https://github.com/ossf/wg-vulnerability-disclosures/issues/122

NicoleSchwartz commented 1 year ago

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.

NicoleSchwartz commented 1 year ago

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?

NicoleSchwartz commented 7 months ago

This is published on the website, but is this yet in the source control?