Security
Headlines
HeadlinesLatestCVEs

Headline

Red Hat’s CWE journey

As the IT security landscape continues to evolve, so do the practices that IT organizations use to mitigate threats and maintain a more secure operating environment. Staying ahead of attackers and minimizing the cost of defense requires constant and appropriate reflection and analysis to improve processes and strategies. In this series, we explain what a CWE is, share our background on CWE collection, and explain how Red Hat has evolved our usage of CWEs over the past few years.

What is a CWE?

Common Weakness Enumeration (CWE) is a community-developed taxonomy of weaknesses maintained by

Red Hat Blog
#vulnerability#red_hat#perl#buffer_overflow

As the IT security landscape continues to evolve, so do the practices that IT organizations use to mitigate threats and maintain a more secure operating environment. Staying ahead of attackers and minimizing the cost of defense requires constant and appropriate reflection and analysis to improve processes and strategies. In this series, we explain what a CWE is, share our background on CWE collection, and explain how Red Hat has evolved our usage of CWEs over the past few years.

What is a CWE?

Common Weakness Enumeration (CWE) is a community-developed taxonomy of weaknesses maintained by MITRE. When it was released in 2006, it was focused on software weaknesses. Over time, CWE evolved to include weakness classification in additional categories like mobile applications and, most recently, hardware design flaws. The introduction of CWE provided a common language for software, hardware and general IT security practitioners to describe an underlying issue in a design that may lead to a vulnerability. This information has been a valuable resource for academia and industry professionals seeking to understand the product security landscape, and to observe changes in vulnerability trends.

CWE at Red Hat

Red Hat attained CWE compatibility at the end of 2012. At that time, we’d already been publishing CVEs and Red Hat Security Advisories (RHSA) for over a decade, so we started applying CWEs retroactively. Red Hat Product Security used that information almost immediately, and our first risk report covered the data we collected throughout 2013. We took advantage of CWE chains and composites to help clarify what it would take for an attacker to realize a vulnerability. This allowed customers to understand risks within their own environment. This collection and analysis of CWE data helps form Red Hat Product Security risk reports.

Making Red Hat CWE more impactful

Since 2013, however, Red Hat has adopted new CWE versions to make better use of CWE data in the vulnerability management process.

CWE-699 Software Development View adoption

Correct weakness selection helps understand a vulnerability’s root cause and potential consequences. From the beginning of 2022, Red Hat’s default CWE coverage has been based on the CWE-699 Software Development view, which we’ve found provides more accurate weakness selection for vulnerabilities most common in software vendors. While we changed our default view to Software Development, we continue to use all weaknesses from the CWE program. We prioritize the accuracy of the data we provide, so we continue to select weaknesses outside the scope of the Software Development View if they contribute to a more accurate selection.

Red Hat has also suggested several improvements to the CWE Software Development View. We proposed adding a common weakness in the software development CWE-416: Use After Free to the “Resource Management Errors” category. Additionally, we proposed adding the CWE-122: Heap-based Buffer Overflow weakness to the Memory Buffer Errors category and CWE-1325: Improperly Controlled Sequential Memory Allocation weakness to the Resource Management Errors. It’s expected that future CWE program versions will include these changes.

Reactive and proactive CWE usage

By structuring the CWE data based on the Software Development View, Red Hat can more efficiently describe the nature of vulnerabilities affecting our offerings. This enables us to perform a detailed analysis and gain deeper insight into the underlying causes of the issues. For example, we can group similar weaknesses based on the CWE Software Development View categories. That approach provides useful information about repeating the same type of weaknesses in specific products and their core components. This knowledge can then be used as input for a range of proactive security testing. We can also monitor what type of weaknesses categories usually lead to exploits, which can then be used as a factor to prioritize the patching process for affected components.

Some example CWE analyses are published by Red Hat in the yearly risk reports, such as the Red Hat Product Security risk report 2022. Having well-structured CWE data allows us, for example, to correlate the CWE weakness categories, based on the Software Development View, with the CVE severity for vulnerabilities.

Table 1. Top 3 CWE categories visible in the Critical and Important severity vulnerabilities

Table 2. Top 3 CWE categories visible in the Moderate and Low severity vulnerabilities

Based on these statistics, weaknesses related to Memory Buffer issues are the most frequent reasons for high-impact vulnerabilities (Critical and Important). This is in consonance with the fact that memory corruption flaws are more likely to lead to an arbitrary code execution, which is classified as a high severity issue based on Red Hat security ratings.
In contrast, low impact vulnerabilities are mostly caused by Resource Management Errors.

We can also correlate the same CWE categories with the public KEV exploits data, published by CISA. See the following list of categories sorted from most frequent to less.

Table 3. Top 5 CWE categories in correlation with the known exploits

Based on this report, the most frequent known exploits are related to the weaknesses from the Resource Management Errors and Data Neutralization Issues categories.

Compare this to the previous statistics. Even though Memory Buffer issues are usually correlated with high-priority vulnerabilities, these weaknesses are not the root cause for the most frequent exploits in the wild. This is a very useful observation for Red Hat and our customers.

CWE and continual improvement

As we transition to a shift-left approach and more proactive secure development process, we’re able to leverage CWE information collected at various stages of the process and create a feedback loop that benefits both upstream projects and downstream products.

We have an additional goal for ourselves as a CNA. We intend to obtain the CWE “Provider” status. To accomplish this goal, NIST’s CVMAP CWE audit requirements require at least a 95% accuracy on CWEs.

Red Hat contributes to CWE community

The CWE community consists of many groups working together to improve the entire CWE program usage. Red Hat is actively engaged in the governance with our membership on the CWE/CAPEC board as well as the Hardware CWE Special Interest Group, the REST API Working Group, and the User Experience Working Group, which recently published CWE user personas and stories of CWE users based on Red Hat suggestions.

CWE’s value lies in its emphasis on continuous security improvement when used as part of the feedback loop in a secure development lifecycle (SDL). Stay tuned for our next blog post on the Red Hat Security channel for more about CWEs, including how they’re used to discover areas for improvement in software practices. You can also follow us on Twitter @RedHatSecurity, and we encourage interested parties to become active members in the CWE community.

Red Hat Blog: Latest News

Managed Identity and Workload Identity support in Azure Red Hat OpenShift