Using SCA Resolver in Checkmarx One

Debian install command:

apt-get install maven

To ensure Maven is installed, run: mvn --version inside the project directory

If Maven is correctly installed, you should receive a message indicating which version is installed on your machine.

Checkmarx SCA Resolver uses Maven to extract the dependency graph.

This process downloads the dependencies to the local cache folder (usually .m2 ) and inspects the pom.xml files of the dependencies recursively to construct the graph.

It requires connectivity to a Maven repository to download those dependencies. By default, Maven uses the Central Maven repo but other repositories may be configured in a settings.xml file in the project root or in the global Maven folder in the local machine.

Testing Dependency Resolution

You can test whether the dependency tree can be extracted successfully, by running the following command inside the folder where the manifest exists:

mvn dependency:tree

Troubleshooting

The following command can be used to troubleshoot problems with the dependency resolution.

mvn install -DskipTests

Dev Dependencies

Any dependency marked with <scope>test</scope> is considered a Dev dependency in Checkmarx SCA

A multi-module project has a root pom.xml file and multiple modules, each in a sub-directory.

The root pom.xml has the following structure:

  <modules>
    <module>module1</module>
    <module>module2</module>
  </modules>

To successfully resolve dependencies, the project needs to be in a "buildable" state.

If SCA Resolver is not being run “post build”, please run the following command before invoking the Resolver scan.

mvn install -DskipTests

Debian install command:

apt-get install gradle

To ensure Gradle is installed, run: gradle --version inside the project directory

The dependency resolution process downloads the dependencies to the local cache folder (usually .gradle )

It requires connectivity to a java repository to download those dependencies. By default, the Maven Central is used (link) but other repositories may be configured in a build.gradle file, or in global Gradle settings.

gradle dependencies -q --no-daemon -Dorg.gradle.jvmargs=-Xmx1g

A multi-module project has a settings.gradle file with list of included modules. Each module resides in a sub-directory.

Checkmarx SCA Resolver recognizes this file, and resolves the modules of the project one-by-one using the main settings, calling the following command in the root folder per module (give by modulename):

gradle modulename:dependencies -q --no-daemon -Dorg.gradle.jvmargs=-Xmx1g

Gradle is commonly shipped with a wrapper script, called gradlew in the root directory of the project.

Checkmarx SCA Resolver detects the wrapper and uses the script instead of the global “gradle” command.

For example:

./gradlew dependencies -q --no-daemon -Dorg.gradle.jvmargs=-Xmx1g

Invoking the gradlew script may download and compile a desired Gradle version, usually within the gradle/wrapper/gradle-wrapper.properties file. Gradle Wrapper requires JRE to run and install Gradle.

To learn more, visit https://docs.gradle.org/current/userguide/gradle_wrapper.html

Debian:

Dependency Resolution

Each ivy.xml file will tentatively be associated with a build.xml file. For each ivy.xml file, configurations will be fetched. Each corresponding build.xml file will be modified to contain a specific target which will download the dependencies to the local cache folder (usually .ivy2) and generate XML report files based on the configurations fetched from ivy.xml.

The XML report files will be used to construct the dependency tree.

This process requires connectivity to a repository to download those dependencies. By default, Apache Ivy uses the Central Maven repo (https://repo.maven.apache.org/maven2/ ) but other repositories may be configured in an ivysettings.xml file.

At the end of the process, build.xml files which were modified will be restored back to their original content.

Test

Check the configurations for a particular ivy.xml.

Add the following target to the corresponding build.xml (inside <project> tag), ensuring that {CONFS} contains a comma separated list of the configurations from ivy.xml.

    <target name="generateIvyReportsforDependencyScan" description="Generate Ivy report files">

        <ivy:resolve />

        <ivy:report graph="false" xsl="false" xml="true" conf="{CONFS}" todir="./ivyReports" />

    </target>

Run ant generateIvyReportsforDependencyScan in build.xml location and check that the ivyReports folder was created and contains one .xml file per specified configuration.

Install dotnet cli or nuget cli, according to your project requirements.

To test dotnet installation, run the following command:

dotnet --version

To test nuget installation, run the following command:

nuget

NuGet restore command downloads the dependencies to the local machine. The nuget.config file is used to configure custom repositories to be used.

Checkmarx SCA Resolver uses NuGet to create a lock file and parses it to extract the full dependency graph.

Test

Checkmarx SCA Resolver requires the project to be in a ‘buildable’ state for the packages to be resolved.

Depending on which package manager you are using, run the appropriate command inside the folder where the manifest exists. A file named package.lock.json is created with the dependency tree.

For dotnet cli, run:

dotnet restore --force-evaluate --use-lock-file

For nuget cli, run:

nuget restore -Force -UseLockFile

Requirements:

Debian install command:

apt-get install npm git
npm -g install npm@8.11.0
npm install -g lerna

Alpine install command:

apk add --update npm git
npm -g install npm@8.11.0
npm install -g lerna

To ensure NPM is installed, run: npm --version

Checkmarx SCA Resolver uses NPM to parse the lock file (package-lock.json) and to extract the dependency graph. If the lock file does not exist, the Resolver creates it.

When creating a lock file, NPM connects to the NPM registry to collect metadata.

Checkmarx SCA Resolver attempts to create a lock file without installing dependencies, by using the --package-lock-only flag to the npm install command - this is the default behavior.

In some specific cases where package-lock creation is disabled by the project configuration, the Resolver runs a regular install which downloads the dependencies to a node_modules folder.

Custom NPM registries may be configured inside the package.json file, or in project / global configurations, usually .npmrc files.

Test

To generate a lock file, run the following command inside the project directory (a package-lock.json file is created):

npm i --package-lock-only

If creating a lock file is disabled by the NPM configuration, run the following command:

npm install --ignore-scripts instead.

If the file already exists, or created in the step above, run the following command to extract the dependency graph:

npm ls --json

Dev Dependencies

Any dependency under devDependencies section is considered Dev.

To generate a list of dev dependencies, Checkmarx SCA Resolver runs the following command on the lock file.

For NPM version 6:

npm ls --json --dev

For NPM version 7 or higher:

npm ls --json --include dev

This project structure uses Lerna build tool to manage multiple NPM modules inside one project.

The root folder of the project has a lerna.json file defining the modules.

Simply resolving each module individually will be inaccurate since peer modules reference each other.

Checkmarx SCA Resolver recognizes the use of Lerna, and uses it to extract the complete dependency graph.

The command used is:

lerna bootstrap --hoist

This creates a lock file in the root folder with the complete project dependencies.

Requirements:

Debian install command:

apt-get install yarn git

To ensure Yarn is installed, run: yarn --version

Checkmarx SCA Resolver parses the lock file (yarn.lock) and to extract the dependency graph. If the lock file does not exist, the Resolver creates it.

When creating a lock file, Yarn connects to the NPM registry to collect metadata and downloads the dependencies to the local machine

Custom NPM registries may be configured inside the package.json file, or in project / global configurations, usually .yarnrcfiles.

Test

To generate a lock file, run the following command inside the project directory. A yarn.lock file is created.

yarn install --ignore-scripts

Dev Dependencies

Any dependency under devDependencies in the package.json file is considered as a dev dependency.

This project structure uses Yarn feature to manage multiple modules inside one project.

The package.json file has a workspaces section that lists the local paths of modules

Checkmarx SCA Resolver recognizes the use of Yarn Workspaces, and installs the dependencies from the root folder location only, running yarn install --ignore-scripts

This creates a lock file in the root folder with the complete project dependencies.

Requirements:

Debian install command:

apt-get install npm
npm install -g bower

Alpine install command:

apk add –update npm
npm install -g bower

To ensure Bower is installed, run: bower --version

Checkmarx SCA Resolver uses the bower-dependency-tree module to generate a tree of dependencies.

This is an NPM module. In case it is not installed, Checkmarx SCA Resolver installs it using NPM.

Test

Ensure installation of the bower-dependency-tree module with the following command:

npm install -g bower-dependency-tree

Then, using the following command, run it to generate the dependency tree inside the project root folder:

bower-dependency-tree

Requirements:

Debian install command:

apt-get install python python-pip

Alpine install command:

apk add --update py-pip py3-setuptools

To ensure pip is installed, run: pip -V

Checkmarx SCA Resolver ensures the installations of the dependencies in manifest, and uses pipdeptree utility to construct the dependency graph

The Resolver creates a temporary virtual environment to install the dependencies, using the command:

python -m virtualenv random-name

Then, all commands are run in the virtual environment and the pipdeptree utility is temporarily installed there. For example, this is an install command on Linux:

source random-name/bin/activate && python -m pip install -r requirements.txt

Test

Checkmarx SCA Resolver requires the dependencies to be installed to extract the full tree. Use the following command:

python -m pip install -r requirements.txt

The full flow of extracting dependencies is this for Linux

python -m virtualenv random-name
source random-name/bin/activate && python -m pip install -r requirements.txt
source random-name/bin/activate && python -m pip install pipdeptree
source random-name/bin/activate && python -m pipdeptree --graph-output dot -e pipdeptree,setuptools,wheel,graphviz

random-name\Scripts\activate

When Python 3 is installed, Checkmarx SCA Resolver may execute the Python commands python3 and pip3.

Checkmarx SCA Resolver first attempts to run python3, and if it is not found, it attempts to run python.

You can use the --python-version flag or PythonVersion configuration argument to explicitly specify which Python version to use for the manifest file resolution.

Requirements:

Linux, macOS, Windows (WSL) install command:

curl
-sSL https://install.python-poetry.org | python3 –apt-get install python python-pip

To ensure Poetry is installed, run:

poetry --version

Checkmarx SCA Resolver ensures the installations of the dependencies in manifest to extract the dependency tree of the project.

Test

Use the following command to install dependencies::

poetry install

Use the following command to extract the dependency tree:

poetry show --tree

Requirements:

Debian install command:

apt-get install php-cli php-curl composer

Alpine install command:

apk add –update php-cli php-curl composer

To ensure composer is installed, run: composer --version

Checkmarx SCA Resolver install the dependencies using composer. Composer installs and downloads the dependencies to the local machine.

Afterwards, Composer is used to the detect dependencies

Test

Checkmarx SCA Resolver requires the dependencies to be installed to extract the full tree. Use the following command:

composer install
composer show --tree --format json

Dev Dependencies

Dependencies under require-dev are considered as dev by Checkmarx SCA.

Requirements: sbt

To install, visit: https://www.scala-sbt.org/download.html

To make sure sbt is installed correctly, make sure you can invoke sbt inside the project folder by running the following command:

sbt --script-version

The dependency resolution process involves downloading and building the scala project using the sbt "compile" command. Checkmarx SCA Resolver uses the IVY reports generated during the build process to gather the dependency graph.

They can be found under the target/scala-*/reports/*.xml, where scala-* can be any Scala version used, such as scala-2.13.

Those XML files are parsed to generate the tree of dependencies.

Test

Run the following command in the project root:

sbt "compile"

After a successful build, validate that XML files are generated inside the target/scala-*/reports/*.xml folders, where scala-* can be any Scala version used, such as scala-2.13.

Debian:

Use the following procedure to ensure that version 5.3.3 of SwiftPm is installed as well as other necessary tools.

The dependency resolution process uses SwiftPm’s capabilities to calculate all the dependencies.

If a Package.swift file exists, then Checkmarx SCA Resolver uses that to calculate the dependencies. It also checks if the folders declared on the manifest file, .target and .testTarget, are present on the project.

If there is only a Package.resolved file, then the package resolution is done from that file, without executing any commands.

Test

Run the following command in the project root:

swift package show-dependencies

After a successful build, check if the output contains the dependencies for the project.

The dependency resolution process involves downloading the manifest files from GitHub via API.

Checkmarx SCA Resolver uses Cartfile, Cartfile.private and Cartfile.resolved files to gather the info needed to generate the set of dependencies. When the dependencies repository includes the Cartfile.resolved files, these are used to avoid resolving the versions again.

Test: no testing needed

Carthage resolution uses GitHub API to resolve the packages. GitHub limits unauthenticated users to 300 requests per hour. This may affect the resolution capabilities. To bypass this limitation, on Checkmarx SCA Resolver you can define the GithubToken environment variable with up to 4 tokens (separated by “-”) obtained from a GitHub account.

Repositories that are referenced as “git sources” aren’t considered for resolution unless they are hosted on GitHub.

Debian install command:

apt -q install ruby-full -y && apt-get install -y --no-install-recommends ruby ruby-dev make gcc libcurl4 libc6-dev git && gem install cocoapods

This command will install the latest available version of CocoaPods, Ruby and other necessary tools.

To ensure that CocoaPods is installed, run pod --version --allow-root

If Podfile.lock does not exist, dependencies from Podfile will be installed and the Podfile.lock file will be generated. This file will then be parsed, creating the dependency tree.

Test

Run the following command where Podfile is located:

pod install --allow-root

After running successfully, check if Podfile.lock file was created.

Debian:

Use the following procedure to install Go version 1.16.6 and other necessary tools.

If “go.sum” does not exist, dependencies from “go.mod” will be installed and “go.sum” file will be generated. Then a dependency graph will be generated that is used to build the dependency tree.

Test

Authentication

Docker Hub API has restrictions for anonymous requests. We offer the possibility to authenticate your requests through these environment variables:

Build Arguments

Some projects may contain build arguments that are required for layer resolution.

Checkmarx SCA Resolver supports the use of a .env_cxsca-container-build-args file, which can be added to repository code to provide custom build-arguments to Dockerfile FROM instructions. We recommend using this file when the docker is present and the build process requires arguments in order to enhance the docker layer resolution and improve results.

For more info about using custom build arguments, see Container Scans.