What is CERT C?
CERT C is a set of guidelines for software developers and is used for secure coding in C language. It was developed on the CERT community wiki following a community based development process, with the first edition released in 2008 and the second edition released in 2014.
The guidelines, for example, help eliminate constructs with undefined behavior that can lead to non-deterministic runtime behavior and expose security weaknesses. Sounds familiar to MISRA, doesn’t it?
There is overlap since both guidelines aim to address the underlying nondeterministic behavior, but differences arise because MISRA C is focused on safety and reliability, while CERT C focuses on security.
Please refer to the following CERT C wiki section for a comparison and applicability of various guidelines such as MISRA C, CERT C, CWE, etc.
CERT C guidelines are written in the form of rules and recommendations and are similar to updates to the MISRA C coding rules, i.e. MISRA-C: 2012. The primary criterion used to label a guideline as a CERT C rule is: determine whether the guideline is statically enforceable. These rules can also be checked manually, but this is not practical and therefore CERT C recommends use of static analysis tools. There is also a deviation mechanism in place to justify violations.
Compliance with CERT C using Polyspace
Static analysis tools greatly simplify compliance with the CERT C standard for the reasons mentioned above, in addition to the automation as part of your development and build toolchain.
Furthermore, Polyspace Bug Finder can detect several security related defects, such as tainted data, in addition to the underlying software weaknesses such as static and dynamic memory defects, numerical and data flow defects, etc. These underlying defects are the root cause of security exploits.
Review the complete list of the categories of Polyspace Bug Finder defect checks.
These bug finder defects have been mapped to the CERT C rules (as shown above), allowing the user to identify which rules have been violated. These violations can then be reviewed to estimate their impact on security. For example, you can use the scoring priority accorded to each of the rules depending on the severity, likelihood for an exploit, and the remediation cost.
In addition to the CERT C rules, Polyspace can also check for compliance to some CERT C recommendations, leveraging the deep semantic analysis capabilities of its analysis engine.
Polyspace Code Prover can also prove that a subset of the CERT C rules are never violated under any run time condition for your application; this is done by verifying the run time behavior without any false negatives. This is important because a false negative implies failure to report a real flaw in the code (which is usually regarded as the most serious analysis error), and may leave the user with a false sense of security.
Buffer overflow violates CERT C rule ARR30-C
Refer to the following documentation link for the mapping between Polyspace checks, CERT C rules, and recommendations.
