^

Standards Compliance

Standards Compliance

Mastering CWE: Overview, top 25, and secure coding

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.

What is CWE?

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.

Who is MITRE in relation to CWE?

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).

What is the CWE Top 25?

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.

What is the difference between CWE and CVE?

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. 

What are CWSS and CVSS?

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.

How does NVD relate to CVE and CVSS?

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.

Is CWE a coding standard?

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. 

How is CWE organized?

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.

What are CWE weakness levels?

Each Common Weakness Enumeration weakness is assigned a level to indicate relative severity and hence help with prioritization. They are as follows: 

  • Class: Class-level weaknesses are concerned with the overall structure of the software system and its potential for security vulnerabilities. They are often broad and fundamental in nature. 
  • Base: Base-level weaknesses are more specific code flaws that can lead to security vulnerabilities, such as buffer overflows, and SQL injection.  
  • They typically easier to spot than class-level issues during code review or automated analysis. 

What is Common Weakness Enumeration Compatibility (or CWE Compatibility)?

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:

  • CWE Searchable – Users may search security elements using CWE identifiers
  • CWE Output – Security elements presented to users includes, or enables users to obtain, associated CWE identifiers
  • Mapping Accuracy – Security elements accurately link to the appropriate CWE identifiers
  • CWE Documentation – Capability’s documentation describes CWE, CWE compatibility, and how CWE-related functionality in the capability is used

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.

How can LDRA help with CWE compliance?

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.

How can LDRA static analysis help?

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.

How can LDRA dynamic analysis help?

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.  

Unit testing v integration testing

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 togetherperhaps with stubs at the outer reaches of the code under test. 

System testing v integration testing

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.  

CWE and dynamic testing

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 inCWE-912 (Hidden functionality) and related CWE weaknesses. 

More generally, benefits of dynamic analysis in this context include: 

  • Identifying actual vulnerabilities: The provision of information on how the software behaves during execution reveals different kinds of vulnerabilities as compared to static analysis. 
  • Testing for security misconfigurations: CWE weaknesses often include issues related to security misconfigurations. The LDRA tool suite can help to identify these misconfigurations by simulating various runtime conditions and configurations and then assessing how the application responds. 
  • Detecting runtime flaws: Many CWE weaknesses are related to memory management issues, such as buffer overflows or use-after-free vulnerabilities. The LDRA tool suite can help to flag execution-time anomalies, helping to pinpoint these types of runtime flaws. 
  • Assessing for Injection Attacks: Dynamic analysis can be used to simulate input attacks, like SQL injection. By monitoring how the application processes and responds to these attacks during runtime, the LDRA tool suite can help identify CWE weaknesses related to injection vulnerabilities. 
  • Evaluating Resilience to Attacks: CWE weaknesses often relate to the application’s resilience against various attacks. Dynamic analysis can be used to simulate different attack scenarios, with the TBextreme module being especially valuable in this regard. 

CWE compliance tools from LDRA

  • Some CWE weaknesses are best identified by means of static analysis. Dynamic analysis is more suited to others. The LDRA tool suiteprovides both
  • The TBvision component of the LDRA tool suite automates static source code checking. And it includes checks to ensure the avoidance of CWE listed weaknesses. It also supports dynamic system testing. 
  • The TBrun component of the LDRA tool suite supports unit test, integration test, System Integration Test (SIT), and system test. 
  • The TBextreme module supplements TBrun to provide an automated means of test vector generation. 
  • LDRArules is a cost-effective, stand-alone rules checker independent from the LDRA tool suite. It includes checks to ensure the avoidance of CWE listed weaknesses.
  • The TBsecure module enables CWE reporting. It identifies security vulnerabilities, including dynamic memory allocation concerns and other common programming errors.  When used with the LDRA tool suite, TBsecure produces additional code reviews capturing memory and security analysis results.
  • The TBexclude supplementary module provides for the efficient management of justified rule violations.
  • LDRA’s structural coverage analysis supports the recommendations of CWE-912 (Hidden functionality) and related CWE listed weaknesses. Related requirements traceability can be automated using the TBmanager component of the LDRA tool suite.

CWE compliance matrix

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.

Additional information

FREE 30 Day
TRIAL

Email Us

Email: info@ldra.com

Call Us

EMEA: +44 (0)151 649 9300

USA: +1 (855) 855 5372

INDIA: +91 80 4080 8707

Connect with LDRA