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 CWE list aims to cover weaknesses throughout the different phases of software development and across many programming languages. These weaknesses are categorized and organized into views that can help software developers quickly find weaknesses based on specific criteria or use cases.
CWE allows developers to identify and minimize weaknesses as early in the lifecycle as possible, improving its overall security and helping to prevent vulnerabilities.
As the above implies, 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 illustration above – extracted from the CWE website – reflects the fact that many of the weaknesses it lists are such that language-specific software security tools like the LDRA tool suite can find them in source code. It is therefore often referred to as the “CWE coding standard” for convenience.
Adherence to the CWE “coding standard” brings several key benefits:
Enhanced Security: By addressing common software weaknesses identified in the CWE coding standard, organizations can significantly enhance the security of their source code. This minimizes the likelihood of successful cyberattacks, data breaches, and other security failures, protecting sensitive information and preserving customer trust.
Reduced Risk: Proactively addressing known vulnerabilities helps mitigate risks associated with software weaknesses. This reduces the likelihood of financial losses, regulatory penalties, reputational damage, and other negative consequences resulting from security breaches or non-compliance with industry standards and regulations.
Cost Savings: Addressing vulnerabilities early in the software development lifecycle is generally more cost-effective than fixing them after deployment. By implementing CWE and conducting thorough security testing, organizations can identify and ultimately fix any vulnerabilities before they become too costly to resolve or cause disruptions to business operations.
Compliance Requirements: Many regulatory and industry standards mandate the implementation of security best practices, including addressing common software weaknesses. Adhering to CWE can help organizations demonstrate compliance with regulations such as GDPR, HIPAA, PCI DSS, and others, avoiding potential fines, legal issues, and loss of business opportunities.
Improved Customer Satisfaction: Building secure software products instils confidence in customers and stakeholders, leading to improved satisfaction and customer loyalty. Demonstrating a commitment to security by implementing CWE can give businesses a competitive advantage in the marketplace and attract new customers who prioritize security and privacy.
Faster Time to Market: By incorporating software security checking into the development process from the beginning, businesses can avoid delays caused by last-minute security fixes. This enables a faster time-to-market for products and services, allowing businesses to capitalize on market opportunities and gain a competitive edge.
Protection of Intellectual Property: Addressing vulnerabilities helps protect intellectual property and proprietary information from unauthorized access, theft, or exploitation. This safeguards valuable assets and prevents competitors or malicious actors from gaining access to sensitive data or compromising the organization’s competitive advantage.
Overall, implementing the CWE standard aligns with sound business practices, promotes a culture of software security, and contributes to the long-term success and resilience of organizations in an increasingly digitally connected world.
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.
The latest version of the CWE Top 25 does not list 25 rules – but it retains the “top 25” moniker irrespective! Some of the rules are enforceable by means of automated tools such as those provided by LDRA, including the examples listed below. Others are not.
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 encyclopaedic reference. CVE lists instances of vulnerabilities for specific applications.
NIST 500-268 is a static analysis implementation standard that calls out specific CWE entries relevant to C and C++. Although it dates from 2011, its focus on issues such as stack and heap safety, exceptions, and range-based errors (e.g. buffer overflows and underflows) make it just as relevant today.
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.
CWE 4.14 is the current version of CWE. It lists a total of 938 weaknesses.
The goal of the CWE list is to offer clear and concise definitions for each type of common weakness, helping the community grasp and tackle vulnerabilities in software and hardware more effectively. This initiative is dynamic, regularly improved and enhanced through input and feedback from users.
What are the differences between CWE 3.4 and CWE 4.14?
The primary difference between CWE 3.4 and CWE 4.14 is that the latter includes a number of new, additional weaknesses.
According to the CWE website, CWE 3.4.1 lists a total of 808 weaknesses while CWE 4.0 (starting at CWE-1189) lists a total of 839 weaknesses.
CWE 4.14 (up to CWE-1424) lists a total of 938 weaknesses, implying that it lists 130 more weaknesses than CWE 4.0.
However, of these 130 new weaknesses, only 3 are applicable to C/C++ – namely CWE-1325, CWE-1335, and CWE-1341:
Along with new weaknesses, other enhancements in the new version include refinement and clarification to the CWE list. These reflect the ongoing efforts to improve the Common Weakness Enumeration and to provide a more comprehensive and effective resource for addressing software and hardware vulnerabilities.
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:
These are typically easier to spot than class-level issues during code review or automated analysis.
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.
More specifically, LDRA tools can help in the following ways:
By leveraging LDRA’s expertise and tool suite for static and dynamic analysis, organizations can effectively apply the CWE standard, strengthen the security of their software, and mitigate the risk of security breaches and compliance violations.
CWE rules include some of the most common and most exploitable software weaknesses that developers and security professionals need to address before a final release. LDRA’s tool suite can play a crucial role in identifying and mitigating these weaknesses throughout the software development lifecycle. They include:
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 Common Weakness Enumeration 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.
For many CWE rules, some parts can be implemented automatically while other parts require some manual review. Such rules are listed as partially implemented. Almost all CWE rules related to C/C++ are implemented to a greater or lesser degree.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707