Vulnerability Jargon
CVE
CVEs (or Common Vulnerabilities and Exposures) are a communication tool.
Their primary purpose is to provide a single canonical name to refer to a specific vulnerability. Refer to vulnerabilities by their CVE Indentifier or CVE ID (i.e., the CVE number). Use CVE IDs in security patch commit messages (without breaking embargo). Use CVE IDs in bug reports. CVEs should only refer to a single vulnerability. Sometimes they are misused to describe non-security bugs, or are duplicate assignments, or describe multiple assignments, or do not even describe a bug, and so on. Vendor IDs, like GHSAs and RUSTSEC, are fine and add specific context, but should always be supplemental to the CVE ID. Unify communication by using CVE ID as the common name for a specific vulnerability.
CVEs are also used for purposes other than the common name of a vulnerability. They include a description which might be informative. They might include a severity score which might be accurate. They are sometimes used as proof-of-work by security researchers. Often useful references are included, like related bug reports, analysis blog posts, and vendor announcements.
The source of truth for CVE information is CVE List V5. CVE Numbering Authorities publish CVEs to the CVE Program’s CVE List though the CVE Service 😛. NIST’s NVD is a downstream consumer of CVE List data and adds their own data, such as their severity score assessments. NVD severity scores drive FedRAMP regulations to patch vulnerabilities in software. NVD data can be downloaded with an API client or from a mirror.
The most important take-away is to use CVEs as thee common name to refer to a specific vulnerability.
CNA
A CNA (or CVE Naming Authority) is allowed to assign CVEs.
What has become the CVE Program and CVE List began in 1999 and was organized by the MITRE Corporation. The CVE Program is funded by the US Federal Government, the MITRE Corporation is largely funded by US Government agencies, and NIST runs NVD. Often these organizations are confused with one another. Initially the CVE Board reviewed and voted on every CVE assignment. In 2005 the MITRE Corporation was given the right to assign CVEs directly. In 2017 other entities were given the right to assign CVEs as a CVE Naming Authority under certain scopes. For instance, Canonical Ltd. is allowed to assign a CVE to any software distributed in Ubuntu. CNA scopes may overlap. Disputes between CNAs are handled by a hierarchical structure. Underneath the CVE Board are Top-Level TL-CNAs (there are two: MITRE and DHS’ CISA) who oversee Root CNAs (four Root-CNAs are governed under MITRE: Google, INCIBE, JPCERT/CC, and Red Hat) who oversee regular CNAs. If Canonical’s were to assign a CVE to curl, then curl’s CNA would have option and right to transfer the CVE to their CNA or to dispute and possibly reject a CVE if the assignment was invalid. Rules governing CNAs can be found on the CVE Program’s website.
Since CNAs began assigning CVEs the total number of assignments has grown each year. Under the CVE Board between 2000 and 2004 ~1500 CVEs were assigned per year. Between 2005 and 2016 ~6000 CVEs were assigned per year between the CVE Board and MITRE. Assignments jumped from 6,517 CVEs in 2016 to 18,113 CVE assignments in 2017 after the CNA program began (see cve.icu). Jerry Gamblin predicts that 32,600 CVE will be published in 2024.
Note that anyone can request or dispute a CVE assignment.
CRD
CRD (or Coordinated Release Date) specifies the datetime which a vulnerability can be publicly disclosed; ending the private embargo.
Security patches*, announcements, analysis blog posts, etc should be disclosed on the specified coordinated release date. When a CVE is under embargo discussion is meant to be private until the CRD. If vulnerability details are leaked before the CRD the embargo is irrevocably broken since the information is public. CRD no longer applies if the embargo is broken. (*To aid rollout some coordinators, such as CERT/CC, believe that security patches can be made public without breaking embargo.) Embargo is also broken if there are credible reports of a vulnerability being used in the wild.
To keep software safe, a maximum embargo period of 90 days is often imposed by reporters. Hardware embargoes often receive much more leniency. Of course, the ideal scenario is that a patch can be developed immediately.
A CRD is usually agreed to by multiple parties, such as by the developers of the affected software and the vulnerability reporter. A CRD may be extended or shortened depending on the situation. Maximizing user safety is often the key factor when changing a CRD. The reporter has the right not to accept extensions. If a software developer needs more time to develop a patch and has kept the reporter in the loop, reporters often agree to maximize user safety. Developers generally have the right to shorten CRD. It is often agreeable to shorten a CRD and protect users sooner if a fix is available early. Downstreams and reporters should also be made aware of shortened CRDs, since they may have patches or analysis blog posts to release. Even when external parties are not involved, it can be helpful to set a CRD to drive a completion date.
On the other hand, only setting a maximum embargo period can lead to quicker security patch deployment when tight coordination is not critical and a responive upstream is involved.
CVD
CVD (or Coordinated Vulnerability Disclosure) is a model for responsibly disclosing vulnerabilities.
The CVD model is contrasted with the extremes Full Disclosure and Non Disclosure. In Full Disclosure information is published early and publicly. This likely means that security patches are not available and that attackers have time to exploit the vulnerability in the wild. Private Disclosure or Non Disclosure is a model where security issues are silently patched or ignored. When a security issue is silently patched and a CVE is not assigned, downstream groups who monitor CVE assignments (e.g., Linux distros) are not made aware that security patches are needed. This leaves end users vulnerable to attack (e.g., even after RCEs the kitty terminal treats vulnerabilities as bugs). CVD is the sane middle ground to protect users. However, an ethical security researcher may choose Full Disclosure as a last resort to protect users if the affected software developers refuse to cooperate in coordinating a security fix in a timely manner. Another exception is to use Full Disclosure when an attack is being used in the wild (e.g., xz-utils).
There are many guides on how to perform CVD, such as those by the Forum of Incident Response and Security Teams, the CERT Coordination Center, and the OpenSSF. Preparing for Zero-Day: Vulnerability Disclosure in Open Source Software is an excellent primer.
See more notes on Coordinated Vulnerability Disclosure.
CVSS
CVSS (or Common Vulnerability Scoring System) is a metric to approximate the severity of a vulnerability.
CVSS, or more generally severity scores, are controversial. It is necessary and useful to broadly assess the importance of a vulnerability. At the same time the CVSS rubric does not apply well across every software vulnerability. FedRAMP regulations use NVD’s CVSS to qualify which vulnerabilities must be patched for compliance. This can be an arbitrary judgement, since some MEDIUM severity issues pose a high real world threat and some CRITICAL severity issues have a negligible real world impact.
Over the years CVSS metrics have improved with newer versions. In addition to Base Score Metrics, the extended Temporal Score Metrics can factor in patch availability, exploit code maturity, and more. Temporal metrics inherently change over time and require maintenance which is likely why they are underutilized. CISA’s Known Exploited Vulnerabilities or KEV catalogs CVEs with high levels of exploit use in the wild.
Art Manion’s Desperately Seeking Severity presentation discusses the philosophy, advantages, and disadvantages of severity scoring.
CWE
CWE (or Common Weakness Enumeration) categories types and lineages of security weaknesses.
It is useful to classify a vulnerability with CWEs to better understand and communicate the nature of a vulnerability. See CWE-767: Out-of-bounds Write as an example. CWEs can be subtypes of other other parent CWEs or have their own children types. Multiple CWEs can apply to a specific vulnerability. The CWE List is maintained by MITRE.