Go back to blog listing

Accelerating MISRA, CERT Compliance with Dedicated Reporting Workflows

gdpr-static-analysis

Introducing a coding standard like MISRA or CERT into the developer’s daily workflow can be time-consuming and intrusive. In this post, we look at how to accelerate compliance with tool automation, dedicated reporting, and workflow management.

During active software development, the typical developer workflow consists of coding (either new code, refactoring, or fixing existing code), local unit testing, submitting code to source control, initiating a continuous integration (CI) build, and receiving feedback from such a build, fixing errors, and continuing on to the next function to implement.

In this post, I’ll describe how to successfully introduce a coding standard into this day-to-day process by leveraging automated static analysis with dedicated reporting and workflow management. This will help you introduce the coding standard compliance process and all the benefits it brings, without sacrificing your productivity and frustrating developers.

With dedicated compliance and reporting for the coding standards, you will also be able to ensure:

  • The effectiveness of the process (reducing the burden on the developers)
  • Consistency in the policy (and monitoring the team progress)
  • Formal aspects of compliance (including automatically generating the compliance documentation that may be required by your contractor or the certification body)

So let’s begin! We’ll start at the beginning, with test configuration.

 

Define the test configuration

The first thing you will do when adopting static analysis into the workflow is define the configuration of static code analysis checkers that are relevant to your project. A team lead, architect, or functional safety officer should define the test configuration, with a collection of static analysis checkers to enforce the coding standard. This may be a one time process or repetitive action over the project lifetime.

If you don’t have an external obligation to follow a specific coding standard, we still recommend selecting a primary standard to follow, such as CERT or MISRA, and extending it with additional guidelines from other standards which may be valuable for our development. We typically see our user who relies on MISRA C 2012 to include selected CERT C guidelines into the process and vice versa.

Publish the test configuration in the IDE

Once the test configuration is prepared, it is automatically made available to all of the team members, directly in their IDEs, for continuous usage during software development.

This point in the workflow is critical in order to accelerate the compliance process and take advantage of the benefits of early defect and security vulnerability detection of automated static analysis. Developers scan their code right after it is created, near instantaneously. From our observations, even 10 to 20 minute delays in delivering the compliance scan results is long enough for developers to lose focus and continue with other work.

Check-in code for additional compliance scanning

In the next step, developers check-in their code, which triggers the CI build, where an additional compliance scan is made.

(The questions often arise if it makes sense to set up static analysis scans as a gate for the code check-in so that non-compliant source code check-in is rejected. In our experience, this does not work well. Developers get easily frustrated by rejected commits and teamwork can be hindered, while dependent pieces of code are not integrated on time. A better workflow doesn't block code check-ins but, rather, assumes that any violations that make it into the source repository are caught at the CI level.)

During the CI build, a full scan of the source repository is made. Why perform an additional scan if the code is already scanned in the IDE? Integration-level scans provide a safety net which is required since some guidelines are detectable only at the system level, or a violation is simply overlooked. Also, a full system view of the source is needed for more complex static analysis (flow analysis) to help detect defects and security vulnerabilities.

Combination of local scans in users IDEs and central scans in CI server assures accuracy and efficiency.

View the results and determine actions

When using Parasoft C/C++test, the results from the CI scan will then be published to a centralized reporting and analytics hub, accessed in a web browser, which stores and analyzes the data.

Team leaders can use the web portal to access the results, understand the current state of compliance, and drill down into specific areas of concern. They can then assign tasks to the developers to follow up on violations found during the analysis.

Fix problems

Developers then fix these problems, scan the code locally, and commit corrections, initiating another cycle.

Generate reports and documentation

As the project gets close to completion and the team is close to its compliance target, compliance reports are automatically generated, including all the documents that are required by the primary coding standard that is in use. These dedicated reports, specific for the standard, are a huge time saver, reducing the amount of tedious manual work related to creating and maintaining the compliance documentation.

Examples of what this looks like for MISRA and CERT are below.

Compliance Reporting for MISRA

Parasoft C/C++test provides dedicated reporting for documenting compliance to MISRA C. A dashboard on the Parasoft web portal provides at-a-glance views on the current state of the project, such as the one here:

Screenshot 2019-04-01 12.14.44

Each of these dashboard widgets is linkable to a more detailed view, containing detailed violation reports, files, and source code.

From here, you can automatically create the reports needed to document MISRA compliance as outlined in MISRA Compliance 2016: Achieving Compliance with MISRA Coding Guidelines. Automating these reports is a big time saver, greatly reducing the amount of manual work required to document project compliance.

Compliance Reporting for SEI CERT C

Although the SEI CERT C standard doesn’t require specific compliance reports, it does require a project to document conformance to the rulesets (e.g. L1, L2 and fully compliant.) Parasoft C/C++test includes a dedicated dashboard for CERT C conformance, that looks like this:Screenshot 2019-04-01 12.15.05

Team leads can use this dashboard view to dig deeper into specific areas of concern and assign tasks to developers to increase compliance over time. Viewing the results in context of the risk assessment framework used by the coding standard itself (for instance, seeing specific violations of L1 guidelines), significantly streamlines the process. Automating this reporting reduces the amount of analysis that team leads and architects need to perform in order to achieve CERT C compliance.

Summary

To accelerate compliance, three elements are essential: central management of compliance policies, short feedback loops for developers working with IDEs and CI/CD scans for process management and reports generation. Automation via static analysis is key to not only achieving compliance to the rule set but also reducing the manual effort of documenting and reporting compliance to auditors and assessors. By leveraging developer-centric workflows leveraging Parasoft C/C++test, teams can efficiently assess and monitor compliance on a daily basis, with dedicated reporting tools to help team leaders manage and achieve compliance.

 

Unified development testing for C and C++ applications

Stay up to date