Document CSAF CVRF version 1.2

[esarafianou]

Documents CSAF CVRF version 1.2 as part of #67

[mprpic]

It might be worth noting that the 2.0 version of the schema (which uses JSON schema instead of XML) is in development: https://github.com/oasis-tcs/csaf/tree/master/csaf_2.0/json_schema

Would it be useful to list more real-world examples of vendors publishing security advisories in the CVRF format? I know of at least these:

• ftp://ftp.suse.com/pub/projects/security/cvrf/
• https://tools.cisco.com/security/center/cvrfListing.x
• https://www.redhat.com/security/data/cvrf/ (obviously :-))

As for tools that parse CVRF, there are:

• https://github.com/oasis-open/csaf-parser
• https://github.com/mschiffm/cvrfparse

I don't know of any CVRF generator tools. I suspect none exist because generating a CVRF heavily depends on the way each vendor keeps track of security metadata internally. Though, I could imagine some tool that would take as input CVEs in the MITRE JSON schema, request some input interactively, and spit out a properly formatted CVRF file.

Great write-up, @esarafianou!

[mprpic]

Suggested change

	* Organzation
	* Organization

[mprpic]

Suggested change

	* Decription
	* Description

[mprpic]

Suggested change

	### RedHat real example
	### Red Hat real example

[mprpic]

These namespace specifications aren't really all that useful for this example. I would just omit them and note it down in the explanation to reduce noise a bit. Wdyt?

[esarafianou]

Agreed, I'll remove them all

[mprpic]

Note that the product ID is completely arbitrary and has meaning only in the context of the CVRF file. The ID can simply be 1, 2, and 3 for different product trees. The point of the ID is to refer to a product in various parts of the vulnerability element, so the "-on-bar" and "-on-baz" don't actually have any meaning here.

[esarafianou]

I'll re-word this point to make it more clear, thank!

[esarafianou]

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

• Real world examples
• CVRF parsers
• Note about versions 2.0

[MarcinHoppe]

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

[esarafianou]

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

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

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.

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:

• GHSA-gxr4-xjj5-5px2
• https://www.npmjs.com/advisories/1543
• https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html

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]

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.