OSS vulnerability disclosure white paper

[MarcinHoppe]

In the last WG meeting we had an idea of collecting and distilling the information we've gathered so far in the form of a white paper. I think this would be an amazing resource and a valuable contribution to the OpenSSF.

I did a bit of thinking and thought about a very draft outline:

1. Introduction to OSS vulnerability disclosure
2. Ecosystem participants (our personas)
3. Disclosure models used in the wild
4. Relevant standards (CVE JSON, CSAF/CVRF, etc.)
5. Support from open source products and platforms (e.g. GitHub)
6. Challenges
7. Recommendations
8. Case studies

Who would like to participate? I am guessing this requires some commitment over at least a few weeks.

[SecurityCRob]

On 12/18/20 6:53 AM, Marcin Hoppe wrote: In the last WG meeting we had an idea of collecting and distilling the information we've gathered so far in the form of a white paper. I think this would be an amazing resource and a valuable contribution to the OpenSSF. I did a bit of thinking and thought about a very draft outline * Introduction to OSS vulnerability disclosure * Ecosystem participants (our personas) * Disclosure models in the wild o OSS VDP/bug bounties o Coordinated disclosure * Standards (CVE JSON, CSAF/CVRF, etc.) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#88>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQRFDLDQUDAU7GBXS6VPJILSVM7EXANCNFSM4VBCKSSA>.

+1.  Love it.

…

-- This is the Way. I have spoken, CRob ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Christopher "CRob" Robinson Modern Renaissance Man for Red Hat Product Security ....and other duties as required irc: CRob | tz: UTC -5:00 (US/Eastern) | email: [email protected] Red Hat Product Security contact: [email protected] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[lattera]

I like the term "coordinated disclosure" versus "responsible disclosure." I think some discussion around the different methods of disclosure would be beneficial. Here's an article about "responsible disclosure" versus "full disclosure": https://git-01.md.hardenedbsd.org/shawn.webb/articles/src/branch/master/infosec/Vulnerabilities/2019-01-08_Disclosure/article.md

(FWIW, I support full disclosure, even speaking as a vendor of an open source operating system.)

[JasonKeirstead]

@lattera Great article.

RE this part I think you're coming at disclosure with a Provider-specific (as in the "provider" persona who is an OS/Distribution vendor or cloud provider) focus RE "When a vendor receives a security notification, the vendor must evaluate who could be impacted and of those impacted, who to notify. Coordinated disclosures usually come with either a Non-Disclosure Agreement (NDA) or an embargo until a specified date. The vendor can choose to collaborate with zero or more impacted entities of the vendor’s own choosing."

A lot of disclosures are between the discoverer and a single party who is impacted, who coordinates with no one. Perhaps it is the majority of disclosures? It'd be interesting to run some stats. Anyway IMHO "coordinated disclosures" is a subset of the larger set of responsible disclosure processes. Not all responsible disclosures require coordination.

EDIT: Of course the problem with Full Disclosure is you're creating a huge risk, as as soon as a vuln is public it starts being exploited on a global scale within hours.

[MarcinHoppe]

I think we should cover all the disclosure models that are relatively common in the OSS world, including independent researchers, through academics, all the way up to coordinated multi-party disclosures involving embargo, etc.

[lattera]

Of course the problem with Full Disclosure is you're creating a huge risk, as as soon as a vuln is public it starts being exploited on a global scale within hours.

Vulnerabilities can be found and exploited independently by multiple parties, regardless of public notification. I know of quite a few actors paying attention to each and every commit to the Linux kernel, writing exploits for errant commits. These actors of motivations not to share publicly the vulnerabilities.

[JasonKeirstead]

@lattera Agree entirely, and a lot of this has to do with what the vulnerability is and how difficult it is to exploit. High-impact but trivial to exploit - especially remotely - vulnerabilities are the ones that most deserve thought to an embargo. A great example of these would be the NetScaler and PAN-OS vulnerabilities this year... as soon as they became public, active scanning and exploits (and therefore risk to anyone unable to promptly patch ) went through the roof... it is not theoretical that this happens, it's directly measurable. It is always a balancing act.

[MarcinHoppe]

@lattera @JasonKeirstead this is a great discussion but I am wondering if there is a direct connection to the white paper?

[lattera]

@lattera @JasonKeirstead this is a great discussion but I am wondering if there is a direct connection to the white paper?

The very first point is this:

1. Introduction to OSS vulnerability disclosure

I think an intro to vulnerability disclosure should probably talk about the different methods of disclosures.

[SecurityCRob]

Those Product Security teams involved with FIRST will be familiar with the Vulnerability Disclosure SIG's Multiparty Vuln Disclosure guidelines - https://www.first.org/global/sigs/vulnerability-coordination/multiparty/FIRST-Multiparty-Vulnerability-Coordination.pdf
Ideally this and other documents can help inform us to tailor a consistent practice for OSS.

[MarcinHoppe]

I created https://github.com/ossf/vulnerability-disclosures-whitepaper to coordinate the development and publication of the whitepaper.

[zmanion]

Of course the problem with Full Disclosure is you're creating a huge risk, as as soon as a vuln is public it starts being exploited on a global scale within hours.

Vulnerabilities can be found and exploited independently by multiple parties, regardless of public notification. I know of quite a few actors paying attention to each and every commit to the Linux kernel, writing exploits for errant commits. These actors of motivations not to share publicly the vulnerabilities.

Further, parties reverse engineer binary updates/patches, so "full" disclosure (details, PoC) is probably helping (more capable) defenders more than it helps adversaries. Details/PoC do probably help "commodity" adversaries in the short term.

This sort of discussion may not end up being the point of this document (assuming it remains "what should a maintainer do"), but I'd propose that the paper provide some context about why and how to do disclosure.

[jenniferfernick]

Hi @MarcinHoppe / @RedHatCRob

I'd like to contribute to this whitepaper! However, I haven't participated in this working group (yet). Let me know any next steps to get involved :)

I have many thoughts & feels to share regarding disclosure

[SecurityCRob]

On 2/8/21 6:16 PM, jenniferfernick wrote: Hi @MarcinHoppe <https://github.com/MarcinHoppe> / @RedHatCRob <https://github.com/RedHatCRob> I'd like to contribute to this whitepaper! However, I haven't participated in this working group (yet). Let me know any next steps to get involved :) I have many thoughts & feels to share regarding disclosure — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#88 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQRFDLFBN3TZUO7J5YB3SHTS6BWEZANCNFSM4VBCKSSA>.

Welcome!  The next steps would be to show up to a call and introduce yourself!  We are glad to collaborate with one that has a passion (and spare time).  We'll have the whitepaper framed out shortly, once that happens feel free to contribute thoughts/ideas/references to any/all of the sections.  After the skeleton is up we'll start talking about it either within the WG call or will spin off dedicated calls with smaller groups focused on parts to flesh out and then bring back to the whole group.

…

-- This is the Way. I have spoken, CRob ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Christopher "CRob" Robinson Modern Renaissance Man for Red Hat Product Security ....and other duties as required irc: CRob | tz: UTC -5:00 (US/Eastern) | email: [email protected] Red Hat Product Security contact: [email protected] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[jenniferfernick]

Great, thank you! I have a recurrent time conflict for the meeting, but will aim to join you next week and as many future weeks as possible, and to add some content to the skeleton once available.