Some scanners include development and test dependencies and some skip them, and many let you choose. When two tools disagree on a count, scope is a common cause. Decide whether you care about what ships or what builds, set both tools to match, and then compare.
What scope means in two ecosystems
In npm, development dependencies are packages needed for development, such as test frameworks or build tools, not by people who use your package. The npm documentation says npm installs them during a normal install from the package root. Optional and peer dependencies have their own rules too.
The npm audit documentation says the omit setting controls which dependency types are skipped, and that omitted types are left out of the report. So an audit run with dev packages omitted will show fewer findings than one that includes them.
In Maven, scope limits how a dependency is used and where it appears. The Maven dependency mechanism guide says test scope is available only for test compilation and execution and is not transitive. Provided is expected from the JDK or a container and is also not transitive. Runtime is needed for execution but not for compilation.
Why this makes two reports differ
| Tool setting | What appears in the report |
|---|---|
| Includes all scopes | Test and build packages alongside shipped ones |
| Omits dev or test | Only what the runtime needs |
| Reads the lockfile | Whatever the lockfile records, with its own scope markers |
| Reads the manifest | Direct dependencies only, unless it resolves the tree |
A scanner that includes everything can show findings in a test runner that never reaches production. A scanner that omits scope can hide a build tool problem that matters if your build machine is a target.
Which scope should you count?
Both views have a use, so keep both and label them.
- Shipped scope answers what customers receive. Use it for release gates and customer facing reports.
- Build scope answers what runs in your pipeline. Treat it as a supply chain risk to the build system, which is a different priority list.
Do not mix the two in one number. A single figure that blends shipped and build findings is hard to act on, and it makes two tools look further apart than they are.
Steps to align two tools
- Write down the scope each tool uses by default. Read its documentation rather than guessing.
- Set both to the same scope for the comparison. For npm audit, use the omit option to match.
- Rerun and compare. Most of the gap often disappears.
- Keep a separate run for build scope, reported under its own heading.
If the remaining gap is small, move on to the next cause, such as version resolution or advisory data.
A caution about the shipped artifact
Scope settings describe intent. The built artifact tells you the truth. A bundler can pull a development package into a production bundle by mistake, and a manifest will not show that. When the stakes are high, scan the artifact you actually deploy, not only the manifest.
Quick check
Should I ignore findings in dev dependencies?
Not ignore, but rank lower. They matter for build security, and they sometimes end up in shipped bundles by accident.
Does npm audit skip dev packages by default?
The documentation says omit defaults to dev only when the environment is set to production, and is otherwise empty. Check your own environment and flags.
Sources
Last reviewed: 19 October 2026.
