CWE

Common Weakness Enumeration

A community-developed list of SW & HW weaknesses that can become vulnerabilities

New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > Documents > CVE → CWE Mapping "Root Cause Mapping" Guidance 
ID

CVE CWE "Root Cause Mapping" Guidance

This 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:

  1. Driving the removal of classes of vulnerabilities: Root cause mapping encourages a valuable feedback loop into a vendor’s SDLC or architecture design planning

  2. Saving money: the more weaknesses avoided in your product development, the less vulnerabilities to manage after deployment

  3. Trend analysis (e.g., how big of a problem is memory safety compared to other problems like injection)

  4. Further insight to potential “exploitability” based on root cause (e.g., command injection vulnerabilities tend to see increased adversary attention, be targeted by certain actors)

  5. Organizations demonstrating transparency to customers how they are targeting and tackling problems in their products

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 Language

As 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”.


Weakness Prerequisite Technical Impact

Insecure Direct Object Reference (IDOR) in MyProduct 10.1 to 10.6 allows an unauthenticated attacker to read sensitive data and execute specific commands and functions with full admin rights via the page parameter to the /api/xyz API endpoint.

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.

Glossary

To 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: