This article describes the relationship between the Common Weakness Enumeration (CWE) and CERT Secure Coding Standards.
Common Weakness Enumeration
The Common Weakness Enumeration (CWE) is a unified, measurable set of software weaknesses that enables the effective discussion, description, selection, and use of software security tools and" services that can find these weaknesses in source code and operational systems. The CWE also enables better understanding and management of software weaknesses related to architecture and design. It enumerates design and architectural weaknesses as well as low-level coding and design errors.
CERT Secure Coding Standards
CERT1, part of Carnegie Mellon University's Software Engineering Institute, is developing secure coding standards for commonly used programming languages such as C, C++, and Java through a broad-based community effort that includes members of the software development and software security communities. CERT secure coding standards include guidelines for avoiding coding and implementation errors as well as low-level design errors.
Well-documented and enforceable coding standards are essential to secure software development. Coding standards encourage programmers to follow a uniform set of rules and guidelines determined by the requirements of the project and organization, not by the programmer’s familiarity or preference. Once established, these standards can be used as a metric to evaluate source code (using manual or automated processes) for compliance with the standard.
The CWE and the CERT secure coding standards perform separate but mutually supportive roles. Simply stated, the CWE provides a comprehensive repository of known weaknesses, while CERT secure coding standards identify insecure coding constructs that, if present in code, could expose a weakness or vulnerability in the software. Not all weaknesses enumerated in the CWE are present in any particular secure coding standard because not all weaknesses are present in each language and because the CWE also includes high-level design issues. Not all CERT secure coding guidelines are mapped directly to weaknesses in the CWE because some coding errors can manifest in ways that do not directly correlate to any given weakness. Both tools are necessary in evaluating the security and safety of software systems.
Figure 1 illustrates the software development aspect of the software assurance ecosystem supported by the CWE and the CERT secure coding standards. Related views could be constructed to show how these tools support acquisition, education, and research.
Figure 1. The CERT-CWE landscape
The CWE contains multiple views, the most important of which are the full dictionary view, the development view, and the research view. The CWE-734 view enumerates weaknesses addressed by the CERT C Secure Coding Standard [Seacord 2009] and includes 103 out of the 799 total CWEs. Developers can fully or partially prevent the weaknesses identified in this view if they adhere to that standard. Because not all CERT guidelines map to specific weaknesses, the CWE-734 view is incomplete.
In addition, developers can use a CWE coverage graph to determine which weaknesses are not directly addressed by the standard. Making that determination can help identify and resolve remaining gaps in training, tool acquisition, and other approaches for reducing software weaknesses.
Guidelines in the CERT C Secure Coding Standard are cross-referenced with CWE entries. These cross-references are created only for guidelines that, if violated, directly contribute to the referenced weakness. Similar mappings will be created for other CERT coding standards once the coding standards are completed.
Seacord, Robert C. CERT C Secure Coding Standard. Addison-Wesley Professional, 2009. www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard
- 1. CERT is registered in the U.S Patent and Trademark Office by Carnegie Mellon University
Copyright © Carnegie Mellon University 2005-2012.
This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at email@example.com.
The Build Security In (BSI) portal is sponsored by the U.S. Department of Homeland Security (DHS), National Cyber Security Division. The Software Engineering Institute (SEI) develops and operates BSI. DHS funding supports the publishing of all site content.
THIS MATERIAL OF CARNEGIE MELLON UNIVERSITY AND ITS SOFTWARE ENGINEERING INSTITUTE IS FURNISHED ON AN “AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.