What is the Connection Between CERT & CWE?

2021-08-26 | By Tan Rahman

Up to 90% of software security problems are caused by coding errors, which is why secure coding practices and secure coding standards are essential. We’ll look at two of them in the post, CWE and CERT, and explain the relationship between them.

Common Weakness Enumeration

“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.” Names and descriptions are provided so that software analysis tools can be used to identify the coding errors and defects that cause them. The CWE also allows developers to better design and architect their applications. It provides an enumeration for design and architectural weaknesses, as well as low-level coding and design errors.


CERT Secure Coding Standards

The Carnegie Mellon Software Engineering Institute’s Computer Emergency Response Team (CERT) develops coding standards for C, C++ and Java. This is achieved by contributions by a wide ranging software engineering communities across the globe. These standards are well documented and designed to be enforced within software development teams to ensure that high quality code and secure code is created. By following a uniform set of rules, software developers can work to guidelines developed by an organisation rather than their own personal preferences which may not be fully tried and tested. Once the standards have been established within an organisation, they can be used to quantitatively evaluate the quality and vulnerabilities in source code. This can be achieved through manual code reviews or automated ones using code analysis tools.

CERT secure coding standards include guidelines for avoiding coding and implementation errors, as well as low-level design errors.


CERT-CWE Relationship

They both provide coding standards but approach the issues in slightly different ways. They are mutually supportive of each other. The CWE is a database of known security weaknesses in software applications. CERT, on the other hand, provides guidelines for writing code and to identify insecure coding constructs. The CWE covers a wide range of programming languages so extends beyond say, just the CERT C rules, because not all weaknesses are found in just one language. In addition, CWE includes high-level design problems that can lead to vulnerabilities. Conversely, not all CERT rules are mapped to a CWE weakness, as coding errors can cause issues which are not necessarily related to a security concern. Hence, the use of both standards gives a greater level of security and safety for application development.


CERT-CWE Mappings

By following the rules set out in CERT, developers can directly address some of the weaknesses identified in CWE. The ability to map these connections is important to address organizational coding requirements for security. For example, developers can fully or partially prevent the weaknesses identified in CWE-734 if they adhere to the CERT coding standard. CWE-734 includes 103 out of the 799 total CWEs for CERT C. Static code analysis tools provide much of the mapping according to the number of CERT rules they cover.

Guidelines in the CERT C Secure Coding Standard are cross-referenced with CWE entries. These cross-references are only created for guidelines which, if violated, directly contribute to the referenced weakness.

To summarise, CWE provides a rundown of known weaknesses in software, while the CERT standards identify coding constructs that could potentially expose weaknesses in the software. Because of their mutually supportive roles, it is wise, or even necessary, to consult all these instances to make sure that the software is safe and secure. Xcalscan provides many of the mappings required for developers to create secure code.


Click here to find out how Xcalscan incorporates CERT and CWE standards for static code analysis ensuring best practice and secure coding.

You might be interested in

seL4 Summit 2022 Recap

2022-11-01 | By Yuning Liang

As seL4 moves onto automotive applications, having industry standards will be a big step forward for mass adoption. Iso 26262 ASIL-D is well known...

read the story

OWASP #5 Broken Access Control

2021-10-19 | By Jason Lu

In the OWASP Top Ten list, the number 5 vulnerability is Broken Access Control. This is concerned with how web applications grant systems access to...

read the story