CWE

Common Weakness Enumeration

A Community-Developed Dictionary of Software Weakness Types

Common Weakness Scoring System
Common Weakness Risk Analysis Framework
Home > About CWE > Frequently Asked Questions (FAQ)  

Frequently Asked Questions (FAQ)

Introduction

  1. What is CWE? What is a "software weakness"?
  2. What is the difference between a software vulnerability and a software weakness?
  3. Why CWE? Is there a lot of support for something like this?
  4. Can't hackers use this to break into my network or system?
  5. How can CWE help me?
  6. Who owns CWE? Is CWE free for public use?
  7. What is the relationship between CWE and CAPEC?
  8. What is the relationship between CWE and CVE?
  9. What is the relationship between CWE and NVD?
  10. How is CWE related to other Software Assurance (SwA) efforts?
  11. Does the CWE Web site participate in link exchange arrangements?

CWE List

  1. What types of software weaknesses are included on the CWE List?
  2. What is a CWE-ID? How is it used?
  3. What information is included in a CWE weakness entry?
  4. Is there a glossary or key available to help me understand CWE terminology?
  5. What is included in the CWE List ZIP download file?
  6. How can I use the CWE schema?
  7. Why is there a printable version of the CWE List? What information is included in it?
  8. What do the numerals in parenthesis signify in the various views of the CWE List?
  9. What are the differences between the Graph, List, Slice, and the XML.zip options in the various views?
  10. How can the four different Overviews of the CWE List help me?
  11. Why is the "Graph" view not graphical?
  12. What is the difference between an Explicit Slice and an Implicit Slice? How can the various slices under each category help me?
  13. What are the Composites and how can they help me?
  14. What are the Named Chains and how can they help me?
  15. Are Change Logs available for the different release versions of the CWE List?
  16. How can I get a complete copy of the CWE List?
  17. Is there a key to the small icons used on the definition and view pages?

CWE/SANS Top 25 Most Dangerous Software Errors List

  1. What is the CWE/SANS Top 25 List?
  2. What should I do to address these errors? How can the Top 25 help me?
  3. Can't hackers use this to break into my network or system?
  4. How is this different from the OWASP Top Ten?
  5. How are the weaknesses prioritized on the Top 25 list?
  6. Is the Top 25 list still updated each year?

Common Weakness Scoring System (CWSS)

  1. What is CWSS? How is it related to CWE?
  2. How does CWSS work?
  3. How does CWSS help me protect my network or system?
  4. How can I customize CWSS for my organization?
  5. Is CWSS free for public use?
  6. Is there a CWSS calculator, such as the calculators for the Common Vulnerability Scoring System (CVSS)?

Common Weakness Risk Analysis Framework (CWRAF)

  1. What is CWRAF? How is it related to CWE and CWSS?
  2. What's a "business domain"?
  3. What's an "archetype"?
  4. What's a "vignette"?
  5. How does CWRAF help me protect my network or system?
  6. How can I customize CWRAF for my organization?
  7. Is CWRAF free for public use?

CWE Compatibility

  1. What does it mean to be "CWE-Compatible"? What does it mean to be "CWE-Effective"?
  2. How can my product or service be made CWE-Compatible and/or CWE-Effective? Are there specific requirements that must be met?
  3. What is Coverage Claims Representation (CCR)?
  4. How can my organization register our product or service as CWE-Compatible and/or CWE-Effective?

CWE Community

  1. Who is the CWE Community? What is their role?
  2. How can my organization and I be involved in this effort?
  3. What is the role of the CWE Research Email Discussion List and how can I join?
  4. Is someone from CWE available to speak or participate on panel discussions at industry-related events, meetings, etc.?
  5. What is MITRE?
  6. What is MITRE's role in CWE?
  7. Why is MITRE maintaining CWE and how long does MITRE plan to maintain it?
  8. Who pays for CWE? Who is the sponsor?
  9. What is the relationship between CWE and DHS?
A. Introduction

A1. What is CWE? What is a "software weakness"?

Targeted at both the development community and the community of security practitioners, Common Weakness Enumeration (CWE™) is a formal list or dictionary of common software weaknesses that can occur in software's architecture, design, code or implementation that can lead to exploitable security vulnerabilities. CWE was created to serve as a common language for describing software security weaknesses; serve as a standard measuring stick for software security tools targeting these weaknesses; and to provide a common baseline standard for weakness identification, mitigation, and prevention efforts.

Software weaknesses are flaws, faults, bugs, vulnerabilities, and other errors in software implementation, code, design, or architecture that if left unaddressed could result in systems and networks being vulnerable to attack. Example software weaknesses include: buffer overflows, format strings, etc.; structure and validity problems; common special element manipulations; channel and path errors; handler errors; user interface errors; pathname traversal and equivalence errors; authentication errors; resource management errors; insufficient verification of data; code evaluation and injection; and randomness and predictability.

See About CWE and the CWE List for additional information.

A2. What is the difference between a software vulnerability and software weakness?

Software weaknesses are errors that can lead to software vulnerabilities. A software vulnerability, such as those enumerated on the Common Vulnerabilities and Exposures (CVE®) List, is a mistake in software that can be directly used by a hacker to gain access to a system or network. See A1. What is CWE? What is a "software weakness"? for additional information.

A3. Why CWE? Is there a lot of support for something like this?

The main goal of the CWE initiative is to stop vulnerabilities at the source by educating software acquirers, architects, designers, and programmers on how to eliminate the most common mistakes before software is delivered. CWE serves as a resource for programmers as they design new software and write code, and supports educators in teaching security as part of curriculum for software engineering, computer science, and management information systems; CWE ultimately helps them prevent the kinds of security vulnerabilities that have plagued the software industry and put enterprises at risk. CWE continues to evolve as a collaborative community effort to populate a publicly available repository of software errors in code, design, architecture, and implementation for developers and security practitioners that can also be utilized by tool vendors for tagging what their tool’s report and claim to cover.

CWE is industry-endorsed by the CWE Community, which includes representatives from major operating systems vendors, commercial information security tool vendors, academia, government agencies, and research institutions. Community members participate in the development of CWE on the CWE Community Research email list. This means the CWE List, as well as its follow-on CWSS and CWRAF efforts, reflect the insights and combined expertise of the broadest possible collection of information technology and information security professionals.

A4. Can't hackers use this to break into my network or system?

Any public discussion about weaknesses in software and/or potential resulting vulnerabilities may help an attacker. However, there are several reasons why the benefits of CWE outweigh its risks:

  • CWE allows developers to minimize weaknesses in their software as early in the lifecycle as possible, improving its overall security.
  • CWE helps reduce risk industry-wide by enabling more effective community discussion about finding and mitigating these weaknesses in existing software, and reducing them in future updates and releases.
  • CWE enables more effective description, selection, and use of the software security tools and services that organizations can use to find these weaknesses and reduce their risk now.
  • There is a shift in community opinion towards sharing information, as reflected in the success of the collaborative nature of the Common Vulnerabilities and Exposures (CVE®) effort, and the fact that the CWE Community includes key organizations in information security.

A5. How can CWE help me?

Software development organizations and security practitioners are using CWE today as a common language for discussing how to eliminate and/or mitigate software security weaknesses in software architecture, design, code, and implementation. Organizations are using CWE today as a standard measuring stick for evaluating software security tools targeting these weaknesses, and as a common baseline standard for their weakness identification, mitigation, and prevention efforts.

In addition, CWE and the community have worked together to leverage the CWE List and create additional tools to help enterprises and software vendors in their efforts to address software weaknesses:

A6. Who owns CWE? Is CWE free for public use?

The MITRE Corporation maintains CWE, its follow-on efforts, and this public Web site; manages the compatibility program; and provides impartial technical guidance to the CWE Community throughout the process to ensure CWE serves the public interest.

CWE is free to use by any organization or individual for any research, development, and/or commercial purposes, per the CWE Terms of Use. MITRE has copyrighted the CWE List, Top 25, CWSS, and CWRAF for the benefit of the community in order to ensure each remains a free and open standard, as well as to legally protect the ongoing use of it and any resulting content by government, vendors, and/or users. MITRE has trademarked ™ the CWE and related acronyms and the CWE and related logos to protect their sole and ongoing use by the CWE effort within the information security arena. Please contact cwe@mitre.org if you require further clarification on this issue.

A7. What is the relationship between CWE and CAPEC?

While CWE is a list of software weakness types, Common Attack Pattern Enumeration and Classification (CAPEC™) is a list of the most common methods attackers use to exploit vulnerabilities resulting from CWEs. Used together, CWE and CAPEC provide understanding and guidance to software development personnel of all levels as to where and how their software is likely to be attacked, thereby equipping them with the information they need to help them build more secure software.

A8. What is the relationship between CWE and CVE?

MITRE began working on the issue of categorizing software weaknesses as early 1999 when it launched the Common Vulnerabilities and Exposures (CVE®) List. As part of building CVE, MITRE's CVE Team developed a preliminary classification and categorization of vulnerabilities, attacks, faults, and other concepts beginning in 2005 to help define common software weaknesses. However, while sufficient for CVE those groupings were too rough to be used to identify and categorize the functionality offered within the offerings of the code security assessment industry. The CWE List was created to better address those additional needs.

A9. What is the relationship between CWE and NVD?

The U.S. National Vulnerability Database (NVD) is a federal government repository of standards-based vulnerability management data. This data enables automation of vulnerability management, security measurement, and compliance (e.g., FISMA). NVD integrates CWE into the scoring of Common Vulnerabilities and Exposures (CVE®) entries, upon which NVD is built, by providing a cross section of the overall CWE structure. NVD analysts score CVEs using CWEs from different levels of the hierarchical structure. This allows analysts to score CVEs at both a fine and coarse granularity, which is necessary due to the varying levels of specificity possessed by different CVEs.

A10. How is CWE related to other Software Assurance (SwA) efforts?

CWE, along with its follow-on CWSS, CWRAF, and Top 25 efforts, are measurement and risk mitigation efforts focused on realizing software assurance (SwA). The CWE initiative, which has matured over the years through collaborative efforts of the the office of Cybersecurity and Communications at the U.S. Department of Homeland Security (DHS) and the international CWE Community, provides the requisite characterization of exploitable software constructs to enable the education and training of programmers on how to eliminate all-too-common errors before software is delivered and put into operation. This means CWE, which is sponsored by DHS, also aligns with the "Build Security In" approach to software assurance so that aims for software to be developed more securely on the front end in order to reduce or eliminate avoidable security issues in the long term.

In addition, CWE enables the interoperable automation of SwA ecosystem components and projects, including the Object Management Group (OMG) SwA Task Force's OMG SwA Ecosystem and National Institute of Standard and Technology's DHS-sponsored Software Assurance Metrics and Tool Evaluation (SAMATE) project.

A11. Does the CWE Web site participate in link exchange arrangements?

No, CWE does not exchange links with other Web sites. Only authorized links are allowed on the CWE Web site such as research and references for the CWE List and those for the CWE-Compatibility and Effectiveness Program, CWE Community Members, and News about CWE.

B. CWE List

B1. What types of software weaknesses are included on the CWE List?

Software weaknesses on the CWE List include those flaws, faults, bugs, vulnerabilities, and other errors in software code, design, architecture, or implementation that if left untreated could result in systems and networks being vulnerable to attacks. Examples of software weaknesses include buffer overflows, format strings, etc.; structure and validity problems; common special element manipulations; channel and path errors; handler errors; user interface errors; pathname traversal and equivalence errors; authentication errors; resource management errors; insufficient verification of data; code evaluation and injection; and randomness and predictability.

See the CWE List page for the most current list.

B2. What is a CWE-ID? How is it used?

CWE Identifiers' also known as CWE-IDs or CWEs' are organized into four main types: Category, Compound Element, View, and Weakness.

CWE is searchable by individual CWE-ID number from the Search CWE section of the CWE List page, and from the search field in the upper right corner of the CWE Web site masthead. In addition, links to specific CWE-IDs for the predefined Views, Graphs, Explicit Slices, Implicit Slices, Composites, and Named Chains perspectives are available in the Review CWE List section on the CWE List page.

B3. What information is included in a CWE weakness entry?

Each CWE entry includes the following information:

  • CWE Identifier Number/Name of the weakness type
  • Description of the type
  • Alternate terms for the weakness
  • Description of the behavior of the weakness
  • Description of the exploit of the weakness
  • Likelihood of exploit for the weakness
  • Description of the consequences of the exploit
  • Potential mitigations
  • Node relationship information
  • Source taxonomies
  • Code samples for the languages/architectures
  • CVE Identifier numbers of vulnerabilities for which that type of weakness exists
  • References

Refer to the Schema and Schema Documentation for more information.

B4. Is there a glossary or key available to help me understand CWE terminology?

Yes, see CWE Glossary for a list of basic terminology and Schema Documentation for the schema elements key.

B5. What is included in the CWE List ZIP download file?

The ZIP download file in the Downloads section of the CWE List page contains the CWE-1000 Research Concepts view in XML format.

There are also individual XML.zip files available of the various views in the Graphs, Explicit Slices, Implicit Slices, Composites, and Named Chains sections of the CWE List page.

B6. How can I use the CWE schema?

The CWE Schema is provided for processing the complete CWE List XML.zip download file and the various XML.zip downloads files of individual CWE entries provided on the CWE List page. See the Schema Documentation for additional information.

B7. Why is there a printable version of the CWE List? What information is included in it?

The Printable Version of CWE in the Downloads section on the CWE List page was created for those wishing to view and use the CWE List in PDF or printed format. Apparently none of the web browsers could print the entirety of CWE from the web site.  The printable version includes a complete list of all CWE entries from the most current release in numerical order along with a table of contents, an index, and the CWE-ID in the facing margins for easy searching through a printed copy. Many organizations use printed copies of CWE for design review meetings and training.

B8. What do the numerals in parenthesis signify in the various views of the CWE List?

These numerals refer to the specific CWE-ID for that particular perspective, or "View", of looking at the CWE List. For example, (1000) refers to CWE-1000: Research Concepts, and (699) refers to CWE-699: Development Concepts.

See B2. What is a CWE-ID? How is it used? for additional information.

B9. What are the differences between the Definition, Graph, List, Slice, and XML.zip options in the various views?

These five options provide different ways for looking at particular CWE "View" entries, as follows:

  • Graph – a view that specifies relationships between entries, typically of a hierarchical nature.
  • Slice – a view that is a flat list of CWE entries that does not specify any relationships between those entries.
  • List – a view that is a simple list view of CWE entries.
  • XML.zip – a machine-readable download of the entry in XML format.

These options may be accessed for View entries directly from the CWE List page, or from the upper right-hand corner of each individual page for a CWE View entry (e.g., as on the page for CWE-699).

B10. How can the four different Overviews of the CWE List help me?

Development Concepts – This view organizes the weaknesses around concepts that are frequently used or encountered in software development, making it useful for the needs of software developers, educators, and assessment vendors.

Research Concepts – This view classifies weaknesses according to abstractions of software behaviors and explicitly identifies relationships that form chains and composites, which have not been a formal part of past classification efforts and might help explain why mutual exclusivity is difficult to achieve within security error taxonomies. This view is useful for academic research, CWE maintenance, and mapping. It can be leveraged to systematically identify theoretical gaps within CWE and, by extension, the general security community.

Comprehensive CWE Dictionary – This view lists all elements on the CWE List in alphabetical order by weakness type. This view can be useful to any researcher, educator, software developer, or other organization interested in locating specific weakness types.

PDFs with Graphical Depictions of CWE – This view provides graphical representations of various CWE views as PDF files. It can be used to quickly see the structure implied by the parent relationships in those views. Also, some files provide "coverage graphs" in which the members of a smaller view are highlighted within the context of a larger view, illustrating how the entries of the smaller view are organized by the larger view.

B11. Why is the "Graph View” not graphical?

A "Graph View” in CWE, as opposed to a graphical view, is a view that shows relationships between entries, typically of a hierarchical nature. The root level nodes of the view are specified using HasMember (i.e., the members of that view are specified using the HasMember field) relationships. Children are specified using ChildOf (i.e., the CWEs that have a familial relationship or association are specified using the ChildOf field) relationships.

B12. What is the difference between an Explicit Slice and an Implicit Slice? How can the various slices under each category help me?

An "Explicit Slice" is a Slice view whose membership is determined by some external criterion that is represented using HasMember relationships between the view and those entries, but not between entries themselves. Examples are CWE-635, which lists the CWE Identifiers that are being used by NVD, and CWE-630 which lists the CWE Identifiers that are being focused on by SAMATE.

An "Implicit Slice" is a Slice that defines its membership based on common characteristics of entries, such as CWE-658, which are weaknesses that can appear in C programs.

Slices are one of the “View” mechanisms within CWE that are meant to help people focus on the portion of the CWE content that they are looking for.

B13. What are the Composites and how can they help me?

The Composite are those instances in which two or more distinct weaknesses must be present at the same time in order for a potential vulnerability to arise, and where removing any of the weaknesses eliminates or sharply reduces the risk. For example, CWE-61: UNIX Symbolic Link (Symlink) Following is only possible through a combination of several component weaknesses, including CWE-340: Predictability Problems, CWE-275: Permission Issues, and CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition').

By eliminating any single component, a developer can prevent the composite from becoming exploitable.  Often the various components of a composite are found in different aspects of a software system, either in the architecture, design, code, or implementation, which means that multiple assessment methods may be needed to find them or that one type of assessment method – like a static analysis tool can find issues in code but not in design, architecture, or implementation.

B14. What are the Named Chains and how can they help me?

A "Chain" is a sequence of two or more separate weaknesses that can be closely linked together within software, where one weakness can directly create the conditions that are necessary to cause another weakness. The "Named Chains" are those chains that appear so frequently in software that a CWE-ID has been assigned to it, such as CWE-680: Integer Overflow to Buffer Overflow.

By understanding how one weakness can chain to another weakness and result in another type of weakness, assessment results that show the presence of one of the weaknesses in a chain can now be viewed in light of the possibility that the one weakness discovered could be indicating the presence of the entire chain.

B15. Are Change Logs available for the different release versions of the CWE List?

Yes, see the Release Notes section of the CWE List page for change logs and the Schema Documentation section of the CWE List page for the schema change logs.

B16. How can I get a complete copy of the CWE List?

CWE is provided in multiple formats on the CWE List page, including html, XML, and PDF.

B17. Is there a key to the small icons used in the Type column in the Relationship section of the definition pages?

A key to the image icons is included below:

Description: Compound Element: Composite Compound Element Composite – An entry that consists of two or more distinct weaknesses, in which all weaknesses must be present at the same time in order for a potential vulnerability to arise. Removing any of the weaknesses eliminates or sharply reduces the risk.
Description: Weakness Base Weakness Base – A weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. It is more general than a Variant weakness, but more specific than a Class weakness.
Description: Description: Weakness Class Weakness Class – A weakness that is described in a very abstract fashion, typically independent of any specific language or technology. It is more general than a Base weakness.
Description: Category Category – A CWE entry that contains a set of other entries that share a common characteristic.
Description: View View – A subset of CWE entries that provides a way of examining CWE content. The two main View Structures are Slices (flat lists) and Graphs (containing relationships between entries).
Description: Weakness Variant Weakness Variant - A weakness that is described at a very low level of detail, typically limited to a specific language or technology. It is more specific than a Base weakness.

Refer to the CWE Glossary and Schema Documentation for additional definitions of CWE terminology.

C. CWE/SANS Top 25 Most Dangerous Software Errors List

C1. What is the CWE/SANS Top 25 List?

Last issued in 2011, the CWE/SANS Top 25 Most Dangerous Software Errors List was a community-built consensus list that provides enterprises and vendors with current-year priorities for mitigation and prevention. The Top 25 identifies the most widespread and critical programming errors that can lead to serious software vulnerabilities. These weaknesses are often easy to find, and easy to exploit. They are dangerous because they will frequently allow attackers to completely take over the software, steal data, or prevent the software from working at all.

The Top 25 was the result of collaboration between the SANS Institute, MITRE Corporation, and many top software security experts in the U.S. and Europe. It leveraged experiences in the development of the SANS Top 20 attack vectors and MITRE's CWE List.

The Top 25 was issued in 2010 and 2011; Common Weakness Scoring System (CWSS™) and Common Weakness Risk Analysis Framework (CWRAF™) now allow organizations to directly address their own specific needs.

C2. What should I do to address these errors? How can the Top 25 help me?

The CWE/SANS Top 25 list, last issued in 2011, is a tool for education and awareness that can help the community as a whole reduce the perpetuation of weaknesses in software code that could lead to dangerous vulnerabilities.

Software Developers – Use the Top 25 to help prevent the kinds of vulnerabilities that plague the software industry, by identifying and avoiding all-too-common mistakes that occur before software is even shipped.

Software Users – Use the Top 25 to help achieve a better awareness of your organization's current risk posture, and to ask your vendors for more secure software.

Software Security Researchers – Use the Top 25 to focus on a narrow but important subset of all known security weaknesses.

Software Managers and CIOs – Use the Top 25 list as a measuring stick of progress in your efforts to secure your organization's software and thus improve your security posture.

Refer to Training Materials and Monster Mitigations for the Top 25 for additional information.

NOTE: The Top 25 was issued in 2010 and 2011; Common Weakness Scoring System (CWSS™) and Common Weakness Risk Analysis Framework (CWRAF™) now allow organizations to directly address their own specific needs.

C3. Can't attackers use this to break into my network or system?

Any public discussion about weaknesses in software code and/or potential resulting vulnerabilities may help a hacker. However, there are several reasons why the benefits of the CWE/SANS Top 25, as well as the follow-on Common Weakness Scoring System (CWSS™) and Common Weakness Risk Analysis Framework (CWRAF™) efforts that replaced the Top 25, outweigh their risks:

  • The Top 25 allows developers to minimize weaknesses in their software as early in the lifecycle as possible, improving its overall security.
  • The Top 25 helps reduce risk industry-wide by enabling more effective community discussion about finding and mitigating these weaknesses in existing software, and reducing them in future releases.
  • The Top 25 enables more effective description, selection, and use of the software security tools and services that organizations can use to find these weaknesses and reduce their risk now.
  • There is a shift in community opinion towards sharing information, as reflected in the success of the collaborative nature of MITRE's CWE and Common Vulnerabilities and Exposures (CVE®) efforts, and the fact that the members of the CWE Community that helped build the Top 25 included key organizations in information security.

C4. How is this different from the OWASP Top Ten?

The OWASP Top Ten covers more general concepts and is focused on Web applications. The CWE/SANS Top 25 covers a broader range of issues than what arises from the Web-centric view of the OWASP Top Ten, such as buffer overflows. Also, one goal of the Top 25 was to be at a level that is directly actionable to programmers, so it contains more detailed issues than the categories being used in the Top Ten. There is some overlap however, since web applications are so prevalent, and some issues in the Top Ten have general applications to all classes of software.

C5. How are the weaknesses prioritized on the list?

The CWE/SANS Top 25 was built upon a survey of a select number organizations that rank potential weaknesses based on their prevalence and importance, which also provided quantitative support to the final rankings.

C6. Is the Top 25 still updated each year?

No, the CWE/SANS Top 25 is no longer updated. Issued in 2010 and 2011, the Top 25 prioritized the most exploitable constructs that make software vulnerable to attack or failure; yet they contain a mix of weaknesses with some only applicable to specific applications or technologies. Common Weakness Scoring System (CWSS™) and Common Weakness Risk Analysis Framework (CWRAF™) now allow organizations to directly address their own specific needs, so the Top 25 is no longer issued. See the CWSS and CWRAF sections of this page for additional information.

D. Common Weakness Scoring System (CWSS)

D1. What is CWSS? How is it related to CWE?

The Common Weakness Scoring System (CWSS™) allows organizations to score the severity of software coding errors–that is, CWE–found in their software applications in order in mitigate weaknesses in applications they are currently using and to influence future purchases. When used in conjunction with the Common Weakness Risk Analysis Framework (CWRAF™), organizations are able to apply CWSS to those CWEs that are most relevant to their own specific businesses, missions, and deployed technologies.

For additional information, visit the CWE-CWSS-CWRAF Framework Overview.

D2. How does CWSS work?

CWSS scores CWEs using 18 different factors across three metric groups: (1) the Base Finding group, which captures the inherent risk of the weakness, confidence in the accuracy of the finding, and strength of controls; (2) the Attack Surface group, which captures the barriers that an attacker must cross in order to exploit the weakness; and (3) the Environmental group, which includes factors that may be specific to a particular operational context, such as business impact, likelihood of exploit, and existence of external controls.

For a detailed description of how CWSS works visit the CWSS page.

D3. How does CWSS help me protect my network or system?

By knowing the severity of weaknesses software developers and organizations that use that software will know which CWEs should have priority in being addressed. In addition, educators teaching software code writing will know which weaknesses should be addressed directly in their curriculum.

D4. How can I customize CWSS for my organization?

See the Common Weakness Risk Analysis Framework (CWRAF™).

D5. Is CWSS free for public use?

CWSS is free to use by any organization or individual for any research, development, and/or commercial purposes, per the CWE Terms of Use. MITRE has copyrighted the CWE List, CWSS, CWRAF, and Top 25 for the benefit of the community in order to ensure each remains a free and open standard, as well as to legally protect the ongoing use of it and any resulting content by government, vendors, and/or users. Please contact cwe@mitre.org if you require further clarification on this issue.

D6. Is there a CWSS calculator, such as the calculators for the Common Vulnerability Scoring System (CVSS)?

No, at this time there is no calculator available for CWSS.

E. Common Weakness Risk Analysis Framework (CWRAF)

E1. What is CWRAF? How is it related to CWE and CWSS?

Common Weakness Risk Analysis Framework (CWRAF™) allows for organizations to apply Common Weakness Scoring System (CWSS™) to those CWEs that are most relevant to their own specific businesses, missions, and deployed technologies. With CWRAF, any organization can apply CWSS to score the severity of CWEs found in the software applications they are currently using in order to mitigate or remediate those weaknesses as soon as possible, and/or to influence future purchases.

CWRAF uses the CWSS scoring criteria with CWE to provide consistent measures for prioritizing risk exposures and for focusing on mitigation efforts and secure coding practices. CWRAF also enables better informed decision-making for the development and acquisition of more secure and resilient software products and services.

E2. What's a "business domain"?

In CWRAF, a Business Domains is a major function or service that includes the operations and interactions of a broad range of networked capabilities or organizations from the public and private sector, government and military, commercial and nonprofit organizations, academia, etc., that are enabled or controlled by software/IT and require some degree of resilience and security in transactions or operations. Examples of business domains for CWRAF include Finance, e-Commerce, Public Health, Emergency Services, Telecommunications, etc.

For additional information see the CWRAF page and CWRAF Domains, Technology Groups, Archetypes, and Vignette.

E3. What's an "archetype"?

