Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > Documents > CWE Mapping Guidance  

CVE CWE Mapping Guidance


The CWE Team sincerely thanks the following groups who provided their invaluable feedback in improving this document. The names are alphabetized by names of the organizations and individuals.

Battelle Memorial Institute (Battelle)
CVE Quality Working Group
Eldar Marcussen
National Institute of Standards and Technology (NIST)
NVIDIA Corporation
Red Hat, Inc.


This guidance is intended for vendors and researchers who produce or analyze CVE Records. It is meant to evolve through community feedback as well, so that it can best serve everyone involved in these efforts. If you would like to help improve this document, please reach out to us at

Additional Resources:

Document Version:  1.0 (Released 3/25/2021)


The goal of this document is to share guidance on navigating the CWE™ site to better align newly discovered vulnerabilities (i.e., CVEs) to their respective, underlying weaknesses. This guidance is informed by two years of experience in analyzing and mapping thousands of CVE Records in the NIST National Vulnerability Database (NVD) to CWEs for calculating the annual CWE Top 25 list. By aligning CVEs to the most applicable CWE entries, the community will be in a better position to mitigate or eliminate their associated operational risk most effectively.

Overview – What Is CWE?

CWE is a community-developed list of common software and hardware weaknesses that have security ramifications. “Weaknesses” are flaws, faults, bugs, or other errors in software or hardware implementation, code, design, or architecture that if left unaddressed could result in systems, networks, or hardware being vulnerable to attack. The CWE List and associated classification schemes serve as a common language that can be used to identify, categorize, and describe these weaknesses in terms of CWE identifiers (CWEs).

Targeted at both the development and security practitioner communities, the main goal of CWE is to educate software and hardware architects, designers, programmers, etc. on how to eliminate the most common mistakes as early in the Software Development Life Cycle (SDLC) as possible. Ultimately, use of CWE helps prevent the kinds of security vulnerabilities that have plagued the software and hardware industries and place enterprises at risk. This, in return, helps save money in the long run as well as reduce liability that occurs through these flaws.

As mentioned above, CWE focuses on a type of mistake that, in conditions where exploits will succeed, could contribute to the introduction of vulnerabilities within that product. This term applies to mistakes regardless of whether they occur in implementation, design, or other phases of a product lifecycle.

A vulnerability is an occurrence of one or more weaknesses within a product, in which the weakness can be used by a party to cause the product to modify or access unintended data, interrupt proper execution, or perform actions that were not specifically granted to the party who uses the weakness.

CWE is the root mistake, which can lead to a vulnerability (tracked by CVE in some cases when known), which can be exploited by an attacker (using techniques covered by CAPEC).

Helpful CWE Resources and CWE Entry Structure

It is important to understand few essential elements of CWE before diving into different ways of mapping. Having a clear grasp on these crucial components will help the overall mapping experience.


In order to provide a common weakness language, CWE uses well-defined/well-known terminology derived from vulnerability theory, which is found at the following link:

The CWE team has found through various activities that different terms mean different things based on the situation and the context they are used in, individuals’ skills and experience, or other related things which introduce subjectivity. To reduce subjective bias, CWE strives to follow the standard definitions found in the glossary where applicable. It is recommended that you become familiar with these terms so that they can maximize your 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 in turn, will lead to accurate CWE(s) being selected for CVE mappings. These are hyperlinked for easy access on digital media, but are also available in Additional Resources with their definitions for printable format.

Terms to describe the important characteristics of weaknesses:    ResourceInformation Exposure

Terms to describe behavior qualifiers:    ImproperIncorrectMissing

Terms to describe protection mechanisms:    AuthenticationAuthorizationPermissionsNeutralization


CWE provides weakness information for over 900 different software and hardware quality and security issues. A hierarchical system of five types of abstraction is utilized to provide clarity and understanding of the relationships between weaknesses. Four well-defined hierarchical types are reserved for weaknesses, from most abstract to most specific: Pillar, Class, Base, and Variant.

These abstraction types correlate with the type of information contained within the CWEs as described by different dimensions: behavior, property, technology, language, and resource. It is worth noting that the fifth type, Category, is simply a collection of similar weaknesses that do not all share the same combination of the dimensions, so a Category should not be used for mapping. Only Pillars, Classes, Bases, and Variants are appropriate for mapping, and the lowest-level mapping should be performed when possible.

It has been the CWE team’s goal to provide as specific of a mapping as possible based on the available information in their analyses, so it is recommended that you follow the same guideline. Having precise CWE mappings will provide for better-quality data, which will help coalesce community guidance and standards.

Mapping Methodologies

There are different methods one can use in the CWE site to identify appropriate weakness mappings for CVEs. Once you have carefully analyzed the CWE(s) based on the CVE at hand, determine which CWE(s) provide the best match, and why. You should also get another opinion to ensure that the process can be as objective as possible. It has been the CWE team’s experience that different skills and experience can introduce bias in how one perceives the information. Therefore, the CWE team recommends verifying your intended mapping with another staff member with slightly different skills and experience than you.

We highlight few common mapping options below with examples on using them:

CWE has a search feature available on the home page of the CWE website, illustrated below.

You can search for any keywords, or known IDs, or even a general term. The in-site search form will find all matching pages to that term on the CWE web site, as all web pages are indexed.

✔ To limit your search to only individual CWE entry pages, include "inurl:definitions" in your query

Let’s say you are interested in learning more about Cross-Site Scripting (XSS) or want to find a CWE ID for XSS to map to a CVE that deals with XSS. Here is the process you could follow to get to that information using the search feature.

  1. Search for “xss” returns the following:
  2. Clicking on the first suggestion leads to the page for CWE-79. Usually, specific keywords will be identified in the first few results, if not the first one. Note that the second result highlights CWE-725 which is a Category for OWASP XSS, and should not be used for mapping. In our case, when checking CWE-79, here is part of what we see.
  3. Quickly glancing through this page reveals “(‘Cross-site Scripting’)” in the name as well as breakdown of different types of XSS in the “Extended Description”. This means this is the right CWE for learning more or mapping to XSS.

Ensure that your “Presentation Filter” is set to “Complete” to get full information on this or any weakness you’re checking.

Now let’s say you wanted to learn more about some other XSS-related CWEs. Look under the “Relationships” section on the CWE-79 page to see XSS related CWEs, as highlighted by Parent, Child, PeerOf, CanFollow, and CanPrecede relationship types. Parent and Child represent direct relationships to CWE-79, whereas the other types can be at the same level or lead to other weaknesses. Here is an example of what that looks like:

You can click the links to open the CWEs you’re interested in to learn more.

If you’ve exhausted your search and still aren’t finding a weakness you’re looking for, there is a chance that it may not be available due to a potential gap in CWE coverage. Although CWE tries to be comprehensive, we recognize that we’re likely to miss certain areas from time to time. In that case, please reach out to and we’ll work with you to create an entry on that topic.

View-1003 Method

View-1003 contains “Weaknesses for Simplified Mapping of Published Vulnerabilities”. This view is currently software centric, so if you need to map to hardware weaknesses, then refer to the View-1194 related sections. This view provides a subset of CWEs that cover the most commonly-used CWEs that are mapped by CVEs. As of CWE 4.4, it includes 127 different CWEs, mostly at the Class and Base level abstractions. This view purposely does not include many Variant level weaknesses, as it is the CWE Team’s experience that only a few vendors and researchers prefer or are capable of mapping at such a low level. Additionally, this view is meant to be easily digestible by novice users. Note that this view is updated whenever needed to provide additional coverage without over-populating it.

For View-1003 and other hierarchical views, you can visit the view’s main page and click the “Expand All” option. Here is a screenshot showing a portion of the view:

It is recommended that you become familiar with all the CWEs in this view. The moderate length makes perusing more manageable and exploring the tree to seek out potential CWE(s) based on their name more reasonable. You may choose to ‘expand all’ or simply expand specific parent groupings by clicking on the “-“ or “+” signs. Each weakness entry is clickable to go straight to its page.

To include the summary of each weakness in addition to the name, click the “Show Details” checkbox on the upper right-hand side:

Other Useful Hierarchical Views

There are three other useful collections of weaknesses that can be used for mapping vulnerabilities to weaknesses: View-1000, View-699, and View-1194. These have the same functionality as View-1003, i.e., you can “Expand All” to show the entire hierarchy and/or select “Show Details” to include summaries of each weakness.

Research View (View-1000)

This view captures all weaknesses in CWE. It has a deep tree structure, beginning with 10 high-level Pillars. It might be especially useful when you are looking for unusual weaknesses, as you could perform a top-down search.

Developer View (View-699)

This view captures a subset of weaknesses intended for software developers. By design, this view is only 2 levels deep. The top level has categories of developer-friendly concepts (but don’t map to these categories – they are only to help you navigate to the appropriate entry). The second level contains Base level weaknesses.

Hardware Design View (View-1194)

This view captures a subset of weaknesses intended for hardware designers/architects. Similar to View-699, this view also tries to be only 2 levels deep. The top level has categories of designer/architect-friendly concepts (but don’t map to these categories – they are only to help you navigate to the appropriate entry). The second level contains Base/Class level weaknesses.

Relationship Graph Visualization in PDF Format

For the main views, a graphical display is available in PDF format. This visualization includes only CWE names, but it can be useful in quickly seeing closely-related issues.

These PDFs are available at

Weaknesses for Simplified Mapping of Published Vulnerabilities Example (View-1003)

Research View Example (View-1000)

Developer View Example (View-699)

Hardware Design View Example (View-1194)

Keyword Scraper

The CWE team has developed a CVE description parsing script as part of the Top 25 analysis and is currently updating that tool. The CWE team was able to identify many keywords in NVD’s CVE descriptions, which made the verification of some of the CVEs much easier. Our hope is to share that with everyone in the near future.

This automated script searches through the latest CWE XML bundle looking for specific terms. Vendors and researchers can create their own customized script/tool to fit their needs best. In general, all CWE entries are provided in the latest XML file, and an organization would write a script in their preferred language to parse through specific keywords. You can focus on each Weakness entry’s “Name” attribute, “Description” element, “Alternate Terms” element, and “Previous_Entry_Name” element. These elements will provide the special keyword(s) that are likely to be searched. For example, if the issue involves “memory corruption”, when you feed the entire XML file, your program should return a hit on CWE-787: Out-of-bounds Write, as its “Alternate Terms” include “Memory Corruption”. The “Previous_Entry_Name” elements can be useful if you use terms that were originally included in CWE but changed at a later time. You don’t need to restrict yourself to only these elements; you can expand to search other CWE entry elements too. You are best aware of your organization’s technology stack, and other security relevant information, so using your knowledge, you can create a sub-list of keywords to focus on.

Page Last Updated: March 25, 2021