Include support for root cause CVE tags

[Chris-Turner-NIST]

We previously discussed including support for CVE level tags (which can be applied to the CNA or ADP containers) that assist in identification of root cause.

Tag	Definition
Hardware Root Cause	Tag this to a CVE if the primary root cause of the security vulnerability is originated from the hardware component of the affected product(s).  The intent is to facilitate Hardware Designers to learn how to prevent similar weakness.   Even when a hardware vulnerability can be addressed by a SW workaround, the “Hardware Root Cause” tag should still be applied, since the focus is on how the issue is introduced, not how it is remediated.
Software Root Cause	Tag this to a CVE if the primary root cause of the security vulnerability is originated from the software component of the affected product(s).  The intent is to facilitate Software Developers to learn how to prevent similar weakness.

This could be expanded to include other concepts such as protocol or specification root causes. Ex:

Tag

Definition

Specification Root Cause

Tag this to a CVE if the primary root cause of the security vulnerability is originated from the industry specification that the affected product(s) comply with.  The intent is to facilitate Industry Specification Groups to learn how to prevent similar weakness.   If the root cause of the CVE is related to inappropriate adoption of an industry standard (e.g., use of an obsolete cryptographic algorithm) or incorrect implementation of an industry standard (e.g., product does not implement the error recovery flow as captured in the protocol specification) in the affected product(s), the appropriate “Hardware Root Cause” or “Software Root Cause” should be applied instead.

[asummers-MITRE]

Is this tag under consideration for inclusion?

[chandanbn]

"root-cause-hardware" : Capture: physical, circuits, unchangeable - unrelated from remedy.

[ccoffin]

Discussed this in the September 12, 2024 QWG Meeting. Maybe this would be covered by CPE using the part field. Possibly a new property within the affected block. Could possibly be derived from the CWE. Maybe a flag under problemType to define hardware or software root cause. What is the delivered value of adding these tags and who uses them. From remediation perspective, this tag may not be useful.

[Chris-Turner-NIST]

Based on my understanding of what the CWE folks were looking for back when this was originally requested, CPE is not a viable solution for identifying this data.
The original intent was to be able to identify (amongst organizations that utilize them) which records appear to be rooted in hardware/software.
If there are concerns around this, we can reach back to the CWE folks for revived perspective of the value add.

[darakian]

Do we know who would be publishing this data? This strikes me as something that could be nice to have but would be quite hard to produce in a reliable manner. Additionally who would we expect to consume this data and how would it aid in their remediation?

[jmfung]

This is Jason Fung from Intel. We partnered with Chris Turner to submit the proposal close to 4 years ago.

We are currently part of the Most Important HW Weakness (MIHW) workgroup sponsored by MITRE CWE Program. I would like to share one of the usage models behind this proposal. We are trying to create the next Top X HW CWE ranking for 2025 by pursuing with a data-driven analysis based on CVE data.

Without this tag, it is very difficult to determine if a CVE is HW or SW related. Some HW CVEs use CWEs that are SW-only or CWEs that are shared between SW and HW. This field is intended to be filled by the CVE submitters. When we query the NVD, we can use the tag to subset the HW CVEs (as determined by the submitters) for further analysis.

Here is another use case. When a CVE submitter picks the most appropriate CWE, this can be the guidance we provide:

If (CVE.tag = SW): select root causes from NVD-Friendly CWE List
else if (CVE.tag = HW): select root causes from CWE HW Design View

[ElectricNroff]

I feel that tags about whether a vulnerability had a certain type of hardware angle is similar to tags about whether a vulnerability had a certain type of AI angle. The latter was recently discussed in the CVEAI Working Group, where one comment was:

I am strongly opposed to the AI tag because it doesn't fit the pattern of the other tags, and because it could lead to an unbounded flat namespace.

The other tags - about disputed, and unsupported, and hosted - were chosen to allow CVE consumers to exclude broad swaths of CVE Records from consideration. Typically the excluded records were ones that were outside of the traditional CVE core mission space of normal vulnerabilities in normal products that are deployed in the normal way. In other words, if there was a tag, a downstream consumer could immediately exclude that vulnerability from triage efforts. Also, when we designed the cve.org website, a tag was placed front and center - at the very top of the page - to emphasize that it could be used in a very early stage of the triage process.

An AI tag is not like that at all. Presence of AI technology would not commonly control a decision about whether the vulnerability was even relevant. Instead, an AI tag is analogous to a large number of other attributes through which CVE Records could be categorized, e.g., all records about document publishing, or about identity management, or about space travel. And there could also be other attribute subsets related to what type of entity produced the CVE Record, or under what circumstances it was produced, or whether the entity considered it especially important. If we had tags for these, it could result in a huge flat namespace, in which data producers would find it difficult to select all of the applicable tags.

Because of this, information about AI (or about space travel, for example) would be better organized into a new section of the CVE Record, perhaps called technology areas. A data producer could provide the same information about AI, but the user experience would be better for both producers and consumers. The set of technology areas would not necessarily be rendered at the top of a CVE Record, and CVE consumers could choose not to render at all.