Static Code Analysis - CERT C Secure Code Checking
Contents
The high-level C code written for an embedded software project can sometimes be as varied, in style and implementation, as the developer writing it. From an organization's perspective, it is often preferable – if not required – to write code that follows a set of defined coding guidelines. Style itself is not such an issue – a coding template can be set up to constrain the formatting look and feel. Far more important, is the security of that code. Depending on the organization and/or where the code is to be deployed, it may be a necessary requirement that such code be resilient to external attack by parties attempting to exploit any weaknesses or programmatic errors contained within.
To aid you in writing safe, quality C code, Altium Designer includes the ability to perform post-compilation static code analysis, testing against rules and/or recommendations provided by the CERT C Programming Language Secure Coding Standard. The coding checks implemented by this standard give you an edge when developing your software, helping you to deliver C source code containing fewer programming errors that result in exploitable vulnerabilities. The result is code of a much higher quality and that is more secure/robust in its deployed role within the marketed electronic product.
CERT C secure code checking brings an invaluable addition to your static code analysis arsenal, alongside MISRA-C checking. Just as a writer has the reassurance of spelling and grammar checkers to produce high-quality documentation, think of these as intelligent 'code-checkers' for embedded developers working with the C programming language and you get the picture!
It is important to note that using the static code analysis feature is intended to help detect common programming errors that can lead to insecure areas of code, or code that can exhibit undefined behavior. In simple terms, the analysis is analogous to ERC of source schematics or DRC on a PCB. It simply validates the code against all enabled rules/recommendations of the CERT standard. Passing these rules/recommendations will result in code that is far more secure, but passing these rules/recommendations is not a sole indicator that the resulting software system is 'cast-iron' (or impenetrable) in its security.
Enabling Code Checking
Code checking is enabled from the Compiler Options tab of the Project Options dialog for the embedded project (Project»Project Options). Click to expand the C Compiler entry on the left-hand side, then click on the CERT C Secure Code Checking entry.
Use the drop-down field on the right-hand side of the tab to choose whether to enable checking and, if enabled, the level of checking. The following options are available:
Disabled– turn off code checking.
Supported rules only– check against only the rule-level code practices defined as part of the CERT C Programming Language Secure Coding Standard.
Supported recommendations and rules– check against both the rule-level and recommendation-level code practices defined as part of the CERT C Programming Language Secure Coding Standard.
Custom configuration– allows you to specify a customized set of rule-level and/or recommendation-level code practices to check against, from those defined as part of the CERT C Programming Language Secure Coding Standard.
When the Custom configuration entry is chosen, you will have access to the Custom Configuration sub-page. The page lists the available rule and recommendations by section (within the standard). Enable/disable which rules/recommendations you wish to include as part of the static code analysis.
CERT C Secure Code Checking is applied to both C source (*.c) and C header (*.h) files.
Interrogating Violations
Any violation of an enabled CERT rule or recommendation check will appear as an entry in the Messages panel. Simply double-click on an entry to cross-probe to the line of code in the affected C source document or header file. The line of code will be highlighted and the cursor positioned at the offending point.
Supported Rules
The following table summarizes the rule-level code practices from the CERT C Programming Language Secure Coding Standard, that are available for use in the static code analysis.
In the following table, the rule identifier reflects that seen in the Project Options dialog. In the CERT documentation, a -C suffix is used to reflect that the rule is part of the CERT C Programming Language Secure Coding Standard, as various other standards exist dealing with other programming languages.
Rule Identifier | Section of Standard | Rule Description |
|---|---|---|
DCL30 | Declarations and Initialization | Declare objects with appropriate storage durations |
DCL31 | Declarations and Initialization | Declare identifiers before using them |
DCL32 | Declarations and Initialization | Guarantee that mutually visible identifiers are unique |
DCL35 | Declarations and Initialization | Do not invoke a function using a type that does not match the function definition |
EXP30 | Expressions | Do not depend on order of evaluation between sequence points |
EXP32 | Expressions | Do not access a volatile object through a non-volatile reference |
EXP33 | Expressions | Do not reference uninitialized memory |
EXP34 | Expressions | Ensure a null pointer is not dereferenced |
EXP37 | Expressions | Call functions with the arguments intended by the API |
EXP38 | Expressions | Do not call |
INT30 | Integers | Ensure that unsigned integer operations do not wrap |
INT34 | Integers | Do not shift a negative number of bits or more bits than exist in the operand |
INT35 | Integers | Evaluate integer expressions in a larger size before comparing or assigning to that size |
FLP30 | Floating Point | Do not use floating point variables as loop counters |
FLP35 | Floating Point | Take granularity into account when comparing floating point values |
FLP36 | Floating Point | Beware of precision loss when converting integral types to floating point |
ARR34 | Arrays | Ensure that array types in expressions are compatible |
ARR35 | Arrays | Do not allow loops to iterate beyond the end of an array |
STR30 | Characters and Strings | Do not attempt to modify string literals |
STR33 | Characters and Strings | Size wide character strings correctly |
STR34 | Characters and Strings | Cast characters to unsigned types before converting to larger integer sizes |
STR36 | Characters and Strings | Do not specify the bound of a character array initialized with a string literal |
MEM30 | Memory Management | Do not access freed memory |
MEM31 | Memory Management | Free dynamically-allocated memory exactly once |
MEM32 | Memory Management | Detect and handle memory allocation errors |
MEM33 | Memory Management | Use the correct syntax for flexible array members |
MEM34 | Memory Management | Only free memory allocated dynamically |
MEM35 | Memory Management | Allocate sufficient memory for an object |
ENV32 | Environment | All |
SIG30 | Signals | Call only asynchronous-safe functions within signal handlers |
SIG32 | Signals | Do not call |
MSC32 | Miscellaneous | Ensure your random number generator is properly seeded |
Supported Recommendations
The following table summarizes the recommendation-level code practices from the CERT C Programming Language Secure Coding Standard, that are available for use in the static code analysis.
In the following table, the recommendation identifier reflects that seen in the Project Options dialog. In the CERT documentation, a -C suffix is used to reflect that the recommendation is part of the CERT C Programming Language Secure Coding Standard, as various other standards exist dealing with other programming languages.
Recommendation Identifier | Section of Standard | Recommendation Description |
|---|---|---|
PRE01 | Preprocessor | Use parentheses within macros around parameter names |
PRE02 | Preprocessor | Macro replacement lists should be parenthesized |
PRE10 | Preprocessor | Wrap multi-statement macros in a do-while loop |
PRE11 | Preprocessor | Do not conclude a single statement macro definition with a semi-colon |
EXP01 | Expressions | Do not take the size of a pointer to determine the size of the pointed-to type |
EXP12 | Expressions | Do not ignore values returned by functions |
ARR01 | Arrays | Do not apply the |
MEM00 | Memory Management | Allocate and free memory in the same module, at the same level of abstraction |
MEM08 | Memory Management | Use |
Further Information
Detailed information on the CERT C Programming Language Secure Coding Standard can be found on the CERT Wiki.