Add cpe identifiers to OS products #2525
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After the discussion in purl-spec around adding an
os
candidate type was rejected, I went to thinking about what identifiers we could use to match OS releases.@captn3m0 mentioned using CPEs in Integrate with the SBOM Ecosystem #763
Steve Springett mentioned using the PURL
swid
type in this commentI think that endoflife.date could support both. But the only thing to note about the
swid
type in the purl spec is that the qualifiertag_id
is NOT optional. This is the only qualifier I'm aware of that's not optional. I think that because of this, matching onswid
would be much more difficult than matching on CPEs, if we wanted to remain compliant with purl-spec (probably should).So, in order to find some kind of path forward, I added this PR, which adds cpes 2.2 and 2.3 for different operating systems. Most of these CPEs I grabbed from syft.
The identifier I added is like
- cpe: <cpe2.2>
or- cpe: <cpe2.3>
but we could also namespace according to cpe version in the key such as- cpe22
or- cpe23
, looking for your feedback.