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).
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.jsonfiles alongside the file system scan, helping us produce more accurate findings. Using
package.jsonmeans 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.
package.jsonmatching, for example in the event that no
package.jsonfiles were provided in the scan.
Get started — scan, report, & remediate
CLI scan example
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
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
More detailed instructions on running a CLI scan can be found in our Nexus IQ CLI help documentation.
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.
- Sonatype CLM for Maven plugin: 2.15.0-01
- IQ Server release 76
- IQ CLI release 76
- Nexus IQ for Bamboo: 1.14.2-01
- Nexus Platform Plugin for Jenkins: 3.8.20191127-111424.5d61f82
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.
|JQuery Scan: package.json (new method)
The new matcher is able to
accurately determine which
files are part of each
creating clarity and reducing
|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.
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.
Need more help? We have you covered: