According to the website, “CWE™ is a community-developed list of software and hardware weakness types. It serves as a common language, a measuring stick for security tools, and as a baseline for weakness identification, mitigation, and prevention efforts.”
The Common Weakness Enumeration (CWE) list therefore covers a broad spectrum of hardware and software issues. It itemises over 800 programming errors, design errors, and architecture errors, any of which may lead to exploitable vulnerabilities.
CWE is an abbreviation for “Common Weakness Enumeration”. It is a community-developed list of software and hardware weakness types, covering the whole range of connected hardware and software. The list includes programming errors, design errors, and architecture errors, any of which may lead to exploitable vulnerabilities.
The common Weakness Enumeration database is a US governmental project, sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA). It is managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE).
The Common Weakness Enumeration (CWE) Top 25 Most Dangerous Software Weaknesses (CWE Top 25) is a subset of the full Common Weakness Enumeration list. It highlights the most common and critical issues experienced over the previous two calendar years.
The issues are commonplace generally because they are easy to find and exploit. They are dangerous because they allow bad actors to steal data, take over a system, or stop it from working.
CWE and CVE (Common Vulnerabilities and Exposures and NOT Common Vulnerability Enumeration!) are closely related, but subtly different. CWE lists types of software weaknesses, and hence provides a software vulnerability encyclopedic reference. CVE lists instances of vulnerabilities for specific applications.
The Common Weakness Scoring System (CWSS) is an open framework for the documentation of software weaknesses. It uses three metrics – Attack surface, Base, and Environmental – to help grade the weaknesses according to severity.
Similarly, the Common Vulnerability Scoring System (CVSS) is an open framework for communicating the characteristics and severity of instances of software vulnerabilities using Base, Temporal, and Environmental metrics to grade each of them.
The relationship between CWSS and CVSS is therefore analogous to that between CWE and CVE.
The National Vulnerability Database (NVD) is not directly related to CWE or CVE despite being complementary to them. It is managed by the National Institute of Standards and Technology (NIST), rather than MITRE.
However, the CVE list feeds into the National Vulnerability Database (NVD). It provides enhanced information above and beyond what’s in the CVE list, including CVSS Base metric scores.
Strictly speaking, there is no such thing as a CWE security coding standard. It is not directly comparable to (for example) the Cert C coding standard or the MISRA C++ Guidelines. However, the nature of many of the weaknesses it lists is such that software security tools like the LDRA tool suite can find them in source code. Different types of tools are available that can find listed weaknesses pertinent to operational systems.
The Common Weakness Enumeration database is organized based on abstractions of behaviour rather than on more pragmatic considerations such as where weaknesses might be found in source code. This gives rise to a tree-like structure that organises and groups the base-level weaknesses.
At the highest level, there are categories and pillars designed to group weaknesses. Strictly speaking, these are not weaknesses themselves but the fact that they are afforded entries in the CWE database sometimes gives rise to references to a “pillar weakness” or a “category weaknesses”. Pillars and categories work in combination. Pillars offer a high-level view, and categories provide a more specific breakdown within each pillar. Beneath these top-level entries, weaknesses are organized at various levels of abstraction.
Each Common Weakness Enumeration weakness is assigned a level to indicate relative severity and hence help with prioritization. They are as follows:
The Common Weakness Enumeration Compatibility and Effectiveness Program provides a mechanism for a product or service to be reviewed and registered as officially “CWE-Compatible” and “CWE-Effective”. The listed products and services in the CWE program enable development teams to identify and evaluate tools, training, and/or services pertinent to their development project.
CWE-compatible products and services must meet the following criteria:
As this CWE certificates illustrates the LDRA Testbed and TBvision components of the LDRA tool suite are listed as CWE‑Compatible, alongside the LDRArules point product.
The ability to statically analyse software efficiently with reference to the Common Weakness Enumeration list of vulnerabilities delivers tangible benefits to development teams in terms of code security, quality, and reduced time-to-deployment. Help is available from LDRA in the form of consultancy and the CWE security tools (sometimes called “CWE checkers”) found in both the LDRA tool suite and LDRArules.
Static analysis can be initiated to ensure Common Weakness Enumeration security compliance as code is developed, and automatically applied during unit, system, or integration testing to ensure that compliance achieved at the outset is not compromised throughout the software development life cycle. Pertinent CWE rules are completely integrated into LDRA tools for efficient checking within a familiar development environment.
LDRA static analysis tools locate and highlight areas of non-conformant code to aid documentation and modification. Extensive reports and graphical displays enhance understanding of the source code, facilitating improvements in line with Common Weakness Enumeration rules.
The use of static and dynamic analysis in tandem provides the opportunity to identify possible weaknesses both in the source code and in the executable.
The TBvision and TBrun components of the LDRA tool suite are examples of tools that support unit testing, integration testing, System Integration Testing (SIT) and system testing. Black box and white box testing are supported, where black box testing focuses on external behaviour and functionality, while white box testing also assesses the internal behaviour of the code under review.
The TBrun component of the LDRA tool suite supports both unit testing and integration testing. Unit testing focuses on isolated units of code often with external dependencies replaced by stubs, while integration testing evaluates how those units work together – perhaps with stubs at the outer reaches of the code under test.
The TBvision and TBrun components of the LDRA tool suite in tandem support integration testing, system integration testing, and system testing
Both integration testing and system testing are essential for ensuring the quality and reliability of a software system. Integration testing is performed to detect issues that arise when components are integrated.
System Integration Testing (SIT) extends that principle by focusing on the interactions and interfaces between subsystems within a larger software system.
System testing verifies that the complete software system meets its intended objectives.
Dynamic analysis is called out in some CWE weaknesses. For example, LDRA dynamic analysis tools facilitate structural coverage analysis to ensure that software “testedness” is measured and maintained, as recommended in CWE-912 (Hidden functionality) and related CWE weaknesses.
More generally, benefits of dynamic analysis in this context include:
LDRA offers complete transparency on compliance with every supported standard including Common Weakness Enumeration listed weaknesses. A compliance matrix shows exactly which rules are implemented.
A summary of LDRA static analysis tools’ compliance with the Common Weakness Enumeration listed weaknesses can be found below and the detailed matrix can be downloaded by registered users.
Note that the CWE list includes a wider range of vulnerability types. This matrix excludes those that concern libraries, languages that are not supported by LDRA, and issues that are not statically checkable.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707