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

Document CSAF CVRF version 1.2 #72

Closed esarafianou closed 3 years ago

esarafianou commented 3 years ago

Documents CSAF CVRF version 1.2 as part of #67

esarafianou commented 3 years ago

@mprpic I updated the PR, I think I've included all your recommendations:

MarcinHoppe commented 3 years ago

@esarafianou how well would those standards work in the OSS context? Are there any gaps that need to be addressed?

esarafianou commented 3 years ago

@MarcinHoppe Here is my summary:

  1. CSAF CVRF v1.2 is not easily human readable as it's XML. This should be improved once v2.0 is released which is based on the JSON schema
  2. Based on @mprpic comment, there aren't any CVRF generator tools making it difficult for Open Source contributors to start using it as a standard as they'd need to manually create the XML document.
  3. In general my impression was that it's more suited to vendors than open source maintainers but I'd like to hear the thoughts of our Red Hat folks as they've been using it a lot.
mprpic commented 3 years ago
  1. CSAF CVRF v1.2 is not easily human readable as it's XML. This should be improved once v2.0 is released which is based on the JSON schema

JSON is also not readable, in my opinion :-) But I don't think human readability should be the concern of different metadata formats. The point of these schemas is to represent the data in a standard format so it can be parsed and interpreted by w/e tooling uses the data (e.g. a website application or a vulnerability scanner).

  1. Based on @mprpic comment, there aren't any CVRF generator tools making it difficult for Open Source contributors to start using it as a standard as they'd need to manually create the XML document.
  2. In general my impression was that it's more suited to vendors than open source maintainers but I'd like to hear the thoughts of our Red Hat folks as they've been using it a lot.

Sharing CVRF generators is difficult because the data that you use to populate a CVRF file comes from different sources for every vendor or maintainer. The OpenSSL project may have a very different representation of CVEs internally from e.g. the Django project. It may be up to security advisory aggregators and package indexes to implement CVRF as an output format. I think it would be ideal to have a CVRF representation of the following pages:

I would love to hear from others in the community on this though. My view may be biased by the fact that Red Hat builds products built on top of open source components so we are naturally very interested in any vulnerability information published for all those components. But processing it is painful specifically because it often comes in the form of blog posts or plain text pages (I've even built a small lib to parse specific advisory plain text / HTML formats into a common representation: https://github.com/mprpic/advisory-parser/).

JasonKeirstead commented 3 years ago

I agree that a project to take a plain-text advisory and auto-generate CVRF would be very challenging.

Perhaps what could help would be a webform-based CVRF "builder tool", something that makes it dead-simple for a maintainer to create an advisory without having to get a Ph.D in CVRF.