Configuring Coverity Thin Client for use with Synopsys Bridge and Polaris

In some cases, you need to provide additional information about your project to make static analysis effective.

When you use Synopsys Bridge to start a fAST static scan, Synopsys Bridge calls Coverity Thin Client to manage code capture. Then Synopsys Bridge uploads the resulting data and artifacts to Polaris.

In some cases, you need to provide capture settings to Coverity Thin Client. You can provide these settings in a configuration file (usually named coverity.yaml), or by passing additional arguments in the CLI when you run a scan.

This guide includes example snippets and resources you can use to create a configuration file.

Note: All of the settings described on this page can be passed as command line arguments, if necessary. See Passing Arguments using the CLI in the Synopsys Bridge documentation for more information.

When to provide capture settings

A scan is likely to succeed without any intervention for uncompiled languages like Python, JavaScript, and PHP, because Coverity Thin Client can automatically detect these languages and configure the scan.

Use a configuration file in the following situations:

When scanning a compiled language, such as C/C++, C#, Java, and Kotlin, use the configuration file to provide your build and clean commands.
When scans for a project have failed or not returned useful results.

Note: Build environment components must be installed and accessible when integrating with compiled languages, as illustrated in the "Build commands and dependencies for various build systems" section further down in this guide. If you plan to run build capture, make sure the build tools are installed where the capture will run.

Things you can specify with the Coverity Thin Client configuration file:

Your build and clean commands
Whether source code in a specific language should be captured or excluded.
A custom compiler configuration. This is helpful if you are compiling C++ and Coverity does not automatically configure the compiler (for example, when using a GCC cross-compiler).

How to start a configuration file

Save a coverity.yaml file in your project's root directory and use the following examples to customize that file. When Coverity Thin Client is called by Synopsys Bridge, it automatically detects the file, reads the contents, and executes custom configurations.

Basic examples

For more build and clean commands, see the reference section at the end of this guide.

Java with Maven

The following configuration specifies the clean and build commands needed by Maven. The project will be cleaned by invoking mvn clean and built using mvn install.

capture:
  build:
    clean-command: mvn clean
    build-command: mvn install

About this example:

This example shows the complete contents of a coverity.yaml file that you can use to test a Maven project.
Note that white space matters in YAML files. The three levels of indentation indicate that the build property is nested under the capture property and build-command and clean command are nested under build.

Standard Java example

capture:
  build:
    build-command: javac HelloWorld.java

C# with msbuild

capture:
  build:
    clean-command: dotnet msbuild /t:Restore;Clean OWASPTop10.SqlInjection.Web.csproj
    build-command: dotnet msbuild /t:Restore;Build OWASPTop10.SqlInjection.Web.csproj

C# with dotnet

capture:
  build:
    clean-command: dotnet clean Foo.sln
    build-command: dotnet build Foo.sln

Executable script as a build command

capture:
  build:
    clean-command: clean.sh
    build-command: build-it.sh

Coverity Thin Client will only accept one build command and one clean command in the config file, but you can point to a script containing commands if you need more.

Configuration properties

The tables in this section describe each of the keys that can be used in the coverity.yaml file, starting at the top level with capture.

Capture settings

The following table describes the capture configuration; subsections describe the fields that make up the Capture type. All the Keys in the first column of this table can be nested directly under the capture key in the coverity.yaml file. (For example, build can be seen in the first row of the table and is used in the example immediately above.)


Key	Type	Description
build	Build Configuration	Specifies that build capture should be used to capture the project and provides the build configuration to use. If not specified and the project directory contains compiled source files, automatic build capture will be used to capture compiled source files in the project directory. For compiled languages only: Java, Kotlin, C#, C, C++, Objective-C, Objective-C++. See the Build configuration table below for keys that can be nested under this one.
encoding	string	Specifies the encoding to use when parsing and emitting the source files in C, C++, JavaScript..Default: US-ASCII
languages	Languages Configuration	Specifies which languages to include or exclude for capture. See Language configuration for a list of supported languages. Default: all languages are included See the table in the Language configuration section for keys that can be nested under the languages key.

Build settings

The following keys can be defined for compiled languages only. All the keys in this table can be nested directly under the build key in the configuration file.


Key	Type	Description
aspnet-compiler	Boolean	Specifies whether to enable or disable the automatic invocation of `Aspnet_compiler.exe` for any ASP.NET 4 and earlier Web applications that are detected in the build. The output of `Aspnet_compiler.exe` is required by the C# security checker.
build-command	String	Required: The build command will be invoked to use build capture to capture the project. A build command specified on the command-line will override this setting.
clean-command	String	The clean command will be invoked prior to doing build capture to capture the project.

