About JavaScript SCA Agent-Based Scanning

Veracode Software Composition Analysis

You can find vulnerabilities in your JavaScript applications using Veracode Software Composition Analysis agent-based scanning. You can run a scan on NPM, Yarn and Bower 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 JavaScript and TypeScript Applications.

NPM Requirements

  • Meet the requirements for the Veracode SCA agent.
  • Have NPM 2.10.0 or later installed on the local path.
  • Include the package.json, package-lock.json, or npm-shrinkwrap.json file in the repository to scan.
  • If neither npm-shrinkwrap.json nor package-lock.json exist, be able to run the npm ls 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 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-javascript
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 away:

# Replace "example-javascript" with the project folder name of your choosing
srcclr scan path/to/example-javascript

To view more verbose output during the scan process, you can add the --loud argument as well:

srcclr scan path/to/example-javascript --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 NPM is:

npm install
npm ls --json

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, 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 NPM code. The following are configuration options which can be used within your srcclr.yml for NPM scanning:

Directive Description
scope Specifies scope of dependency resolution

Fixing Vulnerability Issues

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

Fixing a Direct Vulnerability

When your configuration file specifically references a library, 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 that Veracode SCA recommends. 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 a “Cross-site Scripting (XSS) Using Non-standard Encodings” vulnerability in Express, version 4.1.1 in the example-javascript respository.

To fix this direct vulnerability, edit the package.json file in the root of the project by running the following command:

npm install express@4.5.0 --save

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 vulnerability in a transitive library for NPM can be more tricky than fixing a direct vulnerability because NPM projects allow for multiple versions of the same library which means you cannot override a vulnerable library by adding the appropriate version directly to the configuration file. The following example provides fixes for a Timing Attack Via Signature Validation vulnerability in cookie-signature, version 1.0.3 in the example-javascript repository. In the example, the recommended version of cookie-signature is 1.0.4.

After running a Veracode SCA agent-based scan or running a npm install to install dependencies, which is indicated by the existence of a node_modules folder and a package-lock.json file:
  1. Add this resolutions section to your package.json file:
    "resolutions": {
      "cookie-signature": "1.0.4"
    }

    If a resolutions section already exists, add "cookie-signature": "1.0.4" to it.

  2. Add this scripts section to your package.json file:
    "scripts": {
      "preinstall": "npx npm-force-resolutions"
    }

    If a scripts section already exists, add "preinstall": "npx npm-force-resolutions" to it. This change makes the npm install command force the version resolution of the cookie-signature library to 1.0.4 according to the resolutions section using the NPM Force Resolutions package.

  3. Delete the node_modules folder.
  4. Run the npm install command to download the updated dependency and ensure the updated version works with your project.

If you encounter problems using the NPM Force Resolutions package as in the above example, you can use this alternative method that requires NPM version 3.10.4 or later. After running a Veracode SCA agent-based scan or running npm install to install dependencies, which is indicated by the node_modules folder:

  1. Run the npm shrinkwrap command in the same directory as your package.json file.

    This command generates a npm-shrinkwrap.json file with all of the dependencies currently in use.

  2. Find the cookie-signature library with the version specified in the issue details viewed previously. In this example, version 1.0.3 is vulnerable and the recommended version is 1.0.4.
  3. Edit the npm-shrinkwrap.json file to update the cookie-signature library:
    "cookie-signature": {
      "version": "1.0.4",
      "from": "cookie-signature@1.0.4",
      "resolved": "https://registry.npmjs.org/cookie-signature/-/cookie-signature-1.0.4.tgz"
    }
  4. Delete the node_modules folder, then run the npm install command to download the updated dependency and ensure the updated version works with your project.

Yarn Requirements

  • Meet the requirements for the Veracode SCA agent.
  • Have NPM 2.10.0 or later installed on the local path.
  • Include the yarn.lock file in the repository to scan.
  • Include the package.json file in the repository to scan, in the same directory as the yarn.lock file.
  • Have Yarn installed through NPM and located on the local path.

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-javascript-yarn
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-javascript-yarn" with the project folder name of your choosing
srcclr scan path/to/example-javascript-yarn

To view more verbose output during the scan process, you can add the --loud argument as well:

srcclr scan path/to/example-javascript-yarn --loud

The Veracode SCA agent proceeds to build the code in order to identify the dependencies and versions in your project. The build command for Yarn is:

node -e var fs= require('fs'); \
  var parse= require('../lib/lockfile/parse.js').default; \
  var contents= fs.readFileSync('/path/to/example-javascript-yarn/yarn.lock', 'utf8'); \
  console.log(JSON.stringify(parse(contents)));

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 JavaScript code. The following are configuration options which can be used within your srcclr.yml for yarn scanning:

Directive Description
scope Specifies scope of dependency resolution

Fixing Vulnerability Issues

After viewing the scan results, users will likely want to fix the vulnerabilities discovered in their Yarn project. Veracode SCA 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, 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.

