Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update README.md #52

Merged
merged 1 commit into from Oct 19, 2020
Merged

Update README.md #52

merged 1 commit into from Oct 19, 2020

Conversation

SecurityCRob
Copy link
Collaborator

proposed vision/and objectives for the WG

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a suspicion nobody here thinks the existing industry formats work :)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With that in mind, do you feel coming up with alternatives is something we should be focusing this WG on?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

@mdressman mdressman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @RedHatCRob!


- 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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe "develop" in place of "mature"? ...by helping develop and advocate well-managed...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

verb tense, We plan on addressing this challenge...

@MarcinHoppe
Copy link
Collaborator

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?

@MarcinHoppe
Copy link
Collaborator

I also edited the README to match the new template, so this likely should be rebased.

@SecurityCRob
Copy link
Collaborator Author

SecurityCRob commented Oct 9, 2020 via email

@MarcinHoppe MarcinHoppe mentioned this pull request Oct 19, 2020
@MarcinHoppe MarcinHoppe merged commit ea15336 into ossf:main Oct 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants