Common Weakness Enumeration

Frequently Asked Questions (FAQ)

FAQ answers are available for the topics below. Please contact us to provide feedback about this page.

What is CWE? What are software and hardware "weaknesses"?
What is the difference between a vulnerability and a weakness?
Why CWE? Is there a lot of support for something like this?
Can't hackers use this to break into my network, system, or product?
How can CWE help me?
Who owns CWE? Is CWE free for public use?
What is the relationship between CWE and CAPEC?
What is the relationship between CWE and CVE?
What is the relationship between CWE and NVD?
How is CWE related to other Software Assurance (SwA) efforts?

What is CWE? What are software and hardware "weaknesses"?

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 and hardware weaknesses that can occur in architecture, design, code, or implementation that can lead to exploitable security vulnerabilities. CWE was created to serve as a common language for describing security weaknesses; serve as a standard measuring stick for security tools targeting these weaknesses; and to provide a common baseline standard for weakness identification, mitigation, and prevention efforts.

A “weakness” is a condition in a software, firmware, hardware, or service component that, under certain circumstances, could contribute to the introduction of vulnerabilities.

Weaknesses Examples:

• Software — 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.
• Hardware — core and compute issues typically associated with CPUs, Graphics, Vision, AI, FPGA, and uControllers; privilege separation and access control issues related to identity and policy, shared resources, locking controls, registers, and other features and mechanisms; and power, clock, and reset concerns related to voltage, electrical current, temperature, clock control, and state saving/restoring.

See About CWE and the CWE List for additional information.

What is the difference between a vulnerability and a weakness?

Weaknesses are errors that can lead to 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. A hardware vulnerability is a mistake in hardware or its firmware that can be used by a hacker to gain remote or physical access to a system. See What is CWE? What are software and hardware "weaknesses"? for additional information.

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 and hardware acquirers, architects, designers, and programmers on how to eliminate the most common mistakes before a product is delivered. CWE serves as a resource for programmers as they write code, for architects as they design new software, for hardware engineers as they create physical components, and supports educators in teaching security as part of curriculum for software and hardware engineering, computer science, and management information systems; CWE ultimately helps them prevent the kinds of security vulnerabilities that have plagued the software and hardware industries and put enterprises at risk. CWE continues to evolve as a collaborative community effort to populate a publicly available repository of software and hardware 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.

Can't hackers use this to break into my network, system, or product?

Any public discussion about weaknesses in software and hardware 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 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 hardware, and reducing them in future updates and releases.
• CWE enables more effective description, selection, and use of 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 similar programs such as Common Vulnerabilities and Exposures (CVE®), Common Attack Pattern Enumeration and Classification (CAPEC™), the “CWE Top 25 Most Dangerous Software Errors List,” and the fact that the CWE Community includes key organizations in information security.

How can CWE help me?

Software and hardware 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:

• CWE Top 25 Most Dangerous Software Errors List – provides enterprises and vendors with priorities for mitigation and prevention.
• Common Weakness Scoring System (CWSS™) – allows organizations to score the severity of software coding errors found in their software applications in order in mitigate weaknesses in applications they are currently using and to influence future purchases.
• Common Weakness Risk Analysis Framework (CWRAF™) – allows for organizations to apply CWSS to those CWEs that are most relevant to their own specific businesses, missions, and deployed technologies.
• CWE Coverage Claims Representation (CCR) – allows for software analysis vendors to convey to their customers in XML format exactly which CWE-identified weaknesses they claim to be able to locate in software.

Who owns CWE? Is CWE free for public use?

The MITRE Corporation maintains CWE, its follow-on efforts, and this public website; 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 us if you require further clarification on this issue.

What is the relationship between CWE and CAPEC?

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

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 in 2006 to better address those additional needs.

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.

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

CWE, along with its follow-on CWE Top 25, CWSS, and CWRAF, 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 U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and the international CWE Community, provides the requisite characterization of exploitable software constructs to enable the education and training of developers on how to eliminate all-too-common errors before software and hardware products are delivered and put into operation.

In addition, CWE enables the interoperable automation of SwA ecosystem components and projects, such as the Object Management Group (OMG) SwA Task Force's OMG SwA Ecosystem.

CWE COMMUNITY

Who is the CWE Community? What is their role?
How can my organization and I be involved in this effort?
What is the role of the CWE Research Email Discussion List and how can I join?
Is someone from CWE available to speak or participate on panel discussions at industry-related events, meetings, etc.?
How can I submit content for the CWE List?

CWE COMPATIBILITY

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

SPONSOR

Who pays for CWE? Who is the sponsor?

MITRE'S ROLE

What is MITRE's role in CWE?

CWE COMMUNITY

Who is the CWE Community? What is their role?

An integral component of the CWE effort is broad community participation. The CWE community includes:

• A CWE Board comprised of members from around the world that sets and promotes the goals and objectives of the CWE Program to ensure the ongoing adoption, coverage, and quality of CWE
• CWE special interest groups (SIGs) and working groups (WGs), each focused on specific areas of the program
• Individual researchers and representatives from numerous organizations from across industry, academia, and government interested in actively reducing and managing weaknesses in software and hardware who:
  
  • Participate in content development and other conversations on the CWE Research Discussion List
  • Submit software and hardware weaknesses and related content for the CWE List
  • Engage with us and the community to help promote CWE on social media
  • Advocate for the expansion and active use of CWE and the CWE Top-N lists by the community

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

See CWE Community.

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.

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

Yes, contact us to have the CWE Team present a briefing or participate in a panel discussion about CWE, the CWE Top 25, CWSS, and/or CWRAF efforts at your next event.

How can I submit content for the CWE List?

See Content Submissions.

CWE COMPATIBILITY

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 locates.
• CWE TEST RESULTS – for CWE-Effectiveness, test results from the capability showing the results of assessing the CWEs for a product are posted on the CWE website.

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.

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.

What is Coverage Claims Representation (CCR)?

CCR is a means for analysis vendors to convey to their customers exactly which CWE-identified weaknesses they claim to be able to locate. 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.

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.

SPONSOR

Who pays for CWE? Who is the sponsor?

CWE is sponsored by the office of the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA). This CWE website is sponsored and managed by MITRE to enable stakeholder collaboration.

MITRE'S ROLE

What is MITRE’s role in CWE?

The MITRE Corporation (MITRE) maintains the CWE List and its follow-on efforts (i.e., CWE 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.

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

What is the CWE Top 25 List?

The CWE Top 25 Most Dangerous Software Weaknesses List is a demonstrative list of the most common and impactful issues experienced over the previous two calendar years. These weaknesses are dangerous because they are often easy to find, exploit, and can allow adversaries to completely take over a system, steal data, or prevent an application from working. The CWE Top 25 is a valuable community resource that can help developers, testers, and users – as well as project managers, security researchers, and educators – provide insight into the most severe and current security weaknesses.

The current release of the CWE Top 25 uses real-world vulnerability data from the U.S. National Vulnerability Database (NVD), combining frequency and an average Common Vulnerability Scoring System (CVSS) score to determine a rank order. For details about this new approach, visit the CWE Top 25 page.

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

The CWE Top 25 list 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.

NOTE: The Common Weakness Scoring System (CWSS™) and Common Weakness Risk Analysis Framework (CWRAF™) allow organizations to directly address their own specific needs.

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 Top 25, as well as the follow-on Common Weakness Scoring System (CWSS™) and Common Weakness Risk Analysis Framework (CWRAF™) efforts, 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 the CWE and Common Vulnerabilities and Exposures (CVE®) efforts.

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

How are the weaknesses prioritized on the list?

For the current release, the CWE Team pulled vulnerability data directly from the U.S. National Vulnerability Database (NVD) and developed a scoring formula to calculate a rank order of weaknesses that combines the frequency of a CWE with the projected severity of its exploitation. While this method introduces a bias through analyzing only reported vulnerabilities and could potentially exclude some software and a breadth of other data, the CWE Team believes it will result in a more repeatable and accurate Top 25 list each year.

For detailed information about this new approach, including methodology, rankings, scoring, and refined mappings, visit the CWE Top 25 page.

Is the Top 25 still updated each year?

Yes, the CWE Top 25 will be updated annually using the methodology described on the CWE Top 25 page.

For information about previous releases, visit the CWE Top 25 Archive.

What types of software and hardware weaknesses are included on the CWE List?
What is a CWE-ID? How is it used?
What information is included in a CWE weakness entry?
Is there a glossary or key available to help me understand CWE terminology?
What is included in the CWE List ZIP download file?
How can I use the CWE schema?
Why is there a printable version of the CWE List? What information is included in it?
Are Change Logs available for the different release versions of the CWE List?
How can I get a complete copy of the CWE List?

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

See What is CWE? What are software and hardware "weaknesses"? for examples, and the CWE List page for the most current list.

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.

• Category IDs – assigned to collections of weaknesses sharing a common attribute(s). For example, CWE-557: Concurrency Issues or CWE-355: User Interface Security Issues, where the shared attributes may be any number of things including, but not limited to, functional area (e.g., authentication, cryptography) and the relevant resource (e.g., credentials management, certificate issues).
• Compound Element IDs – assigned to meaningful aggregations of several weaknesses, as in a composite or chain. For example, in a chain such as CWE-252: Unchecked Return Value that can result in CWE-476: NULL Pointer Dereference, or in a composite such as CWE-352 Cross-Site Request Forgery.
• View IDs – assigned to predefined perspectives with which one might look at the weaknesses in CWE. For example, CWE-699: Software Development is geared towards architects, designers, coders, and testers whose goal is to eliminate mistakes from a software application, while CWE-1000: Research Concepts is oriented towards academic research, creating a new framework for classifying weaknesses.
• Weakness IDs – assigned to the actual weaknesses themselves, such as CWE-311: Failure to Encrypt Sensitive Data or CWE-326: Weak Encryption. Within Weakness IDs, there are four sub-classifications: “Pillar”, which are the more abstract representations; “Class”, typically independent of any specific language or technology such as CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'); “Base”, which is a more specific type of weakness that is still mostly independent of a specific resource or technology such as CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'); and “Variant”, which is a weakness specific to a particular resource, technology, or context such as CWE-83: Improper Neutralization of Script in Attributes in a Web Page.

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

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 applicable platforms
• Description of how the weakness may be introduced
• 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 (CVE IDs) of vulnerabilities for which that type of weakness exists
• References

Refer to the Schema and Schema Documentation for more information.

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.

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 selected view in XML format.

How can I use the CWE schema?

The CWE Schema is provided for validating the various XML downloads files of individual CWE entries provided on the CWE List page. See the Schema Documentation for additional information.

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

The Printable Version of CWE was created for those wishing to view and use the CWE List in PDF or printed format. 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.

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

Yes, see Reports.

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

CWE is provided in multiple formats on the CWE List and Downloads, and Archive pages.

What do the numerals in parenthesis signify in the various views of the CWE List?
How can the four different Overviews of the CWE List help me?
What is the difference between an Explicit Slice and an Implicit Slice? How can the various slices under each category help me?
What are the Composites and how can they help me?
What are the Named Chains and how can they help me?
Is there a key to the small icons used on the definition and view pages?

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

The numbers in parenthesis are the CWE IDs for that category or weakness being listed. See What is a CWE-ID? How is it used? for additional information.

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

Development Concepts – This view organizes weaknesses around concepts that are frequently used or encountered in software development. Accordingly, this view can align closely with the perspectives of developers, educators, and assessment vendors. It provides a variety of categories that are intended to simplify navigation, browsing, and mapping.

Research Concepts – This view is intended to facilitate research into weaknesses, including their inter-dependencies, and can be leveraged to systematically identify theoretical gaps within CWE. It classifies weaknesses in a way that largely ignores how they can be detected, where they appear in code, and when they are introduced in the software development life cycle. Instead, it is mainly organized according to abstractions of software behaviors.

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.

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 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 1026: Weaknesses in OWASP Top Ten (2017) and CWE 1128: CISQ Quality Measures (2016).

An "Implicit Slice" is a Slice that defines its membership based on common characteristics of entries, such as CWE-658: Weaknesses in Software Written in C.

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

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.

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.

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:

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

COMMON WEAKNESS SCORING SYSTEM (CWSS)

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

COMMON WEAKNESS RISK ANALYSIS FRAMEWORK (CWRAF)

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

COMMON WEAKNESS SCORING SYSTEM (CWSS)

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, CWEs – 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.

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.

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.

How can I customize CWSS for my organization?

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

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 us if you require further clarification on this issue.

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.

COMMON WEAKNESS RISK ANALYSIS FRAMEWORK (CWRAF)

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.

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.

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.

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.

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.

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. 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 us.

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 us if you require further clarification on this issue.