| Children Display |
|---|
This standard provides rules The CERT C Secure Coding Standard provides rules and recommendations (collectively called guidelines) for secure coding in the C programming language. The goal of these rules and recommendations is to develop safe, reliable, and secure systems, for example by eliminating undefined behaviors that can lead to undefined program behaviors and exploitable vulnerabilities. Conformance to the coding rules defined in this standard are necessary (but not sufficient) to ensure the safety, reliability, and security of software systems developed in the C programming language. It is also necessary, for example, to have a safe and secure design. Safety-critical systems typically have stricter requirements than are imposed by this coding standard, for example requiring that all memory be statically allocated. However, the application of this coding standard will result in high-quality systems that are reliable, robust, and resistant to attack.
Each guideline rule consists of a title, a description, and a noncompliant code exampleexamples and compliant solutions, as well as other information as described in How this Coding Standard is Organized. The title is a concise, but sometimes imprecise, description of the description of the guidelinerule. The description specifies the normative requirements of the rule or recommendation. The noncompliant code examples are examples of code that would constitute a violation of the guidelinerule. The accompanying compliant solutions demonstrate equivalent code that does not violate the guideline rule or any other rules or recommendations in this coding standard.
A well-documented and enforceable coding standard is an essential element of coding in the C programming language. Coding standards encourage programmers to follow a uniform set of rules determined by the requirements of the project and organization rather than by the programmer’s familiarityprogrammers’ individual preferences. Once established, these standards can be used as a metric to evaluate source code (using manual or automated processes).
CERT’s coding standards are being widely adopted by industry. Cisco Systems, Inc. , announced its adoption of the CERT C Secure Coding Standard as a baseline programming standard in its product development in October 2011 at Cisco’s annual SecCon conference. Recently, Oracle has integrated all of CERT’s secure coding standards into its existing Secure Coding Standards. Note that this secure coding standards. This adoption is the most recent step of a long collaboration: CERT and Oracle previously worked together in authoring The CERT ® Oracle Secure Coding Standard for Java (Addison-Wesley, 2011).
History
The idea of a CERT secure coding standard arose at the Spring 2006 meeting of the C Standards Committee (more formally, ISO/IEC JTC1/SC22/WG14) in Berlin, Germany [Seacord 2013a]. The C Standard is an authoritative document, but its audience is primarily compiler implementers, and, as noted by many, its language is obscure and often impenetrable. A secure coding standard would be targeted primarily toward C language programmers and would provide actionable guidance on how to code securely in the language.
The CERT C Secure Coding Standard was developed on the CERT Secure Coding wiki (http://www.securecoding.cert.org) following a community-based development process. Experts from the community, including members of the WG14 C Standards Committee, were invited to contribute and were provided with edit privileges on the wiki. Members of the community can register for a free account on the wiki and comment on the coding standards and the individual rules. Reviewers who provide high-quality comments are frequently extended edit privileges so that they can directly contribute to the development and evolution of the coding standard. Today, the CERT Secure Coding wiki has 1,576 registered contributors.
This wiki-based community development process has many advantages. Most important, it engages a broad group of experts to form a consensus opinion on the content of the rules. The main disadvantage of developing a secure coding standard on a wiki is that the content is constantly evolving. This instability may be acceptable if you want the latest information and are willing to entertain the possibility that a recent change has not yet been fully vetted. However, many software development organizations require a static set of rules and recommendations that they can adopt as requirements for their software development process. Toward this end, a stable snapshot of the CERT C Secure Coding Standard was produced after two and a half years of community development and published as The CERT® C Secure Coding Standard. With the production of the manuscript for the book in June 2008, version 1.0 (the book) and the wiki versions of the secure coding standard began to diverge. A second snapshot was taken in December 2013 and was published in April 2014 as The CERT® C Coding Standard, second edition. The wiki had become so comprehensive by this time that only the rules were included in the second edition of the book.
The CERT C secure coding guidelines were first reviewed by WG14 at the London meeting in April 2007 and again at the Kona, Hawaii, meeting in August 2007.
The topic of whether INCITS PL22.11 should submit the CERT C Secure Coding Standard to WG14 as a candidate for publication as a type 2 or type 3 technical report was discussed at the J11/U.S. TAG Meeting, April 15, 2008, as reported in the minutes. J11 is now Task Group PL22.11, Programming Language C, and this technical committee is the U.S. Technical Advisory Group to ISO/IEC JTC 1 SC22/WG14. A straw poll was taken on the question, “Who has time to work on this project?” for which the vote was 4 (has time) to 12 (has no time). Some of the feedback we received afterwards was that although the CERT C Secure Coding Standard was a strong set of guidelines that had been developed with input from many of the technical experts at WG14 and had been reviewed by WG14 on several occasions, WG14 was not normally in the business of “blessing” guidance to developers. However, WG14 was certainly in the business of defining normative requirements for tools such as compilers.
Armed with this knowledge, we proposed that WG14 establish a study group to consider the problem of producing analyzable secure coding guidelines for the C language. The study group first met on October 27, 2009. CERT contributed an automatically enforceable subset of the C secure coding rules to ISO/IEC for use in the standardization process.
Participants in the study group included analyzer vendors such as Coverity, Fortify, GammaTech, Gimpel, Klocwork, and LDRA; security experts; language experts; and consumers. A new work item to develop and publish ISO/IEC TS 17961, C Secure Coding Rules, was approved for WG14 in March 2012, and the study group concluded. Roberto Bagnara, the Italian National Body representative to WG 14, later joined the WG14 editorial committee. ISO/IEC TS 17961:2013(E), Information Technology—Programming Languages, Their Environments and System Software Interfaces—C Secure Coding Rules [ISO/IEC TS 17961:2013] was officially published in November 2013 and is available for purchase at the ISO store (http://www.iso.org/iso/catalogue_detail.htm?csnumber=61134).
ISO/IEC TS 17961 C Secure Coding Rules
VOID Rules versus Recommendations
This wiki contains ongoing updates of the standard between official published releases. If you are interested in contributing to the rules, create an account on the wiki and then request contributor privileges by sending a request to info@sei.cmu.edu.
The Secure Coding eNewsletter contains news from the CERT Secure Coding Initiative as well as summaries of recent updates to the standard rules. If you are interested in receiving updates directly, subscribe to the eNewsletter through our website or send a request to info@sei.cmu.edu .