Java Scanning

SourceClear Software Composition Analysis

Finding Vulnerabilities in Java repositories

Finding vulnerabilities in your Java repositories using SourceClear is simple. This section includes steps for running a SourceClear scan on Maven, Gradle, and Ant repositories using the SourceClear Command Line Interface, but you can scan with any of the SourceClear CI Integrations as well.

Maven Requirements

  • Requirements for the SourceClear agent
  • pom.xml file present in the directory where the scan is performed
  • Maven 3.1 or higher, executable installed on the local path
  • In your ~/.m2/settings.xml file, verify that any nexus servers or authentications are properly set up in order to successfully compile code

Running a scan

You can use SourceClear to scan any code repository to which you have access and fulfills the above requirements. To demonstrate how to run a scan, you can clone one of SourceClear's 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 theSourceClear 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 SourceClear agent will then proceed 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:

Configuring scans

One of the requirements for SourceClear 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 SourceClear 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 SourceClear to perform compilation before scanning
install_first Forces SourceClear to perform compilation and installation before scanning
Custom_maven_command Allows SourceClear to use a custom maven build command
custom_maven_exec Allows SourceClear to use a custom maven executable for scanning
scope When specified, limits dependency resolution to the specified scope

Fixing vulnerability issues

After viewing the scan results, users will likely want to fix the vulnerabilities discovered in their Maven project. SourceClear 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, pom.xml, or added to your project as a JAR file, SourceClear refers to the library as a direct dependency. Fixing a vulnerability in a direct dependency using SourceClear 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 SourceClear UI, 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 SourceClear. SourceClear 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 SourceClear 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 Nodes”vulnerability 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 SourceClear 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

  • Requirements for the SourceClear agent
  • Gradle version 2.13 or greater
  • Gradle executable installed to your path, or gradlew wrapper file included in project repository.
  • build.gradle file in the directory where the scan is to be performed
  • In your ~/.gradle/gradle.properties, make sure that any nexus servers or authentications are properly set up in order to successfully compile code

Running a scan

You can use SourceClear 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 SourceClear's 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 theSourceClear 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 SourceClear agent will then proceed to build the code in order to identify the dependencies and versions in your project. The build command 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.

Configuring scans

One of the requirements for SourceClear 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 SourceClear 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 SourceClear 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 SourceClear 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
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. SourceClear 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, build.gradle, or added to your project as a JAR file, SourceClear refers to the library as a direct dependency. Fixing a vulnerability in a direct dependency using SourceClear 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 SourceClear UI, 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 SourceClear. SourceClear 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 SourceClear 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 SourceClear 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 SourceClear 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 SourceClear 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 SourceClear 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 SourceClear 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 SourceClear 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 SourceClear 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 SourceClear to use a custom ant executable for scanning
ant_build_steps Allows SourceClear 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. SourceClear 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, SourceClear refers to the library as a “direct” dependency. Fixing a vulnerability in a direct dependency using SourceClear 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 SourceClear UI, 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 SourceClear. SourceClear 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 SourceClear 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-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, SourceClear 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 it’s usage within your code by clicking “Show full call chain”, revealing the actual line number in the project which is causing the issue: