Add support for Package URLs and OmniBOR Artifact IDs in the CVE Record Format.

[alilleybrinker]

This adds support for Package URLs and OmniBOR Artifact IDs to be embedded in CVE records by introducing a new "applicability" structure for both CNAs and ADPs. This "applicability" structure is intended to replace usage of the existing "cpeApplicability" structure added recently for CPE support. It extends the prior schema of "cpeApplicability" in a backwards-compatible way, defining new "purl_match" and "omnibor_match" structures alongside the existing "match" now renamed "cpe_match".

The prior "cpeApplicability" structure remains entirely supported, though CNAs and any future ADPs enriching with software ID information should be encouraged to use the more expressive new "applicability" structure instead, and use of both at the same time should be treated as an error to avoid ambiguity.

This also opens the possibility of introducing more software identification schemes in the future by adding new "_match" variants within the "applicability" structure.

EDIT: This previously included two commits, the first of which was a formatting of the record format JSON file by a JSON auto-formatter. This commit has been removed, and the diff is now clean and only shows the relevant semantic changes.

[alilleybrinker]

Probably ought to bump the version number of the schema itself prior to merging this PR. Right now that would be 5.1.2 under SchemaVer (though we use . separators not - separators as SchemaVer defines).

[alilleybrinker]

Feedback from QWG meeting:

• Constrain the purl schema to explicitly disallow version information.
  • Would this demand vendoring the purl spec?
• How to handle the purl generic type?
  • Also a complexity with the go type, where the purl spec doesn't match Go's expressiveness (purl is case-insensitive while Go is case-sensitive)
• Did we consider limiting number of identifiers?
  • No, we didn't
  • There may be a need to consider how to deal with the "lots of identifiers" case.
  • CVE records do have an existing size limit.
• How does this relate to the affected block, which also encodes version information?

[alilleybrinker]

The PR has been updated to point at develop instead of main. I'll be rebasing it to both remove the formatting and fix the merge conflict that has arisen.

EDIT: The rebase is done. No fixes from the feedback have yet been incorporated, but the diff should now show the correct information and there's only one commit.

[darakian]

To get some conversation going here I think there are three things going on in this PR

1. A rename of the cpeApplicability block to simply be an Applicability block. As I understand the jsonschmea (and I am no expert) this is done as an addition of a new block which will (for the time being I assume) live side by side with the older block. I don't see any limitation restricting the use of both blocks at once. Not sure if that's intentional or if its just not worth restricting the use given that these two should be merged eventually.
2. Two new software identifiers are introduced (applicabilityElements in the schema I think).
3. For one of those new identifiers (purl) there is the question of forking/vendoring.

As I recall from the QWG meeting I think everyone is philosophically onboard with point 1. Point 2 somewhat depends on the forking question in 3, so where are people on that? Perhaps we should also consider what qualities we want/need out of a software identifier so that we can weigh the pros and cons.

[ccoffin]

I believe that we also should separate the addition of PURL and OmniBOR in their own distinct PRs. The thinking is that these two additions will be prioritized differently and may be released separately.

I would also like to understand more regarding the intent for item 1 in Jon's comment. Maybe we can have a quick discussion in the 3/27 meeting.