To ensure that the source code conforms to this coding standard, it is necessary to have measures in place that check for rule violations. The most effective means of achieving this goal is to use one or more ISO/IEC TS 17961–conforming analyzers. Where a guideline cannot be checked by a tool, a manual review is required.
The Source Code Analysis Laboratory (SCALe) provides a means for evaluating the conformance of software systems against this and other coding standards. CERT coding standards provide a normative set of rules against which software systems can be evaluated. Conforming software systems should demonstrate improvements in the safety, reliability, and security over nonconforming systems.
The SCALe team at CERT analyzes a developer’s source code and provides a detailed report of findings to guide the code’s repair. After the developer has addressed these findings and the SCALe team determines that the product version conforms to the standard, CERT issues the developer a certificate and lists the system in a registry of conforming systems.
Conformance
Conformance to the CERT C Coding Standard requires that the code not contain any violations of the rules specified in this standard. If an exceptional condition is claimed, the exception must correspond to a predefined exceptional condition, and the application of this exception must be documented in the source code. Conformance with the recommendations on the wiki is not necessary to claim conformance with the CERT C Coding Standard. Conformance to the recommendations will, in many cases, make it easier to conform to the rules, eliminating many potential sources of defects
Software systems can be validated as conforming to the CERT C Secure Coding Standard. Source code analysis tools, included compilers and static analysis tools, can be certified as able to validate source code as conforming to this standard.
Source Code Compliance
The CERT C Secure Coding standard can be used as a measure of software security by determining the degree to which a software systems complies with the rules and recommendations in this standard. While compliance does not guarantee the absence of vulnerabilities (for example, vulnerabilities resulting from design flaws) it does guarantee the absence of coding errors that are commonly found to be the root causes of vulnerabilities.
The easiest way to validate code as compliant with the CERT C Secure Coding standard is to use a certified source code analysis tool.
Tool Selection and Validation
When choosing a compiler (which should be understood to include the linker), a C99 compliant compiler should be used whenever possible.
When choosing a source code analysis tool it is clearly desirable that the tool be able to enforce as many of the rules in this document as possible.
Compilers and source code analysis tools are trusted processes, meaning that a degree of reliance is placed on the output of the tools. Consequently, developers must ensure that this trust is not misplaced. Ideally this should be achieved by the tool supplier running appropriate validation tests. While it is possible to use a validation suite to test a compiler or source code analysis tools, no formal validation scheme exists at the time of publication of this document.
Levels
Rules and recommendations in this standard are classified into three levels (see Priority and Levels How this Coding Standard is Organized). Emphasis should be placed on conformance Level 1 (L1) rules. Software systems that have been validated as complying with all Level 1 rules are considered to be L1 Conformingconforming. Software systems can be assessed as L1, L2, or fully conforming, depending on the set of rules to which the system has been validated.
Rules vs. Recommendations
Conformance to secure coding rules must be demonstrated to claim compliance with this standard unless an exceptional condition exists. If an exceptional condition is claimed, the exception must correspond to a predefined exceptional condition and the application of this exception must be documented in the source code.
Compliance with recommendations is not necessary to claim compliance with this standard. It is possible, however, to claim compliance with recommendations (especially in cases in which compliance can be verified).
Deviation Procedure
It is recognized that in some instances it may be necessary to deviate from the rules given in this standard. For the rules to have authority it is necessary that a formal procedure be used to authorize these deviations rather than an individual programmer having discretion to deviate at will. The use of a deviation must be justified on the basis of both necessity and security. Rules that have high severity and/or a high likelihood require a more stringent process for agreeing to a deviation, than rules and recommendations with a low severity that are unlikely to result in a vulnerability.
Deviation Procedure
Strict adherence to all rules is unlikely and, consequently, deviations associated with specific rule violations are necessary. Deviations can be used in cases where a true-positive finding is uncontested as a rule violation but the code is nonetheless determined to be correct. An uncontested true-positive finding may be the result of a design or architecture feature of the software or may occur for a valid reason that was unanticipated by the coding standard. In this respect, the deviation procedure allows for the possibility that coding rules are overly strict [Seacord 2013].
Deviations are not granted for reasons of performance or usability. A software system that successfully passes conformance testing must not contain defects or exploitable vulnerabilities. Deviation requests are evaluated by the lead assessor, and if the developer can provide sufficient evidence that the deviation will not result in a vulnerability, the deviation request is accepted. Deviations are used infrequently because it is almost always easier to fix a coding error than it is to provide an argument that the coding error does not result in a vulnerability. 00. Introduction Priority and Levels