From Roadmap to Results: Measuring CWE Adoption to Enable Prevention

From Roadmap to Results: Measuring CWE Adoption to Enable Prevention

Speakers: Alec Summers (CVE and CWE Project Lead, The MITRE Corporation); Steve Christey Coley (The MITRE Corporation)

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=mVO-j8CNYFo

Overview

This talk, presented by Alec Summers and Steve Christey Coley of The MITRE Corporation at VulnCon, provides a comprehensive update on the advancements and strategic direction of the Common Weakness Enumeration (CWE) program. Titled "From Roadmap to Results: Measuring CWE Adoption to Enable Prevention," the presentation reflects on several years of collaborative work with the community, focusing on driving adoption, enhancing usability, and expanding the scope and coverage of CWE. Summers, MITRE's CVE and CWE Project Lead, and Coley, a co-founder of both CVE and CWE, emphasize the program's crucial role in shifting the cybersecurity paradigm from reactive vulnerability management to proactive weakness prevention.

The core message of the talk underscores CWE's increasing importance in the evolving landscape of software security. By identifying, defining, and cataloging fundamental software and hardware design flaws—the root causes of vulnerabilities—CWE aims to enable developers and organizations to "shift left" in their secure development lifecycle. This proactive approach, the speakers argue, is not only more effective in preventing the proliferation of exploitable vulnerabilities but also significantly more cost-efficient than addressing issues downstream in deployment or maintenance phases.

The presentation delves into tangible metrics and observations demonstrating the success of recent initiatives, particularly in increasing the precision and actionability of CWE mappings within vulnerability disclosures. It also highlights ongoing challenges, such as refining terminology, enhancing content completeness, and fostering a "weakness mindset" across the industry. Ultimately, the talk serves as a call to action for the community to engage more deeply with CWE, leveraging its potential as a vehicle for achieving "secure by design" principles and fundamentally improving the security posture of the global software ecosystem.

Background

▶ Watch: CWE's increasing importance and vulnerability prevention goal (0:45)

The Common Weakness Enumeration (CWE) is a community-developed, community-maintained list of software and hardware weakness types. Its foundational mission is to identify, define, and catalog these weaknesses, which are the underlying conditions or mistakes that, under certain circumstances, can lead to exploitable vulnerabilities. As Steve Christey Coley, co-founder of CWE, explains, while a CVE (Common Vulnerabilities and Exposures) identifies a specific, demonstrably exploitable instance of a vulnerability in a particular product, CWE focuses on the root cause – the design flaw or programming error that enables such vulnerabilities. This distinction is crucial: many specific CVEs might map back to one or two underlying CWEs, representing a fundamental type of flaw.

Historically, the CWE program faced several challenges in achieving widespread adoption and impact. Early feedback from the community highlighted issues related to its responsiveness to new technologies, its coverage of emerging weakness types, and its overall usability. Users often encountered a "wall of text" when navigating CWE entries, making it difficult to quickly grasp and apply the information. To address these, Alec Summers outlined a strategic roadmap focused on three key areas: driving adoption, increasing awareness, and expanding coverage. This plan drew inspiration from the success of its sister program, CVE, in leveraging community expertise for growth.

The strategic initiatives included federating the program by engaging diverse community members from government, academia, and industry to improve content and add new weakness types. Usability was to be enhanced not just through better navigation but also by simplifying descriptions and making the information more digestible. Finally, the program aimed to engage the community around broader cybersecurity narratives like "secure by design" and "shifting left," positioning CWE as a critical tool for preventing vulnerabilities early in the software development lifecycle (SDLC). The core idea was that by analyzing the root causes of vulnerabilities, organizations could feed that knowledge back into their development processes, leading to more secure products from inception.

Key Findings

▶ Watch: Significant increase in CNA adoption of CWE mapping (12:00)

The talk presents compelling evidence of CWE's growing impact and successful adoption, particularly within the vulnerability disclosure ecosystem. A significant finding is the dramatic increase in CWE adoption by CVE Numbering Authorities (CNAs). In a snapshot from a couple of years prior, there were 371 total CNAs, with 273 actively disclosing records in the preceding six months. Of these active CNAs, 74% (202 CNAs) included CWE mappings for 100% of their disclosed records. Fast forward to the present, the CNA program has seen tremendous growth, with 619 total CNAs and 544 actively disclosing records. Crucially, the percentage of active CNAs providing 100% CWE mappings has risen to 88% (480 CNAs), indicating a substantial improvement in the integration of root cause mapping into disclosure practices. This growth not only informs CNA internal training and SDLC but also provides valuable aggregated data for ecosystem-wide analysis.

Beyond mere adoption, the quality and actionability of CWE mappings have also seen marked improvement. Analyzing the top 25 most frequently mapped CWEs over the last two years, the speakers noted a significant shift towards more precise and actionable mappings. CWE entries are labeled with "allowed," "allowed with review," "discouraged," or "prohibited" to guide users on appropriate mapping levels. The data shows a reduction in mappings to "discouraged" CWEs within the top 25, with the "slice of the pie" for discouraged mappings being cut in half (from six discouraged CWEs in a previous analysis to three currently). This trend reflects a community-wide move towards greater specificity.

Further underscoring this trend, the analysis of CWE hierarchy demonstrates a positive shift towards mapping at more precise levels of abstraction. CWEs are organized into a hierarchy of pillars, classes, bases, and variants, moving from highest to lowest abstraction. The program encourages mapping to the "base" or "variant" levels for maximum actionability. The data reveals positive trends: an increase in mappings to base-level weaknesses and a decrease in mappings to more abstract "classes." There's also an increase in mapping to the most precise "variant" level. While one "pillar" (CWE-284, Access Control) still appeared in the top 25, indicating an area for continued education, the overall direction is highly encouraging.

Content development efforts have focused on improving entry completeness and depth. While most CWE entries have basic information, the team is now tracking specific sub-elements like affected programming languages, operating systems, and technologies. For instance, while most CWEs have "applicable platforms" data, only about 200 explicitly mention a specific affected language, indicating a gap in depth. Similarly, only 52% of CWEs include "detection method" information, and 75 diagrams have been added (with 800+ more needed). These metrics guide prioritization for content improvement in collaboration with special interest groups like the Hardware SIG.

Community engagement through the Content Development Repository (CDR) has yielded 191 submissions over the last two to three years, with 102 still active. While a valuable channel for community input, the CDR process highlights challenges in submission quality, such as proposals lacking a clear definition of the weakness, focusing on attacks rather than root causes, overlapping with existing CWEs, or being at too low a level of abstraction for a new entry.

Finally, a review of historical and current mapping data, including NVD (National Vulnerability Database) and CNA-provided mappings, reveals significant improvements. A comparison of NVD data from 2016-2017 (influenced by the "NIST 19" list, which included some categories and high-level CWEs) shows a high proportion of "red" (prohibited) and "orange" (discouraged) mappings. Current data (2025) across over 500 unique CWEs (compared to 98 unique CWEs previously) demonstrates a much smaller percentage of discouraged mappings, although common "suspects" like CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer), CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor), and CWE-284 persist. Direct engagement with CNAs, including providing reports on potential mapping errors and machine learning-assisted suggestions, has been successful in correcting mappings and improving future accuracy, further demonstrating the positive outcomes of the program's strategic roadmap.

Technical Deep Dive

▶ Watch: Shifting from vulnerability mindset to weakness mindset (27:00)

CWE functions as a knowledge corpus, providing a structured language to discuss and categorize software and hardware weaknesses. A core technical aspect of CWE is its hierarchical structure, which organizes weaknesses from broad categories down to highly specific instances. This hierarchy consists of pillars (highest abstraction), classes, bases, and variants (lowest abstraction). For effective prevention and remediation, the program strongly advocates for mapping vulnerabilities to the most precise levels—the base or variant—as these offer the highest actionability. A mapping to a "pillar" like CWE-284 (Improper Enforcement of Access Restrictions) is less useful for a developer than mapping to a specific child weakness like CWE-863 (Incorrect Authorization).

