Will the WG support both CPE (v2.3) as well as SWID Tags

[kerberosmansour]

Hello, I noticed a line item in the meating notes: "Drop PURL in favor of the format used by CVE " which is fine given the package name + echo-system will be added.

However I wanted to clarify "which" format that is planing to be supported. NVD leverages CPE 2.3 currently (And plan to move to SWID at some point).

Can you confirm that the plan is to drop PURL in favour of CPE 2.3?

[bwillis]

Can you confirm that the plan is to drop PURL in favour of CPE 2.3?

I may be mistaken, but don't remember us taking the stance on using CPE explicitly, but I do remember we were more avoiding the usage of PURL because it was missing ranges/wildcards, here's the conversation from the original PR:

@bwillis on Jul 29
Probably not something we can answer right now, but PURL doesn't have an opinion on version ranges and doesn't want to support wildcards at this time, so unsure how useful this will be in the long run.

@infin8x on Jul 31
Yeah I agree. It was a nice idea initially to try and re-use PURL, but I wonder if we can go more along the lines of what I suggested for the CVE JSON: https://github.com/CVEProject/automation-working-group/blob/master/cve_json_schema/v5.x_discuss/cve513.schema#L121

@bwillis on Aug 3
Based on our meeting today, we decided that this would be best represented by the CVE format that @infin8x proposed due to aligning it with the CVE process and to the lack of ranges in PURL.

[infin8x]

Yeah, its a good question @kerberosmansour. Personally I'm not a huge fan of either SWID or CPE (they're both very verbose and IMO don't really translate to open source, and particularly packaged OSS, that well). My thought was to just use the package ecosystem and name, and then a range of SemVers (which is also possible in the CVE v5 schema).

[kerberosmansour]

Sounds good, I trust your judgement. Should we reach out to PURL team and work with them to provide ranges + wilder card for consideration later?

[infin8x]

Maybe? Would love to see this format get off the ground first so we have some justification for asking.

[pombredanne]

Hi 👋
PURL founder here. I look forward to the discussion!

Version ranges (or more generally version constraints and that would include any wildcards or globs) are not an easy thing as there cannot be a universal definition since there is no universal way to represent and compare versions across all package types.

To add them to PURL, we could either have a partly universal/partly type-specific approach or be entirely package type-specific.

a partly universal/partly type-specific approach

• Define a base universal notation (universal as used for any package type / ecosystem)
• Delegate the semantics of version comparisons (which are essential to a proper definition of an ordered range of versions) to each package type with a possible sensible default (such as semver)
• have a conversion/mapping that would translate the universal notation to the package type-specific one

an entirely package type-specific approach

• Accept that version ranges are entirely package type-specific and do not attempt to define some universal notation and mappings
• And always use the package type notations/version comparison.

IMHO the package type-specific approach is simpler, self-explanatory as it does not define any new notation and convention by reusing the package one and above all is always correct. Trying to define some universal notation has been something attempted in CPE and I am not sure this has been working OK. It would always be a compromise of sorts with some dark corners. The semantics differences of Python vs. Debian vs.RPM vs. Ruby vs. npm and semver are often minor but I think the details can matter a lot.

In all the cases, the other item is about where to put this version range. I do not think it belongs to the version attribute. Instead it should be its own and would therefore be best as a standard qualifier with a name TBD such as version_range or version_constraints.

Some ideas of what the semantics could be:

• if a version is provided then that's the one version this purl is for.
• if no version is provided and a version range qualifier is provided, then the purl if for that range
• if no version and not version range qualifier is provided, then the purl if for any version

ping to package-url/purl-spec#66

[pombredanne]

@sbs2001 ping for you too since you pointed me to this ticket as part of your work on https://github.com/nexb/vulnerablecode :)

[bwillis]

Oh nice thanks for point that out @pombredanne - looks like @sbs2001 is trying to solve exactly the same problems!

[JasonKeirstead]

Also see SPDX and CycloneDX.

All 3 (SWID, SPDX, CycloneDX) are candidate standards for the work going on in SBOM working group ( see: https://www.it-cisq.org/software-bill-of-materials/ ). A large amount of overlap between members of this working group, and the SBOM working group....

[SecurityCRob]

CPE is a requirement for commercial vendors to supply, so a group of us will always have to deal with it and its progeny. It looks like cpe will be deprecated in ~2 years, so we have until 2022ish to work with industry on what a viable replacement it. While SWID has "some" commercial support (mostly as a request by some public sector customers) it is far from decided yet what can/will replace cpe. I think if we came together and had a simple, reasonable approach that is broadly accepted in our communities we have a large ability to influence industry direction.

[JasonKeirstead]

@RedHatCRob Onè other aspect here I will raise, is there have been conversations surrounding SCAPV2 with some major stakeholders and a desire to move away from CPE and CCE there as well. Both are regarded as somewhat not fulfilling current needs.

[joshbressers]

I'm migrating my comment from #17

I'm trying to put an advisory into json format to see what I think of the schema, here is my current content
https://github.com/joshbressers/wg-vulnerability-disclosures/blob/schema/src/schema/ESA-2020-10.json

The versions are going to be the sticking point I suspect. In my case it's not even that complex
versions before 6.8.11 and 7.8.1
But the current format doesn't really accommodate this.

I'm asking the purl crew if they have suggestions
package-url/purl-spec#84 (comment)

disclaimer: I really like purl

I'm open to any other suggestions if anyone has any

Thanks in advance

[fcanogab]

Does anyone have a link or can explain what are the problems of CPE? What are the reasons NVD and other stakeholders want to drop it? I have found this link [1]. What it describes seems more a process problem than a technical problem with the specification.

[1] https://www.veracode.com/blog/managing-appsec/using-cpes-open-source-vulnerabilities-think-again

[JasonKeirstead]

@fcanogab I think the blog you linked summarizes all the key issues with CPE quite nicely. It is not just a process problem, its a problem that partially originates with the format itself. CPE works OK for commercially produced software. It does not work well for shared libraries distributed by many vendors, and works horribly for rapidly evolving open source libraries.

[kerberosmansour]

Hi @pombredanne

Thinking about the versioning range a bit more I like the entirely package type-specific approach here are my thoughts on the subject.

The problems that are attempted to be solved here are (AFAIK):

• What are the set of software versions impacted by a specific vulnerability
  -- e.g. a CVE impacts Tomcat 5.7 (and below) and Tomcat 6.5 (and below)
• What are the fix versions associated with the vulnerable software
  -- Tomcat 5.8 fixes the CVE for Tomcat 5.7 (and below) and Tomcat 6.6 fixes the CVE for Tomcat 6.5 (and below).
• We can locate these software artifacts in an automated way via specification.

Now looking at @infin8x note the metadata provided would answer these questions. I would say to be pedantic we would want package ecosystem, name, Org (optional), and repo (optional).

The reason why you would want to org and the artifact repo is sometimes a user who cares about a specific "vendor/OSS Foundation" software suite they'd like to search via that object. Also sometimes like in the case of some ecosystems or container images there isn't the one container image repo that everyone uses - the software that is leveraging the spec would need to know if it's not the default artifact repo to use.

So for PURL to go down the entirely package type-specific approach it is till possible to achieve these goals for a few reasons:

• Currently any piece of software has it's own versioning schema, and that is reflected in package URL already (and CPEs), so adding a range property should not be an Issue. NVD does this with CPE 2.3 (i'll get to that in a sec).

• You can have the user agent leveraging the PURL spec to pull each individual impacted package version by looking at the impacted software versions (e.g. from x to y) and query the release history in a repo to list each impacted version in that range.

So effectively you are shift solving the problem from the spec to the repo. This of-course assumes that the ecosystem has the ability to query release history in an automated way (but most do AFAIK). Worth a POC?

[david-a-wheeler]

CPE supports version ranges. SWID, to my knowledge, does not.

Package-URL does not currently support version ranges, but it's not a crazy thing to ask for.

I've already submitted a proposal to package-URL to add version ranges, here:
package-url/purl-spec#93

There are complications (or this would already have been done), but I think they are solvable. If you think package-URLs should include a version range mechanism, please say so in that issue, and please help work out solutions to the problems raised there.

[kerberosmansour]

Yeah... If you look at the CPE match string conditions they also include exceptions - it be nice if we have that as well.

[kerberosmansour]

CPE supports version ranges. SWID, to my knowledge, does not.

Package-URL does not currently support version ranges, but it's not a crazy thing to ask for.

I've already submitted a proposal to package-URL to add version ranges, here:
package-url/purl-spec#93

There are complications (or this would already have been done), but I think they are solvable. If you think package-URLs should include a version range mechanism, please say so in that issue, and please help work out solutions to the problems raised there.

Done! replied to the other Issue.