JavaScript Scanning

SourceClear Software Composition Analysis

Finding Vulnerabilities in JavaScript repositories

Finding vulnerabilities in your JavaScript repositories using SourceClear is simple. In the following section, you will find steps for running a SourceClear scan on npm, Yarn and Bower repositories using the SourceClear Command Line Interface, but scanning can be performed by any of our CI Integrations as well.

NPM Requirements

Note: In order to scan for NPM dependencies, the agent utilizes the shrinkwrap command. For agent hosts with NPM versions 2.7 or earlier, shrinkwrap is not supported, in which case SourceClear will report all dependencies for a given repository including devDependencies.

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-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 SourceClear 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 SourceClear 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 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 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. 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, 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.

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 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 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. As an example, the following provides fixes for a “Timing Attack Via Signature Validation” vulnerability in cookie-signature, version 1.0.3 in the example-javascript repository.

Note: Fixing vulnerabilities in transitive dependencies in NPM repositories requires NPM version 3.10.4 or higher (fix details here).
  1. After having run a scan with SourceClear or having ran npm install to install dependencies (indicated by the existence of a node_modules folder), run the following command in the same directory as your package.json file:
    npm shrinkwrap
  2. Running the previous command will generate a npm-shrinkwrap.json file with all of the dependencies currently in use. 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 to update to is 1.0.4. Edit the npm-shrinkwrap.json file to update the cookie-signature library like the following:
    "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"}
  3. Delete the node_modules folder, then run npm install to download the updated dependency and ensure the updated version works with your project.

    Once you have completed these steps, validate the fix.

Yarn Requirements

  • Requirements for the SourceClear agent
  • NPM 2.10.0 or higher installed on the local path
  • yarn.lock file included in repository to be scanned
  • package.json file included in repository to be scanned, in the same directory as the yarn.lockfile
  • Yarn installed through NPM and located on local path

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-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 SourceClear 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 SourceClear 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 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 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. 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, 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.

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 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 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 transitive vulnerability, the dependency will need to be installed as a direct dependency. To do this run the folllowing commands:

yarn add express@4.5.0
yarn install --flat
Once you have completed these steps, validate the fix.

Bower Requirements

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-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 SourceClear 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 SourceClear agent will then proceed 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 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 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. 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, 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.
For example, the following provides fixes for an “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 to match the following:
"ember": "1.2.2"
After editing your bower.json, enter the following command to install ember version 1.2.2:bash bower update ember 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 bower involves overriding the transitive dependency by specifying how the dependency is resolved. As an example, the following provides fixes for an “Cross-Site Scripting (XSS) Through Execution Of Non-Explicit Data Type” 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 “resolution” section as shown:

"dependencies": {
          ...
         "jquery": "1.12.0",
          ...
},
"resolutions": {
          ...
         "jquery": "1.12.0",
          ...
}
Once you have updated your bower.json, download the updated jquery library by running the following command: bash bower update jquery

Once you have completed these steps, validate the fix.

Validating a fixed vulnerability

Validate the fix you have made to your repository by running a SourceClear scan prior to committing your code changes by adding the --allow-dirty option to ignore uncommitted changes within your code:
srcclr scan /path/to/example-project --allow-dirty

Once you have verified the vulnerability no longer shows up in the scan output, you can proceed to commit your code and you will have fixed the vulnerability!