Table of Contents
- Application Scanning Techniques
- Enhanced Capabilities
- Getting Started
- Viewing the Report
- Remediating Violations
- Additional Resources
- Talk to Us
Application Scanning Techniques
Manifest scans use the project’s build file to identify dependencies and policy violations. They rely on coordinate-based matching to determine which components the project uses. Since manifest scans don’t need the actual files to scan an application, this is an effective way to scan applications when dependency files are unavailable.
The figure above shows an example of A-name matching. The software project contains package foo. Package Foo contains two files, File A and File B. There is a known security risk in File B but File B is not used in the project. The A-Name scan won’t include the vulnerability in File B in the scan results, as the vulnerability is not in the application.
package.json for each dependency in the
node-modules folder to help identity the file’s parent component. This allows us to accurately group matched files together by component. The component coordinates from the
package.json file and the consistent structure of
node_modules directories make this grouping more accurate than the heuristic grouping done by the A-name algorithm.
If the scanned application does not include a
package.json or other build file, the scan will default to the A-name matching. IQ Server performs a file level scan whenever possible. When the scan does not include the code files for a project’s dependencies, IQ server will use the application’s
package-lock.json or other manifest file and attempt to identify dependencies based on it. This way, a scan still provides meaningful results at all stages of the development process. These improved results should make fixing policy violations quicker and easier. IQ Server can use a variety of build files including
npm-shrinkwrap.json files for manifest scans.
The scan results indicate if the new scanning method was used in your scan or if the scan used A-name matching. See the NPM Application Analysis documentation and the report section below for more details.
For Webpack Developers
The webpack plugin is an OSS offering that is not officially supported by Sonatype.
package.json files when configuring the plugin. Check out includePackageJsons for more configuration info.
Disabling Improved Scans
Scanning with the CLI
package.json files in each dependency in your scan. If the
package.json is not included the system will revert to A-name matching.
To start a CLI scan that includes your
node_modules directory or the output directory from the
copy-modules-webpack-plugin run the command below. The example command uses the Application ID Test123, an IQ Server URL of http://localhost:8070, and an unspecified CLI version. Substitute your CLI Version, IQ Server address, and file path to your project. Check out the Nexus IQ CLI help section for more information on running this command.
java -jar ./nexus-iq-cli-<version>.jar -i Test123 -s http://localhost:8070 -a username:password -t release my_project/
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, see the Advanced Step Options section of our Nexus Platform Plugin for Jenkins help documentation.
- Sonatype CLM for Maven plugin
- IQ Server
- IQ CLI
- Nexus IQ for Bamboo
- Nexus Platform Plugin for Jenkins
Viewing the report
After scanning an application, you will be able to access the Application Composition Report for your scanned application. This report is a great starting point to assess an application’s risk. A summary of scan results will be visible from a command line scan along with a link to view the Application Composition Report in the IQ Server UI. The report helps you find better components by providing information on newer versions, identifying the most popular versions, and providing details about security and license risks. Clicking on an item in the Application Composition Report will open the Component Information Panel which shows highly detailed information about each scanned component. Check out the our help pages for the Application Composition Report and the CIP to learn more.
package.json (new method)
The new matcher is able to
accurately determine which
files belong to each
component, making the scan
clearer and easier
A-name (old method)
A-name matching lists
files individually and
attempts to group those vulnerabilities together.
The resulting groups are
less accurate than the
components identified using
the new scanning method.
Fig 1: The Type metadata field indicates the component was identified using A-name matching.
Fig 2: The figure above, the Type metadata field indicates the component was identified using the enhanced npm scanning capabilities.
In general, you can resolve policy violations by doing one of the following:
- Upgrade to a non-vulnerable version of the same component. This usually the best option and the easiest path to resolving the violation.
- Migrate to a different component without a policy violation. If you’re not able to upgrade a component, the next step is to migrate to a similar one. This option takes more time and research. You’re looking for a replacement that provides the same function as the existing component without the risks. Fixing components this way might also take some time to adjust your code for slight differences between the old component and the new one.
- Request a waiver for the policy violation. If you can’t upgrade or migrate, then your last option is to request a waiver. Send a waiver request to the Project Owner and provide enough information for them to understand why this component needs a waiver. Remember that applying a waiver creates a technical debt and does not fix the violation. Use waivers sparingly.
For further help with remediation, please see our Getting Started with IQ Server Remediation guide and video series.
Talk to Us
And visit my.sonatype.com for all things Sonatype.