CWE [Common Weakness Enumeration] | Why It Is Important

December 16, 2021 HackerOne Team

Common Weakness Enumeration (CWE) is a system to categorize software security flaws—implementation defects that can lead to vulnerabilities. It is a community project to understand security weaknesses or errors in code and vulnerabilities and create tools to help prevent them.

The MITRE Corporation operates CWE, and the National Cyber Security Division and US-CERT support it. CWE has over 600 categories detailing different types of vulnerabilities and bugs.

CWE strives to stop vulnerabilities and bugs by educating developers on building better products that aren’t susceptible to exploitation. Programmers can use CWE as a resource while writing code to prevent vulnerabilities during the development process. Security Orchestration, Automation, and Response (SOAR) tools use CWEs to build policies and workflows to automate remediation.

Anatomy of CWE

Common Weakness Enumerations (CWEs) are often well documented and contain detailed descriptions, examples, related Common Vulnerabilities and Exposures (CVEs), and relationships with similar vulnerabilities. For example, CWE-200 includes numerous simulated examples and a list of CVEs leveraging that vulnerability.

Security professionals can use CWE records to build proactive alerts and remediation from related attack patterns. Each CWE has a section listing different attack patterns with an associated vulnerability. Using this information, organizations can build custom detection methods around CWEs with their level of risk tolerance in mind.

The CWE makes it easy for developers and researchers to find common vulnerabilities across different languages, hardware, domains, and architectural concepts.

What Is CWE Compatibility?

The CWE compatibility program registers products or services as either CWE-Compatible or CWE-Effective. Compatible products assist organizations in assessing their applications for known weaknesses and flaws. For CWE compatibility qualification, the service product must meet the first four of the six requirements, while CWE-Effective products and services must meet all six.

  1. CWE Searchable - users may search elements using CWE identifiers.
  2. CWE Output - elements presented to users include, or are obtained associated CWE identifiers.
  3. Mapping Accuracy - security elements accurately link to the appropriate CWE identifiers.
  4. CWE Documentation - capability's documentation describes CWE, CWE compatibility, and CWE-related functionality.
  5. CWE Coverage - capability's documentation explicitly lists the CWE-IDs that the capability claims coverage and effectiveness against.
  6. CWE Test Results - for CWE-Effectiveness, the capability’s test results must show an assessment of software for CWEs, and the test results must appear on the CWE website. 

CWE vs. CVE

The primary difference between CWE and CVE is that CWEs highlight the vulnerabilities, not the specific instance of one within a product. 

For example, a CVE might detail a particular vulnerability within an operating system that allows attackers to execute code remotely. This CVE entry only details this vulnerability for a single product. 

A CWE outlines the vulnerability independent from any product. CWE has become a common language for discussing eliminating or mitigating software security weaknesses. Because developers have access to data regarding weaknesses early in product lifecycles, they can build products without vulnerabilities eliminating subsequent security issues. This allows developers to keep pace with rapid development lifecycles, build better products, release them faster to customers, minimize attack surfaces, and prevent more cyberattacks. 

A few examples of a CWE are below:

  • Out-of-bounds Write
  • Cross-site Scripting
  • Improper Input Validation
  • Missing Authentication for Critical Function

What is CWSS and How Does it Compare to CVSS?

The key difference between CWSS and CVSS is that while CVSS is reactive, CWSS is a proactive approach to cybersecurity. 

CVSS stands for Common Vulnerability Scoring System, numerically scoring vulnerabilities based on risk. Vulnerabilities are security flaws that attackers can exploit to gain access to a system.

Common Weakness Scoring System (CWSS) is a framework that documents software weaknesses so developers can minimize the number of bugs and vulnerabilities they introduce in a live system. 

The biggest difference between scoring systems is that the CWSS is proactive, whereas the CVSS is reactive. Both scoring systems can prevent vulnerabilities and prioritize the remediation of existing flaws when security teams use them together.

CWSS uses three criteria to help developers prioritize software-based weaknesses:

  • Attack Surface - the availability of the weakness
  • Base - the risk of weakness, degree of accuracy, and effectiveness of controls
  • Environmental - the parts of the weakness that are environmentally specific scoring for CWSS ranges between zero and 100.

CVSS uses similar metrics when calculating scores but works on a range of zero to ten using the following criteria:

  • Base - the characteristics of the security flaw
  • Temporal - a metric that changes with time due to external factors
  • Environmental - a metric that measures the impact of the vulnerability in your organization

While remediation teams can use both systems, their scores are not compatible. Even if the scores were normalized, their numbers would reflect differently across each system.

How HackerOne Can Help

HackerOne brings specialized skills and domain expertise to help security teams scale testing across attack surfaces. With the perspective of skilled experts, varied approaches, experience, and knowledge, ethical hackers submit vulnerabilities that traditional scanning tools miss. HackerOne’s vulnerability taxonomy includes a more complete weakness database based on the industry-standard CWE. Customers can rely on HackerOne data to deliver otherwise unavailable vulnerability intelligence and use that data to improve security strategies. Vulnerability reports are labeled with a weakness, either by the hacker at report submission or later by our Triage team. This allows organizations to first address the most critical vulnerabilities, mitigating cyber risk and providing greater protection for their attack surfaces. Contact us to learn more. 

 

Previous Article
Top 5 Takeaways from the 2021 Hacker-Powered Security Report: Industry Insights
Top 5 Takeaways from the 2021 Hacker-Powered Security Report: Industry Insights

For the fifth year in a row, HackerOne published a report that provides insights from the world’s largest d...

Next Article
Log4j Vulnerability Activity on the HackerOne Platform
Log4j Vulnerability Activity on the HackerOne Platform

December 17th Update:  Vulnerabilities in Log4j have been evolving over the course of this week since the ...