Scanning Javascript in IQ Server

IQ Server | Reading time: 7 minutes

Is this article helpful?

The IQ Server team has been on a mission to make scanning JavaScript (JS) awesome—expanding our JS capabilities to provide more context and reliable details to developers. The goal of this change is to iterate on our approach and incorporate more data that increases the accuracy of our results.

This helps you be more successful by providing clear results you can use to take decisive action with regard to your existing JavaScript projects and applications. Because the JS scans provide accurate and relevant information, you can expect decreased time required to understand why a given component is listed, and less time and effort necessary to understand how to take action.

Expanded capabilities

Starting in January 2020, we’re adding capabilities to the Javascript scanning in IQ to complement A-name matching. The basis of A-name matching is that it scans at the file-level rather than at the package-level. We’re extending A-name by including package.json metadata, incorporating more details and findings into our scans, and in turn, increasing the fidelity of our results. Using package.json files for matching means we can provide improved accuracy of components and versions listed in the report and better clarity of your build and what is included.

With this new matching, it’s important to note that we are working with a combination of approaches to arrive at the most meaningful result. We are still performing file hash-based matching, only now we use the package.json metadata as a strong hint of what to match to. This is an advantage over simpler solutions because you still get the benefits of features like our fine-grained, file-level vulnerability data.

For example, if you have File A from Package Foo, and Package Foo also has a File B that is vulnerable, but your application doesn’t contain File B, we won’t raise an alert about that vulnerability. (See Figure 1).

Example JavaScript scan

Figure 1: JavaScript scan example

The following list gives a bit more detail around the improvements that have taken place in how IQ Server scans and matches JS components:

  • We enhanced our scan and match approach to include package.json files alongside the file system scan, helping us produce more accurate findings. Using package.json means we can more accurately find the exact known version and name of a component.
  • For developers building webpack applications, our copy-modules-webpack scanning plugin was updated to include these changes. The Sonatype team highly recommends our customers use this plugin for this purpose.
  • A-name matching will still be used for any JavaScript files that could not be identified using the new package.json matching, for example in the event that no package.json files were provided in the scan.

Get started — scan, report, & remediate

There are several ways to scan JavaScript in the IQ Server—for example, using the CLI, setting up a scan with your CI server (Jenkins), or scanning in the UI. For the purpose of this guide, we will go through an example of how to scan JS with the IQ CLI.

CLI scan example

Note: The following example uses IQ Server release 82. Beginning in January 2020, all scans with updated scanner clients will yield the new JavaScript results. For a list of updated scanner clients, see the best practices section.

To get the new JavaScript results, you need to include package.json files in your scan. If you do not include the package.json files, the new code will not activate and the system will fall back to A-name matching. Start a CLI scan that includes your node_modules directory (or the output directory from the copy-modules-webpack-plugin) ensuring that it will pick up the package.json files of all your JavaScript dependencies. For example:

java -jar ./nexus-iq-cli-<version>.jar -i Test123 -s http://localhost:8070 -a username:password -t release my_project/

The example above shows the command line for an Application ID Test123 and an IQ Server URL of http://localhost:8070. Replace in the jar file path with your version of the CLI.

More detailed instructions on running a CLI scan can be found in our Nexus IQ CLI help documentation.

Best practices

The Sonatype team recommends you use the copy-modules-webpack-plugin to build. This lets you isolate the JavaScript files that are being included in your application bundle. Remember to include your package.json files when configuring the plugin. For specific details on this configuration, see includePackageJsons.

If waivers were formerly applied to your results, they will have to be re-applied as the hash is now different, identifying a “new” (NPM) component. This requires re-applying the waiver.

If you are doing a CI scan with Jenkins, you will need to set up your pipeline build to pick up the package.json files. For more information on how to do this, see the Advanced Step Options section of our Nexus Platform Plugin for Jenkins help documentation.

To get the updated, more accurate JavaScript results, you will need to use newer versions of scanner clients:

Note: IQ Server is listed here in its capacity as a scanner (for example, when you use the file upload feature in the IQ user interface). If you have an older version of IQ, but do a scan with an adequately new version of another client, you will still see the new JavaScript results.

Viewing the report

Because we are leveraging the metadata from the package.json files, the identified files will be correctly grouped into components, potentially reducing the number of distinct components identified. This could reduce the number of violations shown and provide more context and clearer details for investigation.
Example JavaScript npm scan JQuery Scan: package.json (new method)
The new matcher is able to
accurately determine which
files are part of each
component identification,
creating clarity and reducing
noise.
Example JavaScript A-name scan JQuery Scan: A-name (old method)
A-name identifies files
individually and then makes
a best-effort attempt
to group those identifications.

The application composition report is a great place to begin understanding your risk based on data. This data is generally found in the Component Information Panel or CIP, which is available from the IQ Server UI and also in our IDE integrations. Information provided in the CIP helps you investigate better components based on newer available versions, most popular versions, and security and licensing issues. For more information on the report, please see our help documentation on the Application Composition Report and the CIP.

Remediating violations

Successful risk management is the process of identifying vulnerabilities and threats and then deciding what actions you can take to reduce those risks and reach your goals. Remediating risks found in your JavaScript applications follows the same path as any other violations found with an IQ Server scan.

In general, policy resolution can be achieved by completing one of the following tasks:

  • Upgrade to a non-vulnerable version of the same component. This option is most recommended because it is generally the easiest path to resolution and reducing your risk.
  • Migrate to a component that does not contain the violation. If you’re not able to upgrade your component, the next step is to migrate to a similar component without the violation. This option involves research because you’re looking for a replacement component that provides the same functionality while ensuring it’s not exploitable.
  • Request a waiver for the policy violation. If you can’t upgrade or migrate, the next option is to request a waiver. Send a waiver request to the Project Owner with enough information for a determination to be made. Remember—applying a waiver assumes a certain amount of technical debt, and does not fix the violation, so use it appropriately.

For further help with remediation, please see our Getting Started with IQ Server Remediation guide and video series.

Resources

Need more help? We have you covered: