0.8.0 changes

[oliverchang]

• Rename "affects" to "affected", and make it a list of objects.
• Represent version ranges using "events" rather than ranges of [introduced, fixed)
• Move "package", "ecosystem_specific", "database_specific" to "affected".

[oliverchang]

Also moved repo as discussed: 67693a7

[joshbressers]

@oliverchang To followup from our conversation yesterday (or probably your today)

I mentioned I didn't like the new "affected" and I realize why now

	"affected": [ {
		"package": {
			"ecosystem": string,
			"name": string,
			"purl": string,
		},
		"ranges": [ {
			"type": string,
			"repo": string,
			"events": [ {
				"introduced": string,
				"fixed": string
			} ]
		} ],
		"versions": [ string ],
		"ecosystem_specific": { see description },
		"database_specific": { see description },
	} ],

I think the way CVE overloads the package field in an ID is wrong in the modern world. It made sense 20 years ago

Here is the example that made me realize this. It's the same problem for copy and pasting code, or embedding source files, so I ask whoever reads this not to nitpick it too much. It's a hard problem.

Let's say I have a npm project, npm will embed the dependencies, so for example it's VERY common for a project to ship multiple copies of the lodash library as different packages can depend on different versions.

If there is one vulnerability in lodash, today it would get one ID and you would see your application is affected by the same ID multiple times. This means you actually have to key off package:ID, because just the ID isn't enough useful information.

Now, package:ID as the key may not be the worst thing in the world, but it probably creates some new challenges we don't understand. Today I think just using an ID is the most common use case. I want to think about this more, but I wanted to suggest that allowing an array of packages should not be taken lightly.

[kaniini]

I don't follow this argument, any scanner worth anything should automatically dedup any reported vulnerabilities, I think.

[joshbressers]

I don't follow this argument, any scanner worth anything should automatically dedup any reported vulnerabilities, I think.

It's not about the dupes so much as it is about having a way to understand what is vulnerable to a given problem. I could be off my rocker here as well, this makes sense in my head.

Let me just make something up to illustrate my thinking. This is a little unrealistic I know.

Let's say I have a project, and there are two different libraries that run as webservers to service REST requests. The two libraries each share one common source file that is vulnerable to a RCE. In today's model, that would be one ID both libraries share, even though they are unrelated.

Is that acceptable, or would it be better to give each library their own ID?

From a purely automated perspective, it doesn't really matter. But if I have to discuss this problem with a fellow human, I now have to clarify which library we are talking about as part of the conversation, so the identifier is really package:ID, not just the ID

[kaniini]

I get what you're saying there. In that case, I think a scanner should present it as two vulnerabilities, but prefixing it as subcomponent:ID. But the scanner can do that itself, can't it?

[oliverchang]

Thanks for the feedback!

I completely agree that in most cases, there should only ever be one package specified in a single entry (and this is what we strongly recommend), and we really wanted to keep this.

But for ease of adoption, I think we need to make a tradeoff to support interoperability with other schemas (such as CVE, GHSA) which do support (and rarely) have multiple packages listed (example: https://github.com/advisories/GHSA-wh77-3x4m-4q9g). Otherwise, this is adding burden on them to generate new IDs/entries in a way that may not fit easily into their existing workflows.

We also got feedback from the Go vulnerability DB team, who wish to express that same package may have different import paths/names (vanity URLs, versioned imports) and they don't want to create separate entries for each, because it adds complexity for them.

I get what you're saying there. In that case, I think a scanner should present it as two vulnerabilities, but prefixing it as subcomponent:ID. But the scanner can do that itself, can't it?

I agree! The scanner would already know about what package it's scanning for, and then it just has to correlate that with what's listed in the vulnerability entry.

[joshbressers]

I think this is all fair, I appreciate your explanation

[pombredanne]

@oliverchang Singling out semver as being a perfect version scheme assumes that humans handling semver versions will never break semver. I think that this cannot hold at scale.
IMHO there is no reason to treat SEMVER specially and I explained some rationale in the related CVEProject/cve-schema#87 (comment)

Instead a version range may best treated as what it is: a hint for tools and humans to help form a proper versions enumeration.

[oliverchang]

Thanks for the feedback @pombredanne. I agree an explicit list of versions makes this unambiguous in all cases.

I think tooling/validators can help with making sure the SEMVER values are valid. One other reason why we need this is that in ecosystems like Go (which use/enforce Semver), it's infeasible to enumerate every possible version. Every commit can be a "pseudoversion" (valid semver) in Go.

[pombredanne]

Thank you for the clarification. This makes sense now. I had not internalized this aspect of Go modules versioning. That's actually pretty sleek and clean. It creates some extra work when trying to enumerate these when compared to other package types... but that's an issue for tools/db to deal with..!

[rsc]

For consistency with CVE and easier conversion I think we should use 0 here.
* meaning zero in one field and * meaning infinity in another is odd anyway.

[rsc]

Other than the 0 I'm happy.

[rsc]

LGTM