Key Message: CERT led the 7-year effort to publish an ISO/IEC technical specification containing 46 CERT-based secure coding rules for compilers and analyzers.
"An essential element of secure coding in the C programming language is a set of well-documented and enforceable coding rules. The rules specified in this Technical Specification apply to analyzers, including static analysis tools, and C language compiler vendors that wish to diagnose insecure code beyond the requirements of the language standard. All rules are meant to be enforceable by static analysis. The application of static analysis to security has been done in an ad hoc manner by different vendors, resulting in nonuniform coverage of significant security issues. This specification enumerates secure coding rules and requires analysis engines to diagnose violations of these rules as a matter of conformance to this specification." 
In this podcast, Robert Seacord, the leader of CERT’s Secure Coding Initiative, discusses the 7-year journey resulting in the selection of 46 coding rules, derived from the CERT C Secure Coding Standard, for this new technical specification.
Foundational work for this effort started in 2005, captured in the book Secure Coding in C and C++. The following CERT team events led to the development of the technical specification:
Technical Specification vs. Standard
Both can require millions of dollars in investment to comply so the C standards committee tends to be conservative.
Guidelines are often first published as technical specifications so that the affected industry has time to adjust, adapt, work with the content, identify problems, and provide feedback. Once this process is completed, technical specifications often become standards.
Structure and Objective
This specification is a collection of 46 coding rules. A conforming analyzer is required to issue a diagnostic if it detects a violation of any of these rules.
The C language standards have very little guidance on diagnosis. Warning and error messages are currently at the discretion of the compiler vendor so no consistent conformance is required.
The purpose of this specification is to raise the bar for conforming compilers and static analysis tools. It also provides users with a baseline that is guaranteed to find and diagnose the class of problems identified in the specification.
What a Vendor Needs to Do to Comply
ISO does not create conformance test suites that vendors can use to demonstrate that their tools conform with a particular standard or specification. This is typically left to the market and to vendors' self-assessment.
For this specification, CERT developed a conformance test suite called the Secure Coding Validation Suite that is available on GitHub. Vendors can use this suite to test their analyzer or compiler to ensure that they successfully diagnose the rule violations in the suite. It is distributed with a BSD-style license so it is publicly available.
Once vendors demonstrate that their tool conforms, they can make this claim.
How the 46 Coding Rules Were Selected
The team started with the rules in the CERT C secure coding standard. They made an initial determination of which rules could be analyzed. This content was provided to ISO and the study group was formed.
The study group spent three years discussing and reviewing candidate rules. Analyzer vendors argued to eliminate rules; users argued to keep rules. The following criteria were used to select and eliminate rules:
Potential paths forward include a period of time while the specification is used and improved, followed by a second edition or an ISO decision to move directly to a standard if this is warranted by the community feedback.
Coding Rule 5.30: Overflowing Signed Integers [intoflow]
From the specification:
Signed integer overflow is undefined behavior in the C language and users frequently misunderstand the consequences. One example of how this behavior manifests is as a buffer overflow.
The rule was contentious because it’s endemic in most C code that gets written today. For the specification, the rule is intended to diagnose signed integer operations that might trap as the result of one or more tainted inputs (those that are derived from untrusted external sources).
Coding Rule 5.22: Forming or Using Out-of-bounds Pointers or Array Subscripts [invptr]
From the specification:
This rule requires that out-of-bounds pointers or array subscripts be diagnosed – not solely when reading or writing memory at an invalid pointer but, more importantly, resulting from the formation of the pointer itself, which is undefined behavior in the C language. Violations of this rule can also result in buffer overflows.
Addressing Diagnosed Violations
The specification is written for analyzers and compilers. The CERT C secure coding standard is written for developers. It contains examples that illustrate both noncompliant and compliant code. The compliant solutions are meant to be safe, security implementations of the same functionality that developers can use in their software.Next Steps
The CERT team is still in contact with members of the study group and receiving incremental updates. The next set of expected announcements will be from vendors claiming full or limited compliance with the specification.
One member of the CERT team heads the U.S. delegation to the C standards committee, which is another source of coordination and feedback.
 ISO/IEC. "Information technology – Programming languages, their environments and system software interfaces – C secure coding rules." ISO/IEC TS 17961:2013(E), International Standards Organization, 2013.
Seacord, Robert. CERT C Secure Coding Standard. Addison-Wesley, 2008.
Seacord, Robert. Secure Coding in C and C++, Second Edition, Addison-Wesley, 2013.
CERT Secure Coding Initiative website
CERT Secure Coding Standards website
CERT podcast: "Cisco’s Adoption of CERT Secure Coding Standards," February 2012.
CERT podcast: "Mainstreaming Secure Coding Practices," March 2009.