The static code analysis tool C-STAT is completely integrated in the IAR Embedded Workbench IDE and provides an easy way to make sure your application complies with the automotive coding standards defined by MISRA (the Motor Industry Software Reliability Association). But the tool can ensure good code quality for all types of applications. In addition to the MISRA rulesets, it contains hundreds of checks derived from CWE and CERT, as well as checks specific to C-STAT.
So C-STAT can help you avoid certain code constructs pinpointed by MISRA, CERT or the CWE initiative as being dangerous. But who are behind these initiatives and why should you care about adhering to them?
The MISRA-C ruleset started out as an initiative by the Motor Industry Software Reliability Association in the UK and was aimed solely at automotive software. Over the years, the MISRA-C rules has spread over the world and into other industry segments, and the ruleset is now the most widely used C subset in the embedded industry.
MISRA-C:2012, which is the latest version, contains 143 rules and 16 so called directives. The rules are classified as mandatory, required or advisory and cover such areas as avoiding possible compiler differences like integer size, avoiding using functions and constructs that are prone to failure, limiting code complexity, and ensuring that the code is maintainable for example by using naming conventions and commenting.
CWE (the Common Weakness Enumeration) is a community-developed dictionary of software weaknesses and vulnerabilities. Each entry includes an ID number, descriptions of the weakness and its potential consequences as well as potential mitigations, code samples, taxonomies and references. It is intended to help gain a better understanding and management of software weaknesses as well as to enable more effective selection and use of software security tools and services that can find these weaknesses. The project is sponsored by the MITRE Corporation, which is an American non-profit organization that operates multiple federally funded research and development centers.
So what is a “software weakness”? MITRE defines it as flaws, faults, bugs, vulnerabilities, and other errors in software implementation, code, design, or architecture that if left unaddressed could result in systems and networks being vulnerable to attack.
Not all of the listed weaknesses are relevant for embedded systems, but if you take a look at the CWE/SANS top 25 list of the most dangerous software errors there a number of them that you should definitely be aware of. The list for example includes Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'), Incorrect Calculation of Buffer Size, Uncontrolled Format String and Integer Overflow or Wraparound. And that just for the top 25, the complete dictionary has more than a thousand entries.
The CERT C/C++ Secure Coding Standards provide rules and recommendations for secure coding in the C/C++ programming languages. The standards are published by the CERT Division at the Software Engineering Institute (SEI) operated by Carnegie Mellon University. SEI is a research and development center primarily funded by the U.S. Department of Defense and the Department of Homeland Security.
CERT provides rulesets for secure coding in C as well as in C++. Each guideline consists of a title, a description, a non-compliant code example and examples of compliant solutions. The standards include guidelines for avoiding coding and implementation errors, as well as low-level design errors. The aim of the standards is to eliminate insecure coding practices and undefined behaviors that can lead to exploitable vulnerabilities.
The rules in the different standards overlap and complement each other. CWE provides a rundown of known weaknesses in software, while the CERT and MISRA standards identify coding constructs that could potentially expose weaknesses in the software. No coding standard includes all listings in CWE since not all of them are present in one coding language. Also, some of the weaknesses are related to high-level design issues. In parallel, not all the coding guidelines defined by MISRA or CERT can be mapped to entries in CWE since a problematic coding construct does not always correlate directly to a specific listed weakness. However, CERT guidelines do contain references to CWE entries where applicable.
Because of their mutually supportive roles it is wise, or even necessary, to consult all these instances to make sure that the software is safe and secure.
Why not use a tool to do it for you? C-STAT performs a number of security checks for compliance with the MISRA rulesets and rules as defined by the CERT C/C++ Secure Coding Standards as well as for a number of weaknesses as defined by CWE. To further simplify compliance tasks, C-STAT provides output that is consistent with the naming of weaknesses in CWE.
All checks in C-STAT are thoroughly documented with references to the corresponding entries in CWE and in the MISRA and CERT standards. You can select to check your code against rulesets as well as against individual rules.
Description of a C-STAT check for array out of bounds with references to the relevant CWE entries and the corresponding rules in the CERT and MISRA standards.
C-STAT is fully integrated into the IDE and is as simple to use as the regular build tools. No need for complex tool setup and no struggle with language support and general build issues. C-STAT supports approximately 250 unique checks, which are mapped to approximately 600 rules from different coding standards and rulesets, including rules from CERT and the CWE initiative, as well as MISRA C:2012, MISRA C++:2008 and MISRA C:2004.
The C-STAT standards checks ruleset contains checks mapping to hundreds of issues covered by CWE and CERT C/C++.
C-STAT supports C and C++, including all language constructs that are specific to IAR Embedded Workbench, and can be enabled in the build toolchain to simplify development of code that interfaces directly with hardware. The static analysis is based on leading edge technology to identify code patterns ranging from merely suspicious to plain wrong, including things like buffer overflows, arithmetic and conversion issues and temporal properties of heap management etc.
For checks that benefits from cross module analysis, C-STAT will propagate information across module boundaries. C-STAT can also be run in multi-file compilation mode, where the whole source will be analyzed as one module to increase the analysis precision of certain checks.
In conclusion, C-STAT lets you take full control of your code and improve code quality during development. By including code quality checks in the daily work of each developer, companies can find issues early and minimize the impact on the finished product as well as on the project timeline.
Watch this video to see a short introduction of our static analysis tool C-STAT.