Significant technical improvements have been made to the presentation and accessibility of CWE information. The website's user experience has been revamped, moving away from the "wall of text" format. This includes simplifying descriptions to focus on the core weakness and leveraging the rest of the CWE schema (e.g., alternate terms, mitigations, consequences, relationships) for detailed information. Visual aids, such as diagrams, have been incorporated to enhance understanding, and the readability of tables has been improved. Furthermore, the introduction of a REST API allows for programmatic access to CWE data, facilitating integration into automated tools and processes, which the speakers acknowledge could be better promoted.

A critical technical element influencing mapping quality is the set of mapping usage labels associated with each CWE entry:

• Allowed: Recommended for direct mapping.
• Allowed with Review: Can be mapped to, but requires careful consideration to ensure it's the most specific and appropriate choice.
• Discouraged: Generally too high-level or problematic for direct mapping; more specific child CWEs are usually preferred. Examples include CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer) and CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor).
• Prohibited: Should never be mapped to, as these are typically arbitrary categories, IDs for reviews, or deprecated entries.

The talk highlights persistent challenges in terminology and language. The common name for CWE-89, SQL Injection, is attack-oriented. The precise CWE name, "Improper Neutralization of Special Elements used in an SQL Command," while more accurate for weakness identification, is often perceived as awkward. This disconnect between common vulnerability names and precise weakness definitions complicates adoption. Similarly, terms like "buffer overflow" suffer from vagueness, with only about 70% of polled individuals agreeing on its exact meaning (writing past the end of a buffer). The word "improper," frequently used in CWE names, is defined as a generalization of "missing" or "incorrect" within the CWE glossary, but can be misinterpreted in common language or by legal teams. These issues underscore the need for clearer, more consistent terminology across the industry.

The fundamental shift CWE advocates for is moving from a vulnerability mindset (focused on attack, impact, and exploitation) to a weakness mindset (focused on the underlying condition or mistake). This is a difficult educational challenge. Vulnerability-centric thinking often prioritizes impacts like "code execution" or "information leak," which can be the result of dozens of different CWEs, obscuring the root cause. The Content Development Repository (CDR) process technically illustrates this challenge: many submissions are rejected or require significant clarification because they describe an attack rather than a weakness, or they propose a weakness that overlaps existing entries or is too specific to warrant a new top-level CWE.

Specific CWEs are frequently mismapped or misused, indicating conceptual confusion. CWE-284 (Improper Enforcement of Access Restrictions), a pillar, is a prime example. The speakers note that even standards organizations like NIST have multiple definitions for "authorization," highlighting the inherent difficulty in precisely defining these concepts. The mapping usage labels and targeted educational efforts, including workshops and direct CNA feedback, are technical mechanisms designed to address these persistent mapping errors and promote a more accurate and actionable use of CWE.

Demo / Proof of Concept

▶ Watch: Improving mapping quality with usage labels and NVD history (38:00)

While the talk did not feature a live technical demonstration or proof of concept in the traditional sense, it effectively presented data-driven evidence and visual representations of the CWE program's advancements. The speakers showcased statistics on CNA adoption, improvements in mapping quality (e.g., the reduction of "discouraged" mappings in the top 25), and the increased precision of mappings within the CWE hierarchy. They also displayed examples of the new visual aids and simplified descriptions now integrated into CWE entries on the website, serving as a "before and after" illustration of usability enhancements. The discussion around the Content Development Repository (CDR) and the REST API also served as a conceptual "proof" of the community's engagement and the technical infrastructure supporting the program's evolution.

Defensive Implications

▶ Watch: Vision for 2030: Measurable impact on software security (52:00)

The insights shared in this talk carry significant implications for defenders and organizations committed to improving their cybersecurity posture.

1. Embrace Weakness-Centric Thinking: Defenders should actively work to shift their mental models from a reactive "vulnerability mindset" (focusing on attacks and their impacts) to a proactive "weakness mindset." Understanding the underlying design flaws and programming errors (CWEs) is key to preventing broad categories of vulnerabilities rather than just patching individual instances. This fundamental shift enables more effective long-term security strategies.

