CVE → CWE "Root Cause Mapping" GuidanceThis guidance is intended to help CVE Numbering Authorities (CNAs) and those who produce or analyze CVE Records to better identify and disclose the root causes of vulnerabilities . It is also likely to be helpful to those who are analyzing vulnerabilities that are not tracked by the CVE Program. What is Root Cause Mapping? Root cause mapping is the identification of the underlying cause(s) of a vulnerability. This is best done by correlating CVE Records and/or bug or vulnerability tickets with CWE entries. Today, this is not done accurately at scale by the vulnerability management ecosystem. Accurate root cause mapping is valuable because it directly illuminates where investments, policy, and practices can address the root causes responsible for vulnerabilities so that they can be eliminated. This applies to both industry and government decision makers. Additionally, it enables:
Overview – What Is CWE? Common Weakness Enumeration (CWE™) is a community-developed list of common software and hardware weaknesses. A “weakness” is a condition in a software, firmware, hardware, or service component that, under certain circumstances, could contribute to the introduction of vulnerabilities. Referred to as CWEs, weaknesses are named, defined, and given a unique identifier on the CWE website. Weaknesses can occur in the design, implementation, or other phases of a product lifecycle. Many vulnerabilities have the same CWE as their root cause, independent of vendor, coding language, etc. Weakness vs. Vulnerability LanguageAs defined by the CVE Program, a vulnerability is an instance of one or more weaknesses in a Product that can be exploited, causing a negative impact to confidentiality, integrity, or availability; a set of conditions or behaviors that allows the violation of an explicit or implicit security policy. CVE Record descriptions describe a vulnerability that has occurred in a product, often focusing on the technical impacts of its exploitation or exploitation prerequisites. Examples of technical impact phrases include “bypass authorization”, “gain privileges”, or “execute malicious code”. They describe the result of the vulnerability and its attack vectors, not the root cause(s). Examples of exploitation prerequisite phrases include “unauthorized user”, “unauthenticated remote attacker”, or “admin user”. While these phrases could be interpreted as being related to access control CWEs, they are not describing a weakness. In contrast, accurately mapping a CVE Record to a CWE requires information describing an issue that led to the vulnerability. Examples of weakness language include “missing authentication”, “improper bounds check”, or “stack-based buffer overflow”.
CWE Resources & CWE Entry Structure It is helpful to be familiar with how CWE defines weaknesses before diving into different ways of mapping. Having a clear grasp on these crucial components will help the overall mapping experience. GlossaryTo provide a common language, CWE has a glossary of terminology derived from vulnerability theory. Terms can often mean different things based on the situation and the context in which they are used, as well as individuals’ skills and experience in vulnerability management, or other related things that introduce subjectivity. Becoming familiar with these terms can help streamline utility of the CWE corpus. Common and Widely Used Terms in CWE
The following highlights some of the most common terms in CWE, which are chosen based on their prevalence within CWE, vulnerability theory, and industry. They are presented here to alleviate confusion surrounding their meanings. This will lead to the selection of accurate, precise CWE(s) for root cause mapping. Important characteristics of weaknesses: Behavior, Property, Technology, Resource Behavior qualifiers: Improper, Incorrect, Missing Protection mechanisms: | ||||||