Update README.md #52
Update README.md #52
Conversation
proposed vision/and objectives for the WG
|
|
||
| - Identifying vulnerability disclosure pain points for OSS maintainer and consumers and take steps to address them | ||
|
|
||
| - Facilitate the development and adoption of a standards-based OSS Vulnerability Exchange that uses existing industry formats. and allows OSS projects of all sizes to be able to report, share, and learn about vulnerabilities within OSS components. |
There was a problem hiding this comment.
I have a suspicion nobody here thinks the existing industry formats work :)
There was a problem hiding this comment.
With that in mind, do you feel coming up with alternatives is something we should be focusing this WG on?
There was a problem hiding this comment.
I think that's a discussion for the group. As these things tend to go, everyone has their own reason for being here. I think having an agreed upon purpose matters a lot.
If everyone else like the industry standard formats, it would be foolish for one person to derail that. But obviously if the consensus is there is opportunity here, then that's a good goal.
My personal view is the majority of these standards groups are very large, very slow, and generally don't create things that will be adopted by a wide audience. Open source has a strong focus on community and iteration. Rather than talk about something for months, do something now and change it as needed.
But as I say, if this is not the view or purpose of the group, it means I should go elsewhere, not try to steam-roll my own agenda.
There was a problem hiding this comment.
I want to reply to the last comment on standards groups being "very large, very slow, and generally don't create things that will be adopted by a wide audience".
In terms of standards groups being slow or fast - in general they are as slow or fast as you want them to be. Some technical committees create working drafts in very short periods of time. Some of them take a much longer time. The time it takes is generally directly correlated with the complexity of the task. Gaining a working consensus over something complicated, usually takes time - however in my opinion, that is time well very spent. A small group developing something without a wide industry consensus, is highly unlikely to have their project accepted by the masses. This is what, in the end, leads to the famous XKCD "proliferation of standards" comic - it is groups saying "this process is too slow, let's form our own smaller group to move faster!" - forgetting that if no one actually adopts your work, then it serves no real purpose.
RE adoption - I think it is impossible to realistically argue that CVE, CPE etc. are not widely adopted. Not only do these standards drive entire industries, they are also federally mandated, as in, not optional to implement for many end user organizations - not just in the US either, but globally. This is the side of international standards sometimes forgotten - standards get factored into regulations. This is why whenever a standard is going to influence an area where you're a stakeholder, you should seek to, in tandem, influence its development, because eventually the standards tend to catch up with you.
|
|
||
| - Create a unified format and API for vulnerability reporting (from researchers to maintainers) and drive broad adoption of it across the open source software ecosystem | ||
| - Create a unified format, API, and process for coordinated disclosure (from maintainers to users/the world) and drive broad adoption | ||
| -Documenting and promoting reasonable vulnerability disclosure and coordination practices within the OSS ecosystem for component maintainers and community members by providing documented standards and educational materials. |
There was a problem hiding this comment.
Need a space for markdown bullet 😉
| - Create a unified format, API, and process for coordinated disclosure (from maintainers to users/the world) and drive broad adoption | ||
| -Documenting and promoting reasonable vulnerability disclosure and coordination practices within the OSS ecosystem for component maintainers and community members by providing documented standards and educational materials. | ||
|
|
||
| - Identifying vulnerability disclosure pain points for OSS maintainer and consumers and take steps to address them |
There was a problem hiding this comment.
In addition to identifying pain points, I'd propose adding a bit about defining and articulating ideal end-to-end workflows and automation for each persona, unencumbered by the current state of standards or technologies. Something to the effect of:
Identify vulnerability disclosure pain points and define ideal end-to-end workflows and automation for OSS maintainers, consumers, and security researchers.
| @@ -4,10 +4,13 @@ Our vision is an open source software ecosystem where the time to fix a vulnerab | |||
|
|
|||
| ## Objectives and Key Results (CY 2020) | |||
|
|
|||
| The first objectives we're using to track our progress towards that vision are: | |||
| 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. We plan on address this challenge through the following actions: | |||
There was a problem hiding this comment.
super nitpick, but consider removing "help" before "improve", not necessary for your meaning:
The ... Working Group seeks to improve the overall security of the open source software ecosystem by helping mature...
There was a problem hiding this comment.
maybe "develop" in place of "mature"? ...by helping develop and advocate well-managed...
There was a problem hiding this comment.
verb tense, We plan on addressing this challenge...
|
Looks like we have a pretty tight deadline to meet to nail down the scope before the OpenSSF press release. @RedHatCRob do you think we could incorporate the remarks from @mdressman and merge? As far as I understand, we have the consensus about the objectives themselves? |
|
I also edited the README to match the new template, so this likely should be rebased. |
|
On 10/8/20 8:14 AM, Marcin Hoppe wrote:
Looks like we have a pretty tight deadline to meet to nail down the
scope before the OpenSSF press release.
@RedHatCRob <https://github.com/RedHatCRob> do you think we could
incorporate the remarks from @mdressman <https://github.com/mdressman>
and merge?
As far as I understand, we have the consensus about the objectives
themselves?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#52 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQRFDLAKGE22XBWTEEM4UHTSJWUJXANCNFSM4R7AFSVA>.
I think that is fine, yes we had agreement from the call about the
objectives
…--
That 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: CRob@RedHat.com
Red Hat Product Security contact: secalert@redhat.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
proposed vision/and objectives for the WG