Coverity程式碼弱點掃描修正_常使用指令集cov-build跟cov-analyze

Coverity 2022.6.0 Command and Ant Task Reference

cov-build

Intercept all calls to the compiler invoked by the build system and

capture source code from the file system.

cov-build

   (--dir <intermediate_directory> | --da-broker <broker_servername:port>)

   [--capture-ignore <program.extension>]

   [--fs-capture-list <file>]

   [--fs-capture-search <directory>]

   [--test-capture]

   [ OPTIONS ]

   BUILD_COMMAND | --no-command

The cov-build command is the primary tool to capture and emit source

code. It performs build capture, where source code is emitted by

intercepting all calls to the compiler invoked by the build system. It

also performs filesystem capture, where source code is emitted directly

from the file system. (For more information about the build capture

processes, see the section "Coverity Analyses" in the overview to the

Coverity Analysis 2022.6.0 User and Administrator Guide.)

Note: Parallel builds for ASP.NET 4 and earlier applications cannot be

virtualized directly with the cov-build command.

CAUTION: When capturing compilations using the fast Scala compiler, you

must run the fsc -shutdown command first.

Attention: The cov-build and cov-capture tools of Coverity record the

content of all environment variables in logs. This implies that Coverity

stores secrets in plain text if environment variables are assigned secret

values such as API keys or passwords. This weakens security in scenarios

where Coverity runs in a container in which sensitive information is

stored in environment variables and the logs are copied to persistent

storage outside the container. In this case, a copy of the sensitive

information will escape and outlive the container.

To mitigate this weakness when cov-build or cov-capture is run in environments where sensitive values are stored in environment variables, set the COVERITY_NO_LOG_ENVIRONMENT_VARIABLES environment variable and they will not be logged.

In general, the cov-build command name and option can prefix the original

build command. However, if the cov-build command depends on features of the command shell that usually invokes it, such as certain shell variables or non-alphanumeric arguments, you can invoke it using a wrapper script. This preserves the original behavior because the cov-build command is again invoked directly by the shell type (on which it depends).

For example, if the normal invocation of a Windows build is:

> build.bat Release"C:\Release Build Path\"

use cov-build as follows:

> cov-build --dir <intermediate_directory> <wrapper.bat>

where <wrapper.bat> is an executable command script that contains the

original and unmodified build command.

On Windows, specify both the filename and extension for the build command

when using cov-build. For example:

> cov-build --dir <intermediate_directory> custombuild.cmd

Because cov-build uses the native Windows API to launch the build

command, the appropriate interpreter must be specified with any script

that is not directly executable by the operating system. For example, if

the normal invocation of a build within Msys or Cygwin is:

> build.sh

prefix cov-build with the name of the shell:

> cov-build --dir <intermediate_directory> sh build.sh

Similarly, if a Windows command file does not have Read and Execute

permissions, or if you want cov-build to report the command file's

%ERRORLEVEL%, explicitly invoke it as a cmd.exe command string. For

example, to run the Java builder ant.bat:

> cov-build --dir <intermediate_directory> cmd /c "ant && exit/b"

cov-analyze --help

可協助理解相關CLI如何使用

cov-analyze 

Analyze an intermediate directory for quality and security defects.

The cov-analyze command runs checkers on captured code in an intermediate

directory and stores analysis results in that directory, which is

specified with --dir. This command typically follows cov-build and

precedes cov-commit-defects invocations on the same intermediate

directory. Though cov-analyze does not report defects in Java and .NET

bytecode, nor in some forms of source code not written by a person, the

command does run an analysis of them for the benefit of finding

interprocedural defects in editable source code.

A log file (analysis-log.txt) with information about the checkers used in

the analysis, including notices of crashes, is located in the following

directory: <intermediate_directory>/output

Note:

If you get a fatal No license found error when you attempt to run this

command, you need to make sure that license.dat was copied correctly to

<install_dir>/bin.

cov-analyze

    --dir <intermediate_directory>

    [OPTIONS]

where the OPTIONS are listed in the following sections:

[Options: Aggressiveness level]

[Options: Analysis]

[Options: Apex checkers]

[Options: Audit]

[Options: Brakeman checkers]

[Options: C, C++, Objective-C, Objective-C++]

[Options: C#]

[Options: Checkers]

[Options: Compliance checkers]

[Options: Custom checkers and CodeXM]

[Options: Extend SDK]

[Options: Java]

[Options: Java analysis]

[Options: JavaScript, TypeScript]

[Options: Java SpotBugs]

[Options: Kotlin detekt]

[Options: Metrics]

[Options: Models]

[Options: Shared]

[Options: Sigma]

[Options: Web and mobile application security]