For example:

capture:
  build:
    clean-command: dotnet msbuild /t:Restore;Clean OWASPTop10.SqlInjection.Web.csproj
    build-command: dotnet msbuild /t:Restore;Build
    aspnet-compiler: true

Language configuration

Use the following keys to specify which languages to include or exclude from capture. You may not specify both fields.

Language strings may be the following:

apex
c-family (This family includes C, C++, Objective C, and Objective C++)
csharp
go
java (Includes JSP and android config files)
javascript (Includes JavaScript and TypeScript)
kotlin
php
python
ruby
swift
vb (Visual Basic)

The following languages are not supported by the Coverity CLI:

CUDA
Fortran
Scala

Keys in this table can be nested under the languages key, which appears in the first table above and is nested under the capture key.


Key	Type	Description
include	Array of String	Specifies the languages for which the source code should be included in the capture. This key is mutually exclusive with the exclude key. Default: all languages are included.
exclude	Array of String	Specifies the languages for which the source code should be excluded in the capture. This key is mutually exclusive with the include key. Default: No languages are excluded.

For example:

capture: 
   languages: 
      exclude:
         - python

Build commands and dependencies for various build systems

You may need to install the machine dependencies to run the corresponding build. If build and clean commands don't work, check for the dependencies.


Build System	How to Detect	Minimal Set of Machine Dependencies	Build and Clean commands
Maven	Look for the presence of "pom.xml" files in the project directory	Maven build tool Java compiler	`build-command:` mvn -DskipTests -DskipITs install `clean-command:` mvn clean
Gradle	Look for the presence of "build.gradle" files in the project directory
	With a "gradlew" file (Linux/Mac)	Java compiler (Gradle will be downloaded automatically)	`build-command:` gradlew --no-daemon -x test build testClasses `clean-command:` gradlew clean
	With a "gradlew.bat file (Windows)	Java compiler (Gradle will be downloaded automatically)	`build-command:` gradlew.bat --no-daemon -x test build testClasses `clean-command:` gradlew.bat clean
	Without a "gradlew" or "gradlew.bat" file	Gradle build tool Java compiler	`build-command:` gradle --no-daemon -x test build testClasses `clean-command:` gradle clean
Make	Look for the presence of a file called "Makefile"	Make build tool Compiler for the appropriate language	`build-command:` make `clean-command:` make clean
Ant	Look for the presence of a "build.xml"	Ant build tool Java compiler	`build-command:` ant `clean-command:` ant clean
MSBuild	Look for the presence of files with ".sln" or ".csproj" extensions.	.NET SDK	`build-command:` dotnet msbuild /t:Build `clean-command:` dotnet msbuild /t:Restore;Clean
XCode	Look for the presence of directories ending with ".xcodeproj"	XCode	`build-command:` xcodebuild -workspace <xcodeproj dir> -scheme <scheme> build -UseModernBuildSystem=No CODE_SIGN_IDENTITY= CODE_SIGNING_REQUIRED=NO `clean-command:` xcodebuild -workspace <xcodeproj dir> -scheme <scheme> clean

GCC configuration

The GNU Compiler Collection (GCC) requires its own coverity.yaml configuration settings. To use GCC, add lines to:

Specify the GCC compiler using cov-configure.

Designate the language and CPU target:

cov-configure:
    - [ --template, --compiler, arm-linux-gnueabi-gcc, --comptype, gcc ]
    - [ --template, --compiler, arm-linux-gnueabi-g+, --comptype, g+ ]

Below is an example coverity.yaml settings block for GCC, telling it to run a make clean then run the make command in parallel with at least 10 job slots (make -j 10).

C/C++ Cross Compiler coverity.yaml example:
-------------------------------------------
# Coverity configuration file.
# The schema is available here: <install-dir>/doc/configuration-schema.json
capture:
  build:
    clean-command: "make clean"
    build-command: "make -j 10"
  compiler-configuration:
    cov-configure:
    - [ --template, --compiler, arm-linux-gnueabi-gcc, --comptype, gcc ]
    - [ --template, --compiler, arm-linux-gnueabi-g+, --comptype, g+ ]

Note: Pay special attention to GCC binary naming conventions if using more than one language and/or CPU target.