npm audit includes devDependencies unless you tell it to leave them out. Using the omit option, or the production shorthand, removes those packages from what npm sends to the registry. The two choices answer different questions, so know which one your CI runs.
What npm audit does
The npm audit docs describe a simple flow. It submits a description of your dependency tree to the registry's bulk advisory endpoint and reports advisories that match. Two details from the docs matter here:
- Packages in the tree that have no version field in their package.json file are ignored.
- If any omit options are specified, whether through the omit config or shorthands such as the production flag, packages are omitted from the submitted payload as appropriate.
So whether dev dependencies are checked depends on the omit setting at the time you run it.
When omit is set for you
The npm config docs describe the omit default: it is dev if the NODE_ENV environment variable is set to production, and otherwise empty. That means two runs of the same command can behave differently.
| Environment | Omit value | Dev packages checked |
|---|---|---|
| Laptop, NODE_ENV unset | Empty | Yes |
| CI job with NODE_ENV set to production | dev | No |
| Command run with the production option | dev | No |
If your pipeline sets NODE_ENV to production for the build, your audit step may be skipping dev packages without anyone choosing that.
Two useful audits
Each choice answers a different question.
# Full tree: what is installed on a developer machine or build runner
npm audit
# Shipped code only: what is installed in production
npm audit --omit=dev
The full tree matters because build tools run on your machines and in your CI, where a compromised or flawed package can do harm. The production audit matters for the code your customers run. Run both if you can, and label the results.
Interpreting the difference
A finding that shows up only in the full audit is in a dev dependency. It is real in the tree, and may not ship. The npm docs say omitted types are still resolved and added to the lockfile, they are just not physically installed. So the lockfile can show a package that production never has.
That does not make dev findings safe to ignore. See whether dev dependencies matter for supply chain security.
Make the setting explicit
Do not rely on an environment variable to decide your audit scope. Write the flag in the pipeline step, with a comment on why. Add a second step for the other scope, and report them separately.
Quick check
Why does npm audit show different results in CI?
CI may set NODE_ENV to production, which makes the omit default dev. Compare the environment and flags between the two runs.
Does omitting dev packages remove them from the lockfile?
No. The npm docs say they are still resolved and recorded in the lockfile, but not installed.
Should I audit dev dependencies at all?
Yes, as a separate scope. They run on developer and build machines, so a flaw there still matters.
Safeguard offers dependency scanning with SBOM output and reachability analysis, and the free scan lets you try it on your own project.
Sources
Last reviewed: 19 October 2026.