For example, the following provides fixes for a “Cross-site Scripting (XSS) Using Non-standard Encodings” vulnerability in Express, version 4.1.1 in the example-javascript-yarn project.

To fix this direct vulnerability, edit the yarn file in the root of the project by running the following command:

yarn upgrade express@4.5.0
yarn install --flat

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 vulnerability in a transitive library for Yarn can be more tricky than fixing a direct vulnerability because Yarn projects allow for multiple versions of the same library which means you cannot override a vulnerable library by adding the appropriate version directly to the configuration file. As an example, the following provides fixes for an “Timing Attack Via Signature Validation” vulnerability in cookie-signature, version 1.0.3 in the example-javascript-yarn repository.

To fix this direct dependency vulnerability with Yarn 1.0 or later:
  1. Add this resolutions section to your package.json file:
    "resolutions": {
      "cookie-signature": "1.0.4"
    }

    If a resolutions section already exists, add "cookie-signature": "1.0.4" to it.

  2. Run the yarn install command.
To override the dependency version with Yarn versions earlier than 1.0:
  1. Run this command to install cookie-signature library 1.0.4:
    yarn add cookie-signature@1.0.4
  2. Run this command and, when prompted, choose the latest version:
    yarn install --flat
After completing these steps, build, test, and rescan your project to ensure the fix succeeded.

Bower Requirements

  • Meet the requirements for the Veracode SCA agent.
  • Have Bower installed on path.
  • Include the bower.json file in the repository to scan.
  • Be able to run bower install and, then, the bower list command from the root of the project where you performs scans. For both commands, use the --allow-root flag when the user is the superuser (root) by setting the allow_root scan directive or the SRCCLR_ALLOW_ROOT environment variable to true.

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-javascript-bower
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 away:

# Replace "example-javascript-bower" with the project folder name of your choosing
srcclr scan path/to/example-javascript-bower

To view more verbose output during the scan process, you can add the --loud argument as well:

srcclr scan path/to/example-javascript-bower --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 Bower is:

bower install
bower list --json

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 JavaScript code. The following are configuration options which can be used within your srcclr.yml for Bower scanning:

Directive Description
scope Specifies scope of dependency resolution
allow_root Using this directive and setting it to true will instruct Bower to use the --allow-root flag.

Fixing Vulnerability Issues

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

Fixing a Direct Vulnerability

When your configuration file specifically references a library, 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.
For example, the following provides fixes for a Cross-site Scripting (XSS) Through link-to Title Attribute vulnerability in Ember, version 1.2.0 in example-javascript-bower repository.
To fix this direct vulnerability, edit the bower.json file in the root of the project and add this line:
"ember": "1.2.2"
After editing your bower.json file, enter this command to install Ember version 1.2.2:
bower update ember
After you have completed the installation, validate the fix.

Fixing a Transitive Vulnerability

Direct dependencies often depend on other libraries called transitive dependencies. Veracode SCA informs you if a library that you add to your project depends on a vulnerable library. Additionally, it provides the version of the dependency to which you must upgrade.

To find details on these issues, clear the Direct only checkbox on the Library table in the Veracode Platform. To view the issue details, including the library type, click the issue number on the Issues table.

Fixing a transitive library for Bower involves overriding the transitive dependency, which requires that you specify how to resolve the dependency. This example provides a fix for a Cross-site Scripting (XSS) Vulnerability in the jquery library vulnerability in jQuery version 1.10.2 in the example-javascript-bower repository.

To fix this transitive vulnerability, add the appropriate version of jQuery to the bower.json file with a defined resolutions section:

"dependencies": {
          ...
         "jquery": "1.12.0",
          ...
},
"resolutions": {
          ...
         "jquery": "1.12.0",
          ...
}
After you have updated your bower.json file, run this command to download the updated jQuery library:
bower update jquery 

After you have completed the download, validate the fix.

Fixing a Vulnerable Method

Veracode SCA supports vulnerable method analysis for NPM packages using the NPM and Yarn package managers. It does not support vulnerable method analysis with Bower.

If a project is using a vulnerable method, the project is calling the specific piece of code that causes a library to be vulnerable. This distinction indicates increased urgency to address the issue, compared to other vulnerabilities where your project might not be using the vulnerable part of the code.

In the Veracode Platform, you can select the Vulnerable methods checkbox on the Issues list for your project to display only vulnerabilities where a vulnerable method is in use.

On the Issue page for a vulnerability in which a vulnerable method is in use, Veracode SCA provides the full call path for every instance of the vulnerable method. You can use this information to evaluate the importance of the vulnerability based on the usage in your project. You can, then, edit your code, instead of updating the library to fix the vulnerability.

For example, the example-javascript-vulnerable-methods repository includes the Regular Expression Denial Of Service (ReDoS) vulnerable method in the marked library. The Vulnerable Methods tab indicates which method makes this library vulnerable. You can view details on its usage within your code by clicking Show full call chain. The call chain displays the line number that causes the issue in the project.