Under the Hood: Sonatype's Enhanced JavaScript Analysis

Overview

Unlike many of our competitors, Sonatype's JavaScript component analysis does more than a simple scan of component manifest files (e.g. package-lock.json, yarn.lock, etc.).  The Sonatype scanner does not assume a JavaScript component listed in a build manifest contains every known vulnerability associated with it. Our scanner also looks at actual JavaScript files present in the application. It confirms which files match the official package and then reports vulnerabilities only for those specific, verified files. This precise "hash-based" approach prevents false positives by ignoring unrelated files or irrelevant vulnerabilities. 

Note: Recent updates as of December 16th 2025 have further enhanced the system's ability to detect dependencies that are deeply nested or obscured. You may see additional violations in scans done after that date due to these new, enhanced detection capabilities

Example of Matching

If a scan finds a /package.json for jquery@3.4.1 and finds three candidate files (file1.js, file2.js, random.js):

• The system looks up the known hashes for jquery@3.4.1 (e.g., 0002 and 0003).
• It checks the candidates:
  • file1.js (hash 0002) ✓ Matches
  • file2.js (hash 0003) ✓ Matches
  • random.js (hash 0666) ✗ Does NOT match
• The result is a definitive identification of jquery@3.4.1 with only file1.js and file2.js attached. The other file, despite being nearby, is excluded because its hash is unknown to that package.

Security

The security detection process for package.json matching is specifically designed to report vulnerabilities for only the files that were actually matched by hash, rather than all known vulnerabilities for the package's coordinates (name and version).

The flow involves a hash-based lookup:

1. Match Creation: package.json matching is completed, creating matches for the nearby files for which SHA1 hashes matched the known official hashes for the package. Each match is associated with a file hash.
2. Hash Collection: The system collects the SHA1 hashes of all the identified (matched) files.
3. Vulnerability Lookup: Vulnerabilities are retrieved for the collected file hashes, not the package coordinates.
4. Reporting: Only vulnerabilities associated with those specific, verified file hashes are reported.

This design means that if a package version (e.g., jquery@3.4.1) has ten known vulnerabilities, but only three of its files are present and matched in your scan, the system will only report the vulnerabilities tied to those three specific file hashes.

This is described as hash-based vulnerability lookup with coordinate-based identification. It contrasts with Manifest Matching, which queries by package coordinates and returns all vulnerabilities for the declared package version regardless of which files are present.

Obscured Dependencies

Infrequently, projects will nest dependencies in such a way that obscures their association with the top-level dependencies. As of December 16, 2025, we have made further improvements to our analysis to disclose these previously obscured dependencies.