Common Weakness Enumeration

About CWE

Process Approach

A main theme of the CWE initiative is leveraging existing work from within the community, especially in light of the large number of diverse real-world vulnerabilities on the CVE List. Therefore, we continue to leverage as many sources and examples as we can from the CWE community and other interested parties, to develop the specific and succinct definitions of the CWE List elements and classification tree structures. In addition, we continue to work to create the appropriate mappings between CWE Identifiers and specific exemplar CVE Identifiers so that each CWE has a list of the specific CVE IDs that belong to that particular CWE’s type of software security weaknesses. In constructing the CWE List and classification trees we endeavor for maximum comprehensive coverage across appropriate conceptual, business, and technical domains.

In defining organizational structures for the CWE elements, we are striving for simplicity and appropriateness of the description for leveraging by various audiences and for various purposes through the use of taxonometric layering. We are currently using what could roughly be described as a three-tiered approach, in which (1) the lowest level consists of the full CWE List (hundreds of nodes) that is primarily applicable to tool vendors and detailed research efforts; (2) a middle tier consists of descriptive affinity groupings of individual CWEs (25-60 nodes) useful to software security and software development practitioners; and (3) a more easily understood top level consisting of high-level groupings of the middle-tier nodes (5-15 nodes) to define strategic classes of vulnerabilities and which is useful for high-level discourse among software practitioners, business people, tool vendors, researchers, etc. There are currently two of these high-level groupings, the Development View and the Research View.

Since the initial release of CWE Version 0.1 in 2005, we have collaborated with our colleagues in industry, government, and academia to further refine the content of CWE and the required attributes of CWE List elements into a more formal schema defining the metadata structure necessary to support the various uses of the list and associated taxonomy. This schema will also be driven by a desire to align with and support other SAMATE efforts such as software metrics, software security tool metrics, the software security tool survey, the methodology for validating software security tool claims, software assurance claims, arguments, and evidence methodologies, and reference datasets. With a schema defined, an initial comprehensive list of CWEs identified and defined and an organizational structure in place, this set of content is being submitted to a much broader audience of industry participants to discuss, review, and revise. This cycle has continued to iterate as a general consensus was reached on what became the first official release of the CWE version 1.0 and then further to CWE 2.0, which by its wide adoption has become a defacto standard. To be involved in this effort, email us at cwe@mitre.org.

Impact

Following is a list of the direct impacts of CWE:

• Provides a common language of discourse for discussing, finding, and dealing with the causes of software security weaknesses as they are manifested in code, design, or architecture.
• Allows software security tool vendors and service providers to make clear and consistent claims of the security weaknesses that they cover to their potential user communities in terms of the CWEs that they look for in a particular code language. Additionally, the new "CWE Compatibility" was developed to allow security tool and service providers to publicly declare and describe their capability's coverage of CWEs.
• Allows purchasers to compare, evaluate, and select software security tools and services that are most appropriate to their needs including having some level of assurance of the level of CWEs that a given tool would find. Software purchasers are able to compare coverage of tool and service offerings against the list of CWEs and the programming languages that are used in the software they are acquiring.
• CWEs provide code examples of each CWE for explanatory purposes.
• Enables the verification of coverage claims made by software security tool vendors and service providers (this is supported through CWE metadata and alignment with the SAMATE reference dataset).
• Enables government and industry to leverage this standardization in the contractual terms and conditions.

Transition Opportunities

Following is a list of the alignment opportunities with existing efforts that are provided by the CWE Initiative.

• Mapping of CWEs to CVEs. This mapping will help bridge the gap between the potential sources of vulnerabilities and examples of their observed instances providing concrete information for better understanding the CWEs and providing some validation of the CWEs themselves.
• Mapping in-between CWEs and Common Attack Pattern Enumeration Classifications (CAPECs). This mapping will help bridge the gap between the potential sources of vulnerabilities and examples of the observed attacks against instances providing concrete information for better understanding the CWEs and how they can be tested as well as how the attacker manipulates the environment to find and exploit CWEs, opening the door to mitigations at the design, deployment and architecture levels.
• Bi-directional alignment between the Common Weaknesses Enumeration and the SAMATE metrics effort.
• Any tool/service capability measurement framework that uses the tests provided by the SAMATE Reference Dataset would be able to leverage this common weakness dictionary as the core layer of the framework. This framework effort is not an explicitly called out item in the SAMATE charter but is implied as necessary to meet the project's other objectives.
• The SAMATE software security tool and services survey effort would be able to leverage this common weaknesses dictionary as part of the capability framework to effectively and unambiguously describe various tools and services in a consistent apples-to-apples fashion.
• There should be bi-directional alignment between this source of common weaknesses and the SAMATE reference dataset effort such that CWEs could reference supporting reference dataset entries as code examples of that particular CWE for explanatory purposes and reference dataset entries could reference the associated CWEs that they are intended to demonstrate for validation purposes. Further, by working with industry, an appropriate method could be developed for collecting, abstracting, and sharing code samples from the code of the products that the CVE names are assigned to with the goal of gathering these code samples from industry researchers and academia so that they could be shared as part of the reference dataset and aligned with the vulnerability taxonomy. These samples would then be available as tailoring and enhancement aides to the developers of software assessment security tools. We could actively engage closed source and open source development organizations that work with the CVE initiative to assign CVE names to vulnerabilities to identify an approach that would protect the source of the samples while still allowing us to share them with others. By using the CVE-based relationships with these organizations, we should be able to create a high-quality collection of samples while also improving the accuracy of the software product security assessment tools that are available to the software development groups to use in vetting their own product's code.
• Any validation framework for tool/service vendor claims, whether used by the purchasers themselves or through a 3rd party validation service, would rely heavily on this common weakness dictionary as its basis of analysis. To support this, we would work with researchers to define the mechanisms used to exploit the various CWEs for the purposes of helping to clarify the CWE groupings and as a possible verification method for validating the effectiveness of the tools that identify the presence of CWEs in code by exploring the use of several testing approaches on the executable version of the reviewed code. The effectiveness of these test approaches could be explored with the goal of identifying a method or methods that are effective and economical to apply to the validation process.
• Bidirectional mapping between CWEs and Coding Rules, such as those deployed as part of the DHS NCSD Build Security In (BSI) Web site and those published by the Carnegie Mellon University's Computer Emergency Response Team (CERT), used by tools and in manual code inspections to avoid introducing weaknesses into software.
• Leveraging of the OMG technologies to articulate formal, machine-parsable definitions of the CWEs to support analysis of applications within the OMG standards-based tools and models.

Follow-On Opportunities

Following is a list of new, unpursued follow-on opportunities for creating added value to the software security industry.

• Expansion of the Coding Rules Catalog on the DHS BSI website to include full mapping against the CWEs for all relevant technical domains.
• Realignment of CWE items through analysis of the Semantic Template work at University of Nebraska Omaha and the Software Fault Pattern work by KDM Analytics
• Identification and definition of specific domains (language, platform, functionality, etc.) and relevant protection profiles based on coverage of CWEs. These domains and profiles could provide a valuable tool to security testing strategy and planning efforts.

Contact Us

To discuss the CWE effort in general, the impacts and opportunities noted above, or any other questions or concerns, please email us at cwe@mitre.org.