1. Integrate CWE Mapping into SDLC: Organizations, particularly CNAs, should integrate precise CWE root cause mapping into their software development lifecycle (SDLC) and vulnerability disclosure processes. The data presented underscores the value of this practice: it informs internal training, strengthens development practices, and provides valuable aggregate data for strategic decision-making. Mapping to specific "base" or "variant" level CWEs, guided by the mapping usage labels, ensures the data is actionable.

1. Leverage CWE for "Secure by Design" and "Shift Left": CWE is a vital tool for implementing "secure by design" principles. By identifying common weaknesses early in the design and development phases, organizations can avoid introducing these flaws, thereby "shifting left" their security efforts. This approach is demonstrably more cost-effective than remediating vulnerabilities discovered late in the product lifecycle.

1. Utilize Enhanced CWE Resources: Defenders should take advantage of the program's usability improvements. This includes navigating the redesigned CWE website with its visual aids, simplified descriptions, and filtering capabilities. For automated tools and large-scale data analysis, the CWE REST API offers programmatic access to weakness information, enabling better integration into security tools and workflows.

1. Focus on Specific Mitigations: As highlighted by the UK NCSC's work, identifying mitigations that address multiple CWEs can significantly improve defensive efficiency. Rather than tackling each weakness individually, organizations can prioritize implementing overarching security practices that neutralize several common root causes. This strategic approach to mitigation can yield a higher return on investment for security efforts.

1. Participate in Community Engagement: The success of CWE relies heavily on community contributions. Defenders are encouraged to engage with initiatives like the Content Development Repository (CDR) for proposing new weaknesses or improvements, and to participate in Special Interest Groups (SIGs) like the upcoming cross-domain SIG. This collaboration directly influences the comprehensiveness, accuracy, and utility of the CWE corpus, benefiting the entire ecosystem.

1. Address Terminology Gaps: Recognize the challenges posed by vague or conflicting terminology (e.g., "buffer overflow," "improper," "access control"). Organizations should strive for clarity and precision in their internal security communications, aligning with CWE's defined terms where possible, to reduce misunderstandings and improve the effectiveness of security guidance.

Key Takeaways

• CWE Adoption is Growing and Improving: There's been a significant increase in the adoption of CWE root cause mapping by CNAs, with a notable shift towards more precise and actionable mappings at the "base" and "variant" levels, reducing the use of high-level or "discouraged" CWEs.
• Weakness Mindset for Prevention: Shifting from a reactive "vulnerability mindset" (focused on attacks) to a proactive "weakness mindset" (focused on root causes) is crucial for enabling "secure by design" principles and preventing the recurrence of common flaws early in the development lifecycle.
• Usability and Accessibility Enhancements: The CWE program has made substantial improvements to its website, including visual aids, simplified descriptions, filtering options, and a REST API, making CWE information more accessible and easier to integrate into security tools and processes.
• Community Collaboration Drives Evolution: Active engagement through working groups (e.g., Hardware SIG, User Experience WG, Root Cause Mapping WG) and the Content Development Repository (CDR) is fundamental to expanding CWE's coverage, improving its quality, and addressing new technological challenges.
• Precision in Mapping is Key: Utilizing CWE's hierarchical structure and mapping usage labels ("Allowed," "Discouraged," "Prohibited") is essential for ensuring that vulnerability disclosures provide specific, actionable information that can effectively inform defensive strategies and developer education.
• Challenges in Terminology and Education: Overcoming the inherent vagueness of some industry terms and bridging the gap between vulnerability-centric and weakness-centric thinking remain ongoing educational challenges that require continued effort and community support.

About the Speaker(s)

Alec Summers is The MITRE Corporation's CVE and CWE Project Lead. He plays a pivotal role in guiding the strategic direction and operational execution of both the Common Vulnerabilities and Exposures (CVE) and Common Weakness Enumeration (CWE) programs. His work focuses on fostering community collaboration and driving the adoption and modernization of these critical cybersecurity initiatives.

Steve Christey Coley is a distinguished figure at The MITRE Corporation and a co-founder of both the CVE program (established in 1999) and the CWE program (circa 2005). Known for his deep expertise and passion for vulnerability management, he humorously refers to himself as a "vulnerability fanboy," reflecting his extensive contributions to the field and his dedication to improving how the industry identifies, defines, and addresses security flaws.