Make "cpeApplicability" structure generic.

[alilleybrinker]

This "renames" (not actually a rename, see below) the existing
"cpeApplicability" structure and its children from CPE-specific names
to generic names. For example, "cpeApplicability" becomes "applicability."

This is intended to permit future record format updates to add support for
additional kinds of software identifiers. This change itself does not add
any new kinds of software identifiers.

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.

Original message from before the PR was split into three parts.

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.

[alilleybrinker]

@darakian, you'd asked if we make the cpeApplicability and applicability structures exclusive in the schema, and yes we do, though the pattern may be non-obvious.

First, here's an explainer: https://groups.google.com/g/json-schema/c/PiT9ZndbcCI

Second, here's what it looks like in the schema (this is done under both the cnaPublishedContainer and adpContainer):

"allOf": [
    <snipped...>
    {
        "not": {
            "required": ["applicability", "cpeApplicability"]
        }
    }
],

The allOf containing a not with a required underneath establishes a validation constraint which will reject any object which includes both the applicability and cpeApplicability structures.

[sethmlarson]

I'm happy with PURLs not containing version information, that information is best encoded into the "affectedness" version ranges whereas the PURL is for identifying which records are relevant for a product.

I don't think we'd need to vendor the entire PURL spec? I think keeping things relatively open-ended in terms of values should work just fine, after all there is a strong incentive for PURL users (ie: mostly open source projects) to have their records be discoverable by downstream users.

[oej]

As PURL is being standardised as part of the CycloneDX TC54 process there's no need for vendoring at this point, just a dialogue with the work group that works on PURL. Philippe Ombredanne is the lead.

[alilleybrinker]

As PURL is being standardised as part of the CycloneDX TC54 process there's no need for vendoring at this point, just a dialogue with the work group that works on PURL. Philippe Ombredanne is the lead.

Yes, we've talked with Philippe and with Steve Springett. The rough consensus from the QWG so far has been that if CVE ships support for purl, it would either need to be vendored or they'd need to wait until the ECMA standard is official. There was not much support for moving forward with purl with only a reference to the specification as it exists on main in the Git repo.

[alilleybrinker]

@darakian, you'd asked if we make the cpeApplicability and applicability structures exclusive in the schema, and yes we do, though the pattern may be non-obvious.

First, here's an explainer: https://groups.google.com/g/json-schema/c/PiT9ZndbcCI

Second, here's what it looks like in the schema (this is done under both the cnaPublishedContainer and adpContainer):

"allOf": [
    <snipped...>
    {
        "not": {
            "required": ["applicability", "cpeApplicability"]
        }
    }
],

The allOf containing a not with a required underneath establishes a validation constraint which will reject any object which includes both the applicability and cpeApplicability structures.

I had a brief conversation with @ccoffin where he raised that it may not be desirable to disallow use of both applicability and cpeApplicability together. I think it probably does make sense to disallow using both, but wanted to raise the issue here for discussion.

[darakian]

I had a brief conversation with @ccoffin where he raised that it may not be desirable to disallow use of both applicability and cpeApplicability together. I think it probably does make sense to disallow using both, but wanted to raise the issue here for discussion.

Just to clarify this is about using both structures in the same record at the same time correct? I agree that they should be mutually exclusive structures, but maybe there's a use case I'm not considering. If so, @ccoffin can you expand on the rational for allowing both at the same time?

[alilleybrinker]

Closing this, as the project has opted for an approach based on the affected array.