How does an SCA scan work, step by step?

An SCA scan works in four steps: detect the files that declare dependencies, resolve the exact packages and versions, match them against vulnerability and license data, and report the results with fix guidance. Each step can fail in its own way, which is why it helps to test them separately when you choose a tool.

Step 1: Detect

The scanner looks for files that declare dependencies: manifests such as package.json or pom.xml, and lockfiles such as package-lock.json. The npm documentation describes the lockfile as recording the exact tree that was generated, so later installs get the same result. A scanner that reads only the manifest sees ranges, not the versions you actually run.

What can go wrong: unusual build systems, files in nested folders, and dependencies fetched during a build are easy to miss.

Step 2: Resolve

Next the tool works out the full tree, including transitive dependencies, and assigns each package an identity. The Package-URL specification gives packages a standard identifier built from ecosystem, name, and version, and it is used by SBOM formats and by vulnerability databases such as OSV.

What can go wrong: without a lockfile, the tool has to guess which version a range would resolve to.

Step 3: Match

The inventory is compared with advisory data. The OSV format records, for each affected package, ranges with events such as introduced and fixed, so a version either falls inside a range or it does not. OSV aggregates sources including the GitHub Advisory Database and several ecosystem databases, which is why many tools build on it.

What can go wrong: stale data, a package with no advisory yet, or a match made by loose name rather than ecosystem and version.

Step 4: Report and enrich

The tool shows findings with severity, fixed versions, and often extra signals. CISA describes its Known Exploited Vulnerabilities catalog as an input to vulnerability management prioritization, and FIRST publishes EPSS scores that estimate likelihood of exploitation. Some tools also add reachability, which asks whether your code can call the vulnerable function.

What can go wrong: severity alone floods the queue, and a fix suggestion may ignore breaking changes.

A test for each step

A worked example: one dependency from file to finding

Say a Node.js service declares a dependency on a package at a caret range, and its lockfile pins the resolved version to 4.17.20 of a utility library.

1. Detect: the scanner finds the manifest and the lockfile.
2. Resolve: it reads the lockfile entry, records the package with its ecosystem, name, and version, and builds the tree to show who depends on it. Maybe a framework brings it in two levels down.
3. Match: it looks up that package and version in advisory data. An advisory says versions below a stated fixed version are affected, and your version is below it, so the tool records a match.
4. Report: the finding shows the advisory identifier and its aliases, severity, the fixed version, and the path through your tree. If the tool does reachability analysis, it also states whether your code calls the affected function.

At each hop there is something you can inspect, which is the basis for a fair evaluation.

Step by step: run a scan and read it critically

1. Pick a repository you know and commit the lockfile.
2. Run the scan and save the raw output.
3. Pick five findings and for each follow the path from your manifest to the vulnerable package.
4. Open the advisory for each and confirm the affected range includes your version.
5. Check whether the fixed version exists in your ecosystem and whether the upgrade is a patch, minor, or major change.
6. Note any finding where you cannot tell why it matched.

Where scans differ between tools

Tools differ most in detection coverage, in how they handle missing lockfiles, in which advisory sources they merge, and in what they add after matching. Some stop at a list of findings. Others rank them using exploited-in-the-wild data, exploit likelihood estimates, and reachability, and some propose or open fix changes.

Those later steps are where a lot of the value and the marketing claims sit, so test them with your own code.

What a scan does not do

A scan does not run your code, does not prove a package is safe, and does not know about flaws that have no record yet. It also does not know how your service is deployed, so it cannot tell you by itself whether a flaw is exposed to the internet. Those are reasons to pair it with context, reachability, and human review.

Timing

Steps one and two can run at build time. Steps three and four can run any time you have a stored inventory, since only the advisory data changes. That is why rescanning without rebuilding is possible, and why a tool that stores inventories can alert you to a new advisory the same day it appears in its data.

Make the steps visible to your team

Developers trust a tool more when they can see why it said something. Ask that each finding show the path, the advisory, the matched range, and the fix. If any of those are missing, expect questions in the pull request.

Try it yourself

Click through it at your own pace, or open it full screen.

Follow one component from the inventory to its findings, and name the step each screen represents.

Quick check

Sources

• npm package-lock.json documentation
• Package-URL specification
• OSV data sources
• CISA Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System

Last reviewed: 19 October 2026.