Most projects are keen on improving the quality of their source code. Who doesn’t want better source code? Better from a quality perspective, better from a security perspective, and better from a maintenance perspective. These are three interesting perspectives on source code: quality, security, and maintenance, and there is some overlap between them.
Static analysis can help in all these scenarios, as you may well know.
When I think of quality, I think of crashes or unexpected behavior, which can be triggered by things such as null pointer dereferences and uninitialized variables. When I think of security, I typically think of memory issues, buffer overruns, and such. When I think of maintenance, I often think of coding styles such as MISRA, JSF, AUTOSAR, CERT, and the like.
Integrate Static Analysis into DevOps Pipelines
Static analysis needs to be integrated into your DevOps pipelines. Every merge request or pull request needs to be analyzed, and the findings need to be reviewed. CodeSecure CodeSonar make this really easy. Most CI/CD tools support a pipeline script, typically in YAML. In that script, you can specify how to run CodeSonar, what configuration to use (which is typically also stored in CI/CD), and where to run the analysis. Kubernetes and similar technologies can be used to set up a scalable, on-demand compute environment if needed, and the resulting findings can be stored on-premises or in the cloud, depending on your preference.
The question then becomes, what do we do with the findings? The answer to that question depends a bit on the industry that you are in. An automotive application that has to adhere to strict functional safety guidelines, as a failure could cause death or bodily harm, will need to make sure that all MISRA violations are addressed or deviations are properly documented. For less critical software, you may not want to take action on all static analysis findings. Not because the tool is wrong, but because the problem described in the finding cannot happen due to other protections.
Let’s look at an example resource leak in NGINX, a popular web/proxy/cache/balancing web server:
This error path is certainly possible, but unlikely, and the impact when it happens is minimal. Tools like CodeSonar will pop findings like this one up to the developer if this is a new warning. The developer can then respond to the finding in multiple ways:
- Fix the problem by making a code change. In this case, for example, closing the file descriptor fd before line 48 would fix the leak.
- Decide not to take action.
The latter is done by changing the ‘State’ of the finding to ‘Reviewed’ and the ‘Finding’ field to ‘No action’. This should usually be combined with a comment to indicate the reason why no action was taken. In this case, it could be a text like ‘Low chance of this happening, and the impact is negligible if it does’. Tools like CodeSonar call this an ‘annotation’. Annotations are stored with the finding in the tool’s datastore and remembered for eternity. Even if the line number changes by adding or removing code before line 48, the annotation stays.
Marking findings as reviewed is easy to do, either for a single finding or a set of findings.
The recommended workflow is that a merge shall not be approved if unreviewed findings exist. A typical workflow is the following:
- Create a new branch
- Work on a feature or a bug fix on the branch
- Create a merge request/pull request
- Review test results on the MR/PR, including static analysis
- Fix test failures
- Review all new static analysis warnings, either changing code (1), or marking them as reviewed (2)
- Merge work into the integration branch
Ideally, this workflow is automated in a CI/CD environment such as GitHub/GitLab/BitBucket or the like. This workflow makes it that the integration/release branch always has all findings reviewed and is ready to release. The findings that have been marked as ‘No action’ are, of course, still in the database and can be reviewed during a code/release meeting by either a team leader or by an independent security team.
Summary
Static analysis is a crucial tool for identifying crashes, memory issues, and maintenance issues and enforcing coding standards like MISRA, JSF, AUTOSAR, and CERT. CodeSecure CodeSonar is an easy-to-integrate tool that helps analyze and review static analysis findings in DevOps pipelines. Configuration scripts, such as those for GitHub or GitLab, specify how to run CodeSonar during repository actions. Kubernetes, and similar technologies to set up a scalable, on-demand compute environment, and the resulting findings can be stored on-premises or in the cloud.
Integrating into developers’ existing workflow is important for tool adoption and return on investment in tooling and training. Tools like CodeSonar integrate seamlessly into existing CI/CD pipelines to enable early detection of bugs and security vulnerabilities.