In CWRAF, an Archetype is general type of technical capability, component, system, system-of-systems, or architecture that is commonly used to support the mission of a particular organization. An archetype may also be used within multiple business domains. An archetype could be a Web application, Web server, database, smartphone, Supervisory Control and Data Acquisition (SCADA) system, etc. For example, many industries manage their information using database-connected Web servers and SCADA systems are used in electrical power grids, manufacturing, oil and gas transmission, and other domains.

For additional information see the CWRAF page and CWRAF Domains, Technology Groups, Archetypes, and Vignette.

E4. What's a "vignette"?

In CWRAF, a Vignette is a shareable, semi-formal description of a particular environment within a business domain, the role that software plays within that environment, and an organization's priorities with respect to software security. The vignette identifies essential resources and capabilities, as well as their importance relative to security principles such as confidentiality, integrity, and availability. For example, in an e-commerce context, 99.999% uptime may be a strong business requirement that drives the interpretation of the severity of discovered weaknesses.

Vignettes allow CWRAF to support diverse audiences that may have different requirements for how to prioritize weaknesses. Those audiences can also use CWRAF to score within the context of the vignette that's most applicable to them.

For additional information see the CWRAF page and CWRAF Domains, Technology Groups, Archetypes, and Vignette.

E5. How does CWRAF help me protect my network or system?

By knowing the severity of those CWEs that directly affect your organization because of the software you are currently using, you will have a much more complete understanding of your organization's security risk posture than ever before. You will know which CWEs should be addressed immediately, either internally or with your vendors. You will also have actionable data with which to influence your vendors to improve future versions of their products and services, and to help your organization acquire more secure alternate software in the future if need be.

E6. How can I customize CWRAF for my organization?

CWRAF enables more targeted prioritization of "Top-N" CWE lists, with respective mitigation practices, that are relevant to specified technologies used by organizations within specific business domains. The 2010 and 2011 releases of the CWE/SANS Top 25 Most Dangerous Software Errors List gained wide attention because they represent community collaboration efforts to prioritize the most exploitable constructs that make software vulnerable to attack or failure; yet they contain a mix of weaknesses with some only applicable to specific applications or technologies. With CWRAF, enterprises from any business domain can use the CWSS scoring criteria with CWE to identify exploitable software fault patterns and associated mitigation practices that are most relevant to them in specific technologies including Web applications, control systems, embedded systems, end-point computing devices, identity management systems, operating systems, databases, storage systems, enterprise system applications, and cloud computing services.

CWRAF uses vignettes with archetypes to identify applicable CWEs in respective technologies used by specific business domains. CWSS scoring criteria applies business value context to specify the top CWEs most applicable to the respective situation.

For a detailed description of how CWRAF works visit the CWRAF page or contact cwe@mitre.org.

E7. Is CWRAF free for public use?

CWRAF is free to use by any organization or individual for any research, development, and/or commercial purposes, per the CWE Terms of Use. MITRE has copyrighted the CWE List, CWSS, CWRAF, and Top 25 for the benefit of the community in order to ensure each remains a free and open standard, as well as to legally protect the ongoing use of it and any resulting content by government, vendors, and/or users. Please contact cwe@mitre.org if you require further clarification on this issue.

F. CWE Compatibility

F1. What does it mean to be "CWE-Compatible"? What does it mean to be "CWE-Effective"?

"CWE-Compatible" means that a product or service meets the first four (4) requirements listed below, while "CWE-Effective" means that a product or service meets all six (6) requirements.

  • CWE SEARCHABLE – users may search security elements using CWE Identifiers (CWE-IDs).
  • CWE OUTPUT – security elements presented to users includes, or allows users to obtain, associated CWE-IDs.
  • MAPPING ACCURACY – security elements accurately link to the appropriate CWE-IDs.
  • CWE DOCUMENTATION – capability's documentation describes CWE, CWE compatibility, and how CWE-related functionality in the capability is used.
  • CWE COVERAGE – for CWE-Compatibility and CWE-Effectiveness, the capability's documentation explicitly lists the CWE-IDs that the capability claims coverage and effectiveness against locating in software.
  • CWE TEST RESULTS – for CWE-Effectiveness, test results from the capability showing the results of assessing software for the CWEs are posted on the CWE Web site.

Visit the CWE-Compatible and CWE-Effective Products and Services section for the most current information regarding the types and availability of CWE-Compatible and CWE-Effective products and services.

F2. How can my product or service be made CWE-Compatible? Are there specific requirements that must be met?

See the CWE Compatibility and Effectiveness Program, Requirements and Recommendations for CWE Compatibility and CWE Effectiveness, and Coverage Claims Representation (CCR) for detailed information.

F3. What is Coverage Claims Representation (CCR)?

CCR is a means for software analysis vendors to convey to their customers exactly which CWE-identified weaknesses they claim to be able to locate in software. CCR documents are written in Extensible Markup Language (XML) based upon the CCR schema.

Each CCR claim document contains the following information:

  • Name of the organization making the coverage claim.
  • Name of the product or service to which the coverage claim refers.
  • Date the coverage claim was made.
  • Where the tool or service claims to be able to find weaknesses, i.e. which programming languages and/or binary formats are being analyzed.
  • Lists the specific CWE Identifiers for which coverage is claimed and details of that coverage.

Note that organizations make these claims on the honor system and neither the CCR itself nor the CWE Compatibility Program verify or otherwise vet the CCR statements of coverage.

See Coverage Claims Representation (CCR) for an example and/or more information.

F4. Can my organization register our product or service as CWE-Compatible?

To begin the process, send an email to cwe@mitre.org requesting a Declaration Form along with your organization name, contact information, the type of product, and the name of the product or service.

See Make a Declaration for more information.

G. CWE Community

G1. Who is the CWE Community? What is their role?

The CWE community includes individual researchers and representatives from numerous organizations from across industry, academia, and government interested in actively reducing and managing weaknesses in software. Refer to the CWE Community page for a complete list of member organizations.

G2. How can my organization and I be involved in this effort?

An integral component of the CWE effort is broad community participation. Visit the CWE Community and Discussion List Sign-Up pages for additional information.

G3. What is the role of the CWE Research Email Discussion List and how can I join?

The CWE Research Email Discussion List is a lightly moderated public forum to discuss CWE definitions, suggest potential definition expansion(s), and/or submit new definitions. General discussion of the vulnerabilities themselves is also welcome.

Active participation is an important part of the CWE effort. Members of the information security community are all invited to participate. A confirmation will be sent to you verifying your addition to the list(s). View our Privacy Policy.

G4. Is someone from CWE available to speak or participate on panel discussions at industry-related events, meetings, etc.?

Yes, contact cwe@mitre.org to have MITRE present a briefing or participate in a panel discussion about CWE, CWSS, and/or CWRAF efforts at your next event.

G5. What is MITRE?

In partnership with government clients, The MITRE Corporation (MITRE) is a not-for-profit corporation working in the public interest. It addresses issues of critical national importance, combining systems engineering and information technology to develop innovative solutions that make a difference.

MITRE's work is focused within Federally Funded Research and Development Centers (FFRDCs) for the Department of Defense, Federal Aviation Administration, Internal Revenue Service and Department of Veterans Affairs, Department of Homeland Security, Administrative Office of the U.S. Courts; and the Centers for Medicare and Medicaid Services.

G6. What is MITRE's role in CWE?

MITRE created the CWE Community, maintains the CWE List and its follow-on efforts (i.e., Top 25, CWSS, and CWRAF), moderates the CWE Research email list, and provides neutral guidance throughout the process to ensure that CWE serves the public interest.

G7. Why is MITRE maintaining CWE and how long does MITRE plan to maintain it?

In accordance with its mission, MITRE has traditionally acted in the public interest. Its unique role allows it to provide an objective perspective to this effort. MITRE will maintain CWE as long as it serves the community to do so.

G8. Who pays for CWE? Who is the sponsor?

CWE is sponsored by the office of Cybersecurity and Communications at the U.S. Department of Homeland Security. This CWE Web site is sponsored and managed by MITRE to enable stakeholder collaboration.

G9. What is the relationship between CWE and DHS?

CWE is one of the key initiatives sponsored by the office of Cybersecurity and Communications at the U.S. Department of Homeland Security (DHS) Software Assurance (SwA) program, with additional funds from the Department of Defense (primarily through the National Security Agency), and represents a joint effort of the U.S. Federal Government and the software stakeholder community with MITRE providing technical leadership and project coordination.

With the aim of better enabling software stakeholders to reduce risks attributable to the most significant exploitable software errors relevant to specific business/mission domains and technologies, the DHS SwA program also sponsored MITRE's development of the Common Weakness Scoring System (CWSS™) for scoring the severity of weaknesses, and the CWE Common Weakness Risk Analysis Framework (CWRAF™) that uses the CWSS scoring criteria with CWE to provide consistent measures for prioritizing risk exposures and focusing on mitigation efforts and secure coding practices. Use of these efforts enables better informed decision-making for the development and acquisition of more secure and resilient software products and services.

Learn more about the DHS SwA program at https://buildsecurityin.us-cert.gov/swa/.

Page Last Updated: July 25, 2014