About Java SCA Agent-Based Scanning

Veracode Software Composition Analysis

You can find vulnerabilities in your Java applications using Veracode Software Composition Analysis agent-based scanning. You can run a scan on Maven, Gradle, and Ant repositories using the agent-based scanning command-line interface or the CI integrations.

For packaging instructions for Veracode Static Analysis and Veracode SCA upload scans, see Packaging Java Applications.

Maven Requirements

  • Meet the requirements for the Veracode SCA agent.
  • Include the pom.xml file in the directory where you perform scans.
  • Use Maven 3.1 or later with the executable installed in the local path.
  • In your ~/.m2/settings.xml file, ensure that you properly set up any Nexus servers or authentications to successfully compile code.
  • Be able to run the mvn dependency:tree command from the root of the project where you perform scans.

Running a Scan

You can use agent-based scanning to scan any code repository to which you have access and fulfills the Maven requirements. To demonstrate how to run a scan, you can clone one of the Veracode SCA public repositories:
git clone https://github.com/srcclr/example-java-maven
Note: You can also scan code repositories hosted on git by using the --url argument with the CLI agent (see documentation for usage), but for the purposes of this guide it will be assumed you have the code stored locally.
Once the code is cloned to your desktop, point theVeracode SCA CLI agent at the directory of the repository and scan away:
# Replace "example-java-maven" with the project folder name of your choosing
srcclr scan path/to/example-java-maven
To view more verbose output during the scan process, you can add the --loud argument as well:
srcclr scan path/to/example-java-maven --loud
The Veracode SCA agent then proceeds to build the code in order to identify the dependencies and versions in your project. The build command for Maven is:
mvn compile -Dcheckstyle.skip=true -e -DskipTests \
-DskipITs -Dmaven.test.skip=true --fail-fast --nsu -Denforcer.skip=true

Once the agent has evaluated the open source libraries in use, a summary of the scan results will be produced which will include counts for total libraries used, vulnerable libraries, percentage of third party code, vulnerable methods in use, as well as a list of the vulnerabilities found:

Scanning the Dependency Tree for Maven

The Veracode SCA agent can scan the output of the Maven dependency:tree command. For dependency tree scanning, the agent requires you to specify the --stdin=maven input option.

You must compile the project before scanning to enable vulnerable method analysis.
Note: Dependency tree scanning disables scanning for all other package managers.

You can scan the dependency tree for Maven using either of these methods:

  • Redirect the output of the Maven dependency:tree command directly to the Veracode SCA agent. For example:

    mvn dependency:tree | srcclr scan --stdin=maven
  • Redirect the output of the dependency:tree command into a file and point the Veracode SCA agent to the file using the dependency_tree_file scan directive. For example, in Linux bash:

    mvn dependency:tree > tree.txt
    SRCCLR_DEPENDENCY_TREE_FILE=tree.txt srcclr scan --stdin=maven

If you want to specify the scope of dependencies included in the scan, Veracode recommends you set the scope scan directive in the agent instead of setting the scope property of the mvn command. The scan directive allows more precise scope selection.

Configuring Scans

One of the requirements for agent-based scanning is the ability to build the code, and many code repositories require specific commands, tasks, or arguments for successful code compilation. By adding a srcclr.yml file to the directory where you point the Veracode SCA agent, you can specify scan directives which can be used for scanning your Java code. The following are configuration options which can be used within your srcclr.yml for Maven scanning:

Directive Description
compile_first Forces Veracode SCA to perform compilation before scanning
install_first Forces Veracode SCA to perform compilation and installation before scanning
custom_maven_command Allows Veracode SCA to use a custom maven build command
custom_maven_exec Allows Veracode SCA to use a custom maven executable for scanning
scope When specified, limits dependency resolution to the specified scope
dependency_tree_file For dependency tree scanning, specifies the path to a file containing the output of the dependency:tree command, relative to the project root

Fixing Vulnerability Issues

After viewing the scan results, users will likely want to fix the vulnerabilities discovered in their Maven project. Veracode SCA agent-based scans provide clear instructions for fixing vulnerability issues through the web interface.

Fixing a Direct Vulnerability

When a library is specifically referenced in your configuration file, pom.xml, or added to your project as a JAR file, Veracode SCA refers to the library as a direct dependency. Fixing a vulnerability in a direct dependency using agent-based scanning is simple. Using the open-source projects mentioned in the Running a scan section and after having navigated to the project scan results within the Veracode Platform, you can view Vulnerability issues which are included only in Direct Libraries:

After filtering the scan results, you can view details on an issue to find out how to fix it by clicking the issue ID next to the vulnerability name. This brings you to the issue details page, where you find information on fixing the vulnerability. In general, the best way to fix a vulnerability in a direct dependency is to update the version in use to the version recommended by Veracode SCA. The agent-based scan recommends a version which is not associated with the vulnerability you are subject to, in addition to any other vulnerabilities which might result from switching to a different version. In order to prevent the update from having significant impact on your code, the recommended version will be the closest to your current version while still not being associated with other vulnerabilities.

Note: Some libraries include vulnerabilities which have not yet been fixed, and therefore Veracode SCA cannot provide a version to update to. In cases such as this, it is recommended you either create a pull request to the unfixed library or use a different library in your code.

For example, the following provides fixes for an Unauthorized Modification of Nodesvulnerability in Apache Kafka, version 0.9.0.1 in the example-java-maven repository.

To fix this direct vulnerability, edit the pom.xml file in the root of the project to match the following:

<dependency>
 <groupId>org.apache.kafka</groupId>
 <artifactId>kafka_2.11</artifactId>
 <version>0.10.2.1</version>
</dependency>

Once you have completed this step, validate the fix.

Fixing a Transitive Vulnerability

Direct dependencies often depend on other libraries which are referred to as transitive dependencies. Vulnerabilities in transitive dependencies are common because often the developer does not realize that the library they are adding to their project depends on a vulnerable library without having a tool such as Veracode SCA to show this information. Fixing vulnerabilities in transitive dependencies can be difficult because the direct dependency may require a specific version rather than a version range. You can find details on these issues by viewing your issues and leaving the Direct Libraries checkbox unchecked. Transitive vulnerabilities are indicated in the Library column by the smaller arrow next to the library name. Selecting the issue number to view the issue details additionally provides the Type of library, either direct or transitive.

Fixing a transitive library for Maven involves overriding the transitive dependency by adding the appropriately versioned dependency as a direct library. As an example, the following provides fixes for a Timing Attack Via Comparison Function vulnerability in OrientDB Core, version 2.1.9 in the example-java-maven repository.

To fix this transitive vulnerability, edit the pom.xml file in the root of the project by adding the following in the dependencies scope:

<dependency>
 <groupId>com.orientechnologies</groupId>
 <artifactId>orientdb-core</artifactId>
 <version>2.1.11</version>
</dependency>

Once you have completed these steps, validate the fix.

Gradle Requirements

  • Meet the requirements for the Veracode SCA agent.
  • Use Gradle version 2.13 or later.
  • Have the Gradle executable installed in your path or include the gradlew wrapper file in the project repository.
  • Include the build.gradle file in the directory where you perform the scan.
  • In ~/.gradle/gradle.properties, ensure you properly set up any Nexus servers or authentications to successfully compile code.
  • Be able to run the gradle dependencies command from the root of the project where you perform the scan.

Running a Scan

You can use agent-based scanning to scan any code repository which you have access to and fulfills the above requirements. To demonstrate how to run a scan, you can clone one of the Veracode SCA public repositories:
git clone https://github.com/srcclr/example-java-gradle
Note: You can also scan code repositories hosted on git by using the --url argument with the CLI agent (see documentation for usage), but for the purposes of this guide it will be assumed you have the code stored locally.
Once the code has been cloned to your desktop, point the Veracode SCA CLI agent at the directory of the repository and scan:
# Replace "example-java-gradle" with the project folder name of your choosing
srcclr scan path/to/example-java-gradle
To view more verbose output during the scan process, you can add the --loud argument as well:
srcclr scan path/to/example-java-gradle --loud
The Veracode SCA agent then proceeds to build the code in order to identify the dependencies and versions in your project. The build command for Gradle is:
./gradlew projects classes

Once the agent has evaluated the open source libraries in use, a summary of the scan results will be produced which will include counts for total libraries used, vulnerable libraries, percentage of third party code, vulnerable methods in use, as well as a list of the vulnerabilities found.

Scanning the Dependency Tree for Gradle

The Veracode SCA agent can scan the output of the Gradle dependencies task. For dependency tree scanning, the agent requires you to specify the --stdin=gradle input option.

You must compile the project before scanning to enable vulnerable method analysis.
Note: Dependency tree scanning disables scanning for all other package managers.

You can scan the dependency tree for Maven using either of these methods:

  • Redirect the output of the Gradle dependencies task directly to the Veracode SCA agent. For example, in Linux bash:

    ./gradlew dependencies | srcclr scan --stdin=gradle
  • Redirect the output of the Gradle dependencies task into a file and point the Veracode SCA agent to the file using the dependency_tree_file scan directive. For example, in Linux bash:

    ./gradlew dependencies > tree.txt
    SRCCLR_DEPENDENCY_TREE_FILE=tree.txt srcclr scan --stdin=gradle

For multi-project Gradle builds, you might need to prefix the dependencies task with a subproject name and a colon in the gradle or gradlew command. For example: my-subproject:dependencies.

If you want to specify the scope of dependencies included in the scan, you can use the --configuration option with the dependencies task for gradle or gradlew. The scope scan directive for the agent does not support dependency tree scanning for Gradle.

Configuring Scans

One of the requirements for agent-based scanning is the ability to build the code, and many code repositories require specific commands, tasks, or arguments for successful code compilation. By adding a srcclr.yml file to the directory where you point the Veracode SCA agent, you can specify scan directives which can be used for scanning your Java code. The following are configuration options you can use within your srcclr.yml file for Gradle scanning:

Directive Description
custom_gradle_exec Allows Veracode SCA to use a custom gradle executable for scanning.
gradle_location Specifies the relative path of the gradle wrapper if not in the scanned directory
gradle_tasks Allows Veracode SCA to use custom tasks for scanning gradle projects
gradle_filter_task Allows the user to dynamically pin scans to only certain submodules, based on whether that submodule contains the specified task
scope Limits dependency resolution to the specified scope
dependency_tree_file For dependency tree scanning, specifies the path to a file containing the output of the dependencies task, relative to the project root
Note: By default, the scope for Gradle scans is compile. If you import dependencies using the api or implementation keywords, you must modify the scope to include runtime.

Fixing Vulnerability Issues

After viewing the scan results, users likely want to fix the vulnerabilities discovered in their Gradle project. Veracode SCA provides clear instructions for fixing vulnerability issues through the Veracode Platform.

Fixing a Direct Vulnerability

When a library is specifically referenced in your configuration file, build.gradle, or added to your project as a JAR file, Veracode SCA refers to the library as a direct dependency. Fixing a vulnerability in a direct dependency using agent-based scanning is simple. Using the open-source projects mentioned in the Running a Scan section and after having navigated to the project scan results within the Veracode Platform, you can view vulnerability issues, which are included only in Direct Libraries.

After filtering the scan results, you can view details on an issue to find out how to fix it by clicking the issue ID next to the vulnerability name. This will bring you to the issue details page, where you will find information on fixing the vulnerability. In general, the best way to fix a vulnerability in a direct dependency is to update the version in use to the version recommended by Veracode SCA. The agent-based scan recommends a version which is not associated with the vulnerability you are subject to, in addition to any other vulnerabilities which might result from switching to a different version. In order to prevent the update from having significant impact on your code, the recommended version will be the closest to your current version while still not being associated with other vulnerabilities.

Note: Some libraries include vulnerabilities which have not yet been fixed, and therefore Veracode SCA cannot provide a version to update to. In cases such as this, it is recommended you either create a pull request to the unfixed library or use a different library in your code.

As an example, the following provides fixes for an Unauthorized Modification of Nodes vulnerability in Apache Kafka, version 0.9.0.1 in the example-java-gradle repository.

To fix this direct vulnerability, edit the build.gradle file in the root of the project, and edit the dependencies scope to match the following:

compile 'org.apache.kafka:kafka_2.11:0.10.2.1'

Once you have completed this step, validate the fix.

Fixing a Transitive Vulnerability

Direct dependencies often depend on other libraries which are referred to as transitive dependencies. Vulnerabilities in transitive dependencies are common because often the developer does not realize that the library they are adding to their project depends on a vulnerable library without having a tool such as Veracode SCA to show this information. Fixing vulnerabilities in transitive dependencies can be difficult because the direct dependency may require a specific version rather than a version range. You can find details on these issues by viewing your issues and leaving the Direct Libraries checkbox unchecked. Transitive vulnerabilities are indicated in the Library column by the smaller arrow next to the library name. Selecting the issue number to view the issue details will additionally provide the Type of library; either direct or transitive.

Fixing a transitive library for Gradle involves overriding the transitive dependency by adding the appropriately versioned dependency as a direct library. As an example, the following provides fixes for an Timing Attack Via Comparison Function vulnerability in OrientDB Core, version 2.1.9 in the example-java-gradle repository.

To fix this transitive vulnerability, edit the build.gradle file in the root of the project, and add the following in the dependencies scope to match:

compile ('com.orientechnologies:orientdb-core:2.1.11') {
  force = true
}

Once you have completed these steps, validate the fix.

Ant Requirements

To allow agent-based scanning to locate dependencies accurately, the build targets in the Ant build file should be compiling projects with the <javac> tag (seehttps://ant.apache.org/manual/Tasks/javac.html).

Running a Scan

You can use agent-based scanning to scan any code repository which you have access to and fulfills the above requirements. To demonstrate how to run a scan, you can clone one of the Veracode SCA public repositories:
git clone https://github.com/srcclr/example-java-ant
Note: You can also scan code repositories hosted on git by using the --url argument with the CLI agent (see documentation for usage), but for the purposes of this guide it will be assumed you have the code stored locally.
# Replace "example-java-ant" with the project folder name of your choosing
srcclr scan path/to/example-java-ant
To view more verbose output during the scan process, you can add the --loud argument as well:
srcclr scan path/to/example-java-ant --loud
The Veracode SCA agent will then proceed to build the code in order to identify the dependencies and versions in your project. The build command for Ant is:
ant build

Once the agent has evaluated the open source libraries in use, a summary of the scan results will be produced which will include counts for total libraries used, vulnerable libraries, percentage of third party code, vulnerable methods in use, as well as a list of the vulnerabilities found.

Configuring Scans

One of the requirements for agent-based scanning is the ability to build the code, and many code repositories require specific commands, tasks, or arguments for successful code compilation. By adding a srcclr.yml file to the directory where you point the Veracode SCA agent, you can specify scan directives which can be used for scanning your Java code. The following are configuration options which can be used within your srcclr.yml for Ant scanning:

Directive Description
custom_ant_exec Allows Agent-Based Scanning to use a custom ant executable for scanning
ant_build_steps Allows Agent-Based Scanning to use a custom ant build steps before scanning
ant_lib_dir Allows specification of relative paths to scan for Jar files

Fixing Vulnerability Issues

After viewing the scan results, users will likely want to fix the vulnerabilities discovered in their Ant project. The agent-based scan provides clear instructions for fixing vulnerability issues through the web interface.

Fixing a Direct Vulnerability

When a library is specifically referenced in your configuration file or added to your project as a jar, Veracode SCA refers to the library as a direct dependency. Fixing a vulnerability in a direct dependency using agent-based scanning is simple. Using the open-source projects mentioned in the Running a scan section and after having navigated to the project scan results within the Veracode Platform, you can view Vulnerability issues which are included only in Direct Libraries.

After filtering the scan results, you can drill into an issue to find out how to fix it by clicking the issue id next to the vulnerability name. This will bring you to the issue details page, where you will find information on fixing the vulnerability. In general, the best way to fix a vulnerability in a direct dependency is to update the version in use to the version recommended by Veracode SCA. The agent-based scan recommends a version which is not associated with the vulnerability you are subject to, in addition to any other vulnerabilities which might result from switching to a different version. In order to prevent the update from having significant impact on your code, the recommended version will be the closest to your current version while still not being associated with other vulnerabilities.

Note: Some libraries include vulnerabilities which have not yet been fixed, and therefore Veracode SCA cannot provide a version to update to. In cases such as this, it is recommended you either create a pull request to the unfixed library or use a different library in your code.

As an example, the following provides fixes for an Unauthorized Modification of Nodesvulnerability in Apache Kafka, version 0.9.0.1 in the example-java-ant repository.

To fix this direct vulnerability, perform the following steps: 1. Delete the kafka_2.11-0.9.0.1.jarfile in the libsrc/ directory. For your own projects, the libsrc/ directory would be wherever jars are currently be stored for your project.

  1. From the issue details page, click the link to the appropriate version of the Apache Kafka library in Maven Central.
  2. Within that page, select the download link for the Apache Kafka jar file.
  3. Download the jar file to the libsrc/ directory.

Once you have completed these steps, validate the fix.

Fixing a Vulnerable Method

Within the issues across a given project, you can filter your list to display only vulnerabilities where a vulnerable method is in use by clicking the Vulnerable methods checkbox above your issues list. If a vulnerable method is shown to be in use, as indicated by the warning icon (), it means that the specific piece of code which causes a given library to be vulnerable is being used by the code project it is found in. This is a crucial distinction from other vulnerabilities where you might not be using the vulnerable part of the code, therefore making the issue important but more a matter of code hygiene where you would want to prevent future developers from using this library.

Within the issue details for a vulnerability with a vulnerable method in use, agent-based scanning provides the full call path for every instance of a given vulnerable method. This helps users evaluate the importance of the vulnerability based on the usage within their project and alter their actual code rather than fixing the vulnerability by updating the library.

This particular Information Disclosure vulnerable method in jBCrypt is included in the example-java-maven, example-java-gradle, and example-java-ant repositories. Upon drilling into the Vulnerable methods tab, you can see that the crypt_raw method is what is identified as making this particular library vulnerable. You can view details on its usage within your code by clicking Show full call chain, revealing the actual line number in the project which is causing the issue: