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
176 stars 40 forks source link

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

Open kerberosmansour opened 3 years ago

kerberosmansour commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

pombredanne commented 3 years ago

Hi :wave: 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

an entirely package type-specific approach

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:

ping to https://github.com/package-url/purl-spec/issues/66

pombredanne commented 3 years ago

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

bwillis commented 3 years ago

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

JasonKeirstead commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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

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:

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 commented 3 years ago

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: https://github.com/package-url/purl-spec/pull/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 commented 3 years ago

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

kerberosmansour commented 3 years ago

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.