Poll: should new software identifiers be able to fill the "identifier-like" requirement for objects in the affected array?

[alilleybrinker]

In #407, we've proposed the introduction of support for new software identifiers via the addition of fields to the product object inside the affected array.

Currently, the product object has a requirement that at least one set of "identifier-like" fields must be present. Today those can be:

• vendor and product
• collectionURL and packageName

The question at hand is: should these proposed new fields for new identifier types be able to fulfill this "identifier-like" requirement?

A detailed breakdown of the trade-offs can be found here: #409 (comment)

Examples of product objects where the new fields can or cannot fulfill the "identifier-like" requirement can be found here: https://gist.github.com/alilleybrinker/de8f56ba599609f7867bc5589c73505b

This poll is to gauge the preference the QWG has for the two options:

• Option 1: New identifier fields can fulfill the "identifier-like" requirement.
• Option 2: New identifier fields cannot fulfill the "identifier-like" requirement.

To vote, please react to this post with the emoji matching your choice:

👍🏻: Vote for Option 1, where new fields can fulfill the "identifier-like" requirement.
🚀: Vote for Option 2, where new fields cannot fulfill the "identifier-like" requirement.

Note

Why not make a "real" poll?

GitHub Discussion's poll feature doesn't show who voted for what option, which would permit non-QWG participants to vote without us being able to know. Voting-via-emoji does show who clicked each emoji, which lets us validate voters.

Warning

This poll will close at 1pm PDT / 4pm EDT on Thursday, June 26th.

[ElectricNroff]

I don't feel that this poll is worthwhile because people may realistically favor at least a few other options:

1. Some may feel that pkg:npm/color is something a human can understand as a specific piece of software but gitoid:blob:sha256:9f64df92367881be21e23567a31a8ce01994d98b69d28917b5c132ce32a8e6c8 perhaps isn't
2. Some may feel that gitoid:blob:sha256:9f64df92367881be21e23567a31a8ce01994d98b69d28917b5c132ce32a8e6c8 would be OK if a different element of an affected array, perhaps even in a different container, has human-readable software identity that is somehow known to include gitoid:blob:sha256:9f64df92367881be21e23567a31a8ce01994d98b69d28917b5c132ce32a8e6c8 and maybe other frequently seen objects (such as the same code with different whitespace)
3. Some may feel that providing only collectionURL and packageName is sufficiently uncommon that it should be deprecated
4. Some may feel that submitting a container with only pkg:npm/color should cause the CVE Services server to put color into the product field
   4a. if we choose to rely on server-side extraction of product from a Purl, maybe vendor would become optional?

[alilleybrinker]

This poll is purposefully agnostic about the specific formats in the RFD, and is instead trying to resolve the general question of whether new identifiers should be introduced as new fields and be able to fulfill the "identifier-like" requirement.

collectionURL and packageName are both widely used. For example, a quick GitHub search of the cvelistv5 repository shows more than 10,000 CVE records with the collectionURL field present: https://github.com/search?q=repo:CVEProject/cvelistV5%20%22collectionURL%22&type=code

As for the idea of CVE Services auto-filling in additional fields based on a packageURL, I don't believe CVE Services generally does this kind of editing of the CNA container, and in fact that any proposal to do so would be strongly rejected by the QWG and the Board.

---

I'd also like to clarify whether any of these represent your view, and if they do, whether you'd like to advance a more detailed proposal for them.

[ElectricNroff]

This poll is purposefully agnostic about the specific formats in the RFD, and is instead trying to resolve the general question of whether new identifiers should be introduced as new fields and be able to fulfill the "identifier-like" requirement.

collectionURL and packageName are both widely used. For example, a quick GitHub search of the cvelistv5 repository shows more than 10,000 CVE records with the collectionURL field present: https://github.com/search?q=repo:CVEProject/cvelistV5%20%22collectionURL%22&type=code

As for the idea of CVE Services auto-filling in additional fields based on a packageURL, I don't believe CVE Services generally does this kind of editing of the CNA container, and in fact that any proposal to do so would be strongly rejected by the QWG and the Board.

My understanding now is that this is a poll on a hypothetical question.

One of the two options is: New identifier fields cannot fulfill the "identifier-like" requirement.

"cannot" is a strong word.

The plain meaning seems to be:

Option 2: Vote for this if you feel it will never be appropriate to do this fulfillment in any other way, regardless of whether the change would be introduced in a much later version of the schema, and regardless of whether the common mechanisms for distributing and labeling software evolve in the future. In other words, we shall lock in vendor/product and collectionURL/packageName.

Option 1 perhaps encompasses everything else, e.g., all positions ranging from "the identifier-like selections should routinely have an expansion" to "when making a major schema change in the future, an expansion would be likely" to "because the question is hypothetical, and my answer must be agnostic, I agree that expansion is merely possible."

Here, even if we were to "resolve the general question," we would still have little guidance about what to actually do.

Incidentally, "providing only collectionURL and packageName" above was meant to mean that product was not provided. This has occurred, but remains far below one percent, and most instances seem incorrect (e.g., CVE-2024-22050 looks fine, but CVE-2024-43430 suggests that https://github.com/moodle/moodle is a collection in which moodle is one of the packages). Declaring collectionURL/packageName to be insufficient would have little operational impact on producers.

Finally, the server already modifies submitted CNA containers in two ways (such as for trailing spaces and any \u usage) before storage, so I feel that extracting product from a Purl before storage may have some support in the community.

[alilleybrinker]

As we'd discussed in the QWG meeting last week, the poll is about what to do with the current proposal, with an eye toward establishing norms around the handling of constraints, and is also an informal reading of the preferences of the group. It is not preclusive of updating the constraints in the future. It is a question of whether, when new identifiers are added they should also be permitted to fulfill the "identifier-like" requirement of the product object.

Any specific rules or limitations on the compatibility practices of the QWG that are more rigorous that the normative approach taken here would need to be addressed by a future versioning RFD (see #418).

I'm not sure the point you're making about whether product is also included. There is nothing here that's "delcaring collectionURL/packageName to be insufficient."

As for modifying CNA containers, I think there is an enormous difference between formatting cleanup like trimming trailing spaces or normalizing unicode literals and content changes like introducing new fields derived from fields provided by the CNA within the CNA container.

[ElectricNroff]

I'm not sure the point you're making about whether product is also included. There is nothing here that's "delcaring collectionURL/packageName to be insufficient."

I didn't understand your comment here about declaring insufficient.

This was not part of your poll description; it is part of my objection to your poll. You offered the options of either "more than vendor/product and collectionURL/packageName" or "only vendor/product and collectionURL/packageName" whereas I wanted an option of "less than vendor/product and collectionURL/packageName" too.

Reasons for declaring collectionURL/packageName to be insufficient include:

1. Alignment with the survey results. Many people valued "Affected product listing (current CVE product and version data)." There were no comments directly stating that collectionURL and packageName were helpful. A CVE Record that has packageName but not product might make it harder for consumers to find valuable information.
2. As mentioned above, it's far below one percent.
3. Today, it interferes with the semantics of affected by introducing ambiguity (although this can have a separate solution; see below).

The ambiguity today is that if collectionURL/packageName is used alone, then the remaining properties of an affected array element apparently apply to the packageName. Thus, if both vendor/product and collectionURL/packageName are used, the remaining properties of an affected array element may apply to either one or the other, or both. In this contrived example, versions and modules apply to the Debian package but repo and programFiles apply to the same software distributed on GitHub. Even though data.tar.xz is one of the three sub-components of the Debian package (the .deb file), it doesn't exist on GitHub, and thus someone installing from GitHub might falsely conclude that they aren't vulnerable. Similarly, the Debian package doesn't have lodash.default.js.

"affected": [
 {
   "vendor": "Lodash core team",
   "product": "Lodash",
   "collectionURL": "https://packages.debian.org",
   "packageName": "node-lodash",
   "defaultStatus": "unaffected",
   "versions": [
    {
      "version": "4.17.21+dfsg+~cs8.31.198.20210220-1",
      "lessThan": "4.17.21+dfsg+~cs8.31.198.20210220-10",
      "status": "affected",
      "versionType": "custom"
     }
   ],
   "modules": ["data.tar.xz"],
   "repo": "https://github.com/lodash/lodash",
   "programFiles": ["lodash.default.js"]
  }
]

The ambiguity could become worse if an affected array element can refer to arbitrary software identifiers, e.g., if there is a SWHID with no qualifiers, and an absolute pathname in programFiles, then is this an absolute pathname at an OS level, or is it relative to the top-level directory of the software?

Also, it's unclear how one would merge this into the above affected array element:

"affected": [
 {
   "artifactID": "gitoid:blob:sha256:9f64df92367881be21e23567a31a8ce01994d98b69d28917b5c132ce32a8e6c8",
   "artifactType": "artifact",
   "defaultStatus": "affected"
  }
]

because "defaultStatus": "affected" only applies to the artifactID, and neither to the product nor the packageName.

A possible solution is updating the schema documentation to state that all of these must be correct as additional attributes of product (a required data element) and may be inapplicable to any optional software identifier: vendor, modules, programFiles, programRoutines, platforms, repo, defaultStatus, and versions. For example, "defaultStatus": "unaffected" does not ever indicate that the producer is providing an artifactID of an unaffected artifact.

There are other reasons, related to a type of completeness check, for artifactID/artifactType to not live alone in its own affected array element. In most cases, a vulnerable artifact is present because one of a set of specific versions of a product (or similar products) is present. Expressing a relationship between Artifact IDs and product/version information is especially important to consumers because the OmniBOR data formats cannot enforce completeness. Specifically, although a CVE Record could conceivably contain any number of Artifact IDs or Input Manifests, there is no direct way for a consumer (e.g., in investigating unexpected vulnerability scan results) to check whether a producer bothered to consider applicable artifacts across the entire range of affected versions. For example, suppose all of these are true:

• the vulnerability was originally thought to affect versions 1.2.0 through 1.2.3
• the consumer knows it was recently found to also affect 1.2.4
• the affected file in 1.2.4 is semantically the same as in older versions but has a different sha256

then (with the currently proposed integration of OmniBOR and CVE) the consumer has no way to know whether the producer already updated the set of artifactIDs to include a 1.2.4 leaf artifact, whether the producer is planning to do this soon, or whether it may never happen.

For this reason, at least during the early adoption of OmniBOR, it seems very important to have a direct human-readable association to the sha256 binary data (similar to the origin qualifier in SWHIDs). Later, we may end up with a community of excellent OmniBOR practitioners, and it may be reasonable for all consumers to have blind faith that that 1.2.4 leaf artifact would be added promptly. There might be inelegant ways to achieve human readability in the current data format, e.g.,

"affected": [
 {
   "vendor": "Lodash core team",
   "product": "Lodash",
   "collectionURL": "https://packages.debian.org",
   "packageName": "node-lodash",
   "versions": [
    {
      "version": "4.17.21+dfsg+~cs8.31.198.20210220-1",
      "lessThan": "4.17.21+dfsg+~cs8.31.198.20210220-10",
      "versionType": "custom",
      "status": "affected",
      "changes": [
       {
         "at": "gitoid:blob:sha256:9f64df92367881be21e23567a31a8ce01994d98b69d28917b5c132ce32a8e6c8# aka lodash.min.js in 4.17.21+dfsg+~cs8.31.198.20210220-1",
         "status": "affected"
       },
       {
         "at": "gitoid:blob:sha256:8246427248247262782464261784884726427246253427742746246642624686# aka lodash.min.js in 4.17.21+dfsg+~cs8.31.198.20210220-2",
         "status": "affected"
       },
       ...
       {
         "at": "gitoid:blob:sha256:9282973772763772772cd6637373883819377238826378823773888277288254# aka lodash.min.js in 4.17.21+dfsg+~cs8.31.198.20210220-9",
         "status": "affected"
       }
      ]
     }
   ],
   "modules": ["data.tar.xz"],
   "repo": "https://salsa.debian.org/js-team/node-lodash",
   "programFiles": ["lodash.min.js"],
   "defaultStatus": "unaffected"
  }
]

but changes/at is probably not best, and the structure might end up like:

"affected": [
 {
   "vendor": "Lodash core team",
   "product": "Lodash",
   "versions": [
    {
      "version": "4.17.21",
      "status": "affected",
     }
   ],
   "identifiers": {
     "omniBor": [
      {
        "artifactID": "gitoid:blob:sha256:773483634838948762384732633347ef83778738372367383837627238843812",
        "artifactType": "artifact",
        "leaf": true,
        "notes": "lodash.default.js from (for example) the 4.17.21-es GitHub tag on 2025-06-26T01:00:00Z"
      }
     ]
   }
 }
]

To summarize: I feel it would be best to start with product in every element of an affected array, and other important identifiers can be introduced in a way that encourages adoption by CVE consumers.

[alilleybrinker]

@ElectricNroff this sounds like a compelling future proposal, but there's a lot of nuance to discuss and tease out in what you've proposed. I highly recommend writing an RFD if you'd like to propose a deeper set of amendments to the affected array like you've sketched out here, perhaps as a companion to #421. I do think what you're discussing is beyond the scope of the poll here, and beyond the scope of the proposal in #407 that we're discussing.

The level of change you're proposing would, I think, need to be in a 6.0.0 version. I recognize we haven't solidified versioning rules (see #418), but in any sensible versioning scheme I think this level of churn in the format would be considered breaking, as it would require substantial changes for both CNAs and CVE consumers.

All this to say, I think your ideas are compelling and that there's an opportunity for a rethinking of the affected array in 6.0.0, alongside improvements to CPE handling and possible unification with the cpeApplicability object (to reduce to having only one place for applicability info to go within a CVE Record). I highly recommend you put forth an RFD, or even for now open an issue, sketching out the changes you'd like to see in the Record Format.

[Chris-Turner-NIST]

Thoughts:
For the sake of ensuring that notably useful data that can be used to create alias mappings and future "stuff", I do not think that it would be a good idea to remove this requirement.
As things currently stand, the effort for including additional support is important, but allowing that additional support to replace information that is considered useful seems like a step backwards.
Starting as supplemental would also allow for a soft acceptance period for various identifier-like data points, where we start them as optional and as they increase in use/viability/etc., they can become more foundational.

[alilleybrinker]

Thanks Chris! Sounds like you're advocating for a two-phase approach for handling introducing new options to a required-field constraint in the schema, where first some new field can be introduced as an optional field, and then in the future can be permitted to fulfill a required-field constraint.

[andrewpollock]

I think @Chris-Turner-NIST makes a good point here. Absent an ADP function that normalizes all CVE records to cross-resolve identifiers, I think we should avoid a situation where a CNA starts publishing CVEs using a new identifier and stops publishing them using an existing one, resulting in an immediate and uncontrolled adjustment in how these CVEs would need to be interpreted by all downstream consumers of them.

i.e. identifiers should be additive, at least until such time as there is ADP coverage to make CVEs as comprehensive as possible.

[alilleybrinker]

@andrewpollock I think the additive approach makes sense and is a reasonable path to pursue. To clarify, do you prefer that? I see you voted for letting the new identifiers fulfill the "identifier-like" requirement in the poll. Doing the additive approach would instead mean that new identifier cannot fulfill the "identifier-like" requirement (though they may be permitted to do so in the future).

[andrewpollock]

I think there's nuance here. I voted for it, from the perspective of where it is being unsatisfied today (I consider values of n/a as not satisfying the intent of product/vendor, so they're effectively useless anyway).

So I wouldn't want to see a CNA that is providing (potentially) useful values for product/vendor pivot away from that in favour of starting to supply alternative values because that forces an uncontrolled migration on the consumers.

[alilleybrinker]

@andrewpollock, right. I think the ways to deal with that would be to...

1. Vote for Option 2, or
2. To plan that the QWG will work with CNAs who do issue records with only the new fields to get them to continue also issuing the older fields if possible, or
3. To recommend to the CVE Board that they enroll identifier-focused ADPs.

[zmanion]

The vote has closed, I've read up, the simplest thing I can say is that I don't think we need to make this decision yet. So that'd be a late vote for Option 2 I guess.

I'm very much in favor of supporting more SWID schemes and generally requiring CNAs to (correctly, sufficiently) populate at least one SWID scheme. One concern I have is illustrated by the OmniBOR-can-fulfill example, IIUC, as a consumer, I need to dereference artifactID to get something a human understands?

IOW, I'm not sure how to effectively use an "intrinsic ID only" SWID system, which may be a failure on my part.

[alilleybrinker]

Thanks for the late vote! We did choose Option 2, as the vote did not reach consensus and so we chose the more conservative option. We can of course revisit in the future.

For OmniBOR, you don't really "dereference" it, but rather look for matching Artifact IDs for artifacts in your environments, whether those have been inventoried or you search for them. Constructing Artifact IDs is cheap (it's effectively a SHA-256 of the file), so you just hash and compare to the Artifact ID in a CVE Record.

[darakian]

So that'd be a late vote for Option 2 I guess.

Well follow the process and go add an emoji to the top post then 👀