Coverity static analysis has powerful capabilities that can find issues deep within the logic of your application’s code. If you apply third-party or open source code during your build process, Coverity might even find issues in code your team didn’t write. Often, you won’t be interested in fixing that third-party code, for a variety of reasons. If you don’t own the code, you may not be permitted to modify it. If it’s open source code, you may not be willing to assume the licensing obligations associated with updates. Modifying third-party code also has downstream impacts on future development efforts. For example, if there’s a new release of that code, you may need to carry forward your fixes to the new release—potentially an ongoing effort. This post describes a couple of options at your disposal for dealing with issues in code you don’t plan to fix.
The Forrester Wave™ Leader
Black Duck is a Leader in the 2023 Forrester Wave for Static Application Security Testing
Option 1: Use Coverity’s issue-filtering capabilities (highly preferred)
Coverity’s web interface provides all the capability you need to filter out issues in code you don’t plan to fix. Here are some approaches you can take:
If there are just a few issues, the best approach is simply to mark the issues with an action of “Ignore.” You can then filter out ignored issues in any view. A benefit of this approach is someday you might spot an issue that you do want to see fixed, or at least be aware of. This approach is also the easiest and quickest way to ignore issues.
If Coverity identifies a significant number of issues, you can use a component filter to filter out issues in third-party code. This approach requires you to set up a component map, which maps file names or directory locations to named components. Once your component map is defined, you can use the “Component” filter in any view to include or exclude any components.
For example, if your third-party code is in a directory called ThirdParty, you could easily map .*ThirdParty.* to a component named “Third Party” and then exclude it using the “Component” filter. See the screenshot below for an example component map configuration. Note that component maps must be defined by an administrator or a user with the “Manage Component Maps” role.
Figure 1: Coverity component map configuration
Option 2: Filter out irrelevant source code before or during the cov-build step
Take care with either of the options noted in this section, since excluding compiled code during the cov-analyze step can ultimately reduce the quality of the analysis results. An explanation of why this is the case is beyond the scope of this post, but suffice it to say that ignoring compiled code could increase the false-positive and false-negative rates.
Black Duck highly recommends using the filtering options noted in the previous section to ignore uninteresting code. You can also use Coverity support to help guide you in the right direction. If it’s determined that issue filtering is not the right option for you, you can use one of the following two options:
Pre-compile the files you wish to ignore
To understand why this is an option, you first have to understand how Coverity captures your code for analysis. Coverity identifies the code by observing your native build. The cov-build Coverity command (which essentially is also used by the Coverity Wizard and all Coverity IDE plugins) determines which files are compiled and then executes its own compilation to build up a representation of your software. Coverity uses this representation during analysis. If cov-build does not observe a file being compiled, it won’t include that file’s code in the analysis. So you can make cov-build ignore code by ensuring that code is built before cov-build is run.
Let’s look at an example of this approach. Consider a simple command line build using Maven. The native build command sequence might look like this:
mvn clean all
Consequently, this would be the Coverity build command:
cov-build --dir <idir> mvn clean all
If we wanted to avoid capturing third-party code for analysis, we could instead implement a build approach like this:
mvn clean
mvn ThirdParty // Build the third-party code with no Coverity capture
cov-build --dir <idir> mvn all // Now capture the rest of the code with Coverity
Ignore specific files with a new compiler configuration
This approach is a little trickier than all previous approaches but could be useful if issue filtering is not an option and you can’t adjust your build approach. This approach requires you specify the files or directories you want to ignore during compiler configuration. If your third-party code happens to be in a directory named ThirdParty, you can easily configure Coverity to ignore all files in that directory and its subdirectories.
In this approach, you’ll need to delete your existing compiler configuration. First, list your current compiler configurations:
cov-configure --list-configured-compilers text
The list of compiler configs will look something like this (this example uses gcc for compilation):
template-gcc-config-0,gcc,gcc,yes,null
template-gcc-config-1,gcc,gcc-3,yes,null
template-gcc-config-2,gcc,gcc-4,yes,null
Now delete the compiler configs that correspond to your compiler:
cov-configure --delete-compiler-config template-gcc-config-0
cov-configure --delete-compiler-config template-gcc-config-1
cov-configure --delete-compiler-config template-gcc-config-2
You’ll then be ready to generate your new compiler configuration with a skip_file option:
cov-configure --gcc --xml-option=skip_file:"ThirdParty"
Your new compiler config will ignore any file with “ThirdParty” in the path or file name. For more details on this approach and all Coverity commands, see the cov_command_ref.pdf/html documentation. The cov_analysis_admin_guide.pdf/html also has a section that explains compiler configurations and various options in more detail.
The bottom line
Coverity provides a powerful interface that allows you to categorize and filter issues found. You can focus your team’s attention on the issues that you can and should address while avoiding unnecessary investigation into code you don’t own or don’t plan to fix. This powerful interface should be used to filter issues if possible; however, you can also modify your build or analysis approach to avoid issues altogether. But take this latter approach with caution, since it could reduce the quality of the analysis results.
Continue Reading
