In the past Red Hat Product Security assigned weakness IDs only to vulnerabilities that meet certain criteria, more precisely, only vulnerabilities with CVSS score higher than 7. Since the number of incoming vulnerabilities was high, this filtering allowed us to focus on vulnerabilities that matter most. However, it also makes statistics incomplete, missing low and moderate vulnerabilities.

In the previous year we started assigning weakness IDs to almost all vulnerabilities, greatly increasing the quantity of data used to generate statistics. This was a big commitment time-wise, but resulted in 13 times more vulnerabilities with assigned weakness IDs in 2014 than the year before. There are a few exceptions – for some vulnerabilities there are not enough information available to decide the types of weaknesses. These almost always come from big upstream vendors. For this reason bugs in mysql or OpenJDK do not have weaknesses assigned and are excluded from the CWE statistics. With the exceptions mentioned, there are always at least references to commits that fix the vulnerability available, so it is possible to assign correct weakness data to vulnerabilities in any open source project.

Part of using Common Weakness Enumeration (CWE) at Red Hat is CWE Coverage – a subset of weaknesses that we use to classify vulnerabilities. As everyone can notice after scrolling through the CWE list there are a lot of weaknesses that are very similar or describe the same issue in varying level of detail. This means different people can assign different weaknesses to the same vulnerability, a very undesirable outcome. Furthermore, this may skew resulting statistics, as vulnerabilities of the same nature may be described by different weaknesses. To counter these effects, Red Hat keeps CWE coverage, a subset of weaknesses we use, to prevent both. The coverage should contain weaknesses with similar level of detail (Weakness Base) and should not contain multiple overlapping weaknesses. However there is a possibility that a vulnerability would not fit into any of the weaknesses in our coverage and for this reason the coverage is regularly updated.

Maintenance of CWE coverage has been tied with the release of new CWE revisions by MITRE in past. Since we started assigning weakness IDs to much larger number of vulnerabilities we also gathered weaknesses missing in the coverage more quickly. Therefore the coverage has been updated and the changes are now included in the statistics. Current revision of Red Hat`s CWE Coverage can be found on the Customer Portal.

Apart from adding missing weaknesses we also removed a number of unused or unsuitable weaknesses. The first version of coverage was based on CWE Cross-Section maintained as view by MITRE. The CWE Cross-Section represents a subset of weaknesses at the abstraction level most useful for general audiences. While this was a good starting point, it quickly became evident that the Cross-Section has numerous deficiencies. Some of the most common weaknesses are not included, for example CWE-611 Improper Restriction of XML External Entity Reference (‘XXE’), which ranked as 10th most common weakness in our statistics for 2014. On the other hand, we have not included considerable number of weaknesses that were not relevant in open source, for example CWE-546 Suspicious Comment. After these changes current revision of the coverage has little in common with CWE Cross-Section, but represents structure of weaknesses usually specific to open source projects well.

Last but not least, all CWE related data are kept public and statistics (even for our internal use) are generated only from publicly available data.The weakness ID is stored in whiteboard of a vulnerability in bugzilla. This is rather cryptic format and requires tooling to get the statistics into a format that can be processed. Therefore, we are currently investigating the best way how to make the statistics available online for wider audience.