IDE and CI dependency scans disagree mainly because they read different dependency trees, use vulnerability data of different ages, include different scopes, or apply different severity rules. The CI result, built from a clean install and a lock file, is normally the one of record. Align the inputs before blaming either tool.
The five usual causes
1. Different trees. The editor may resolve dependencies from a manifest on one machine, while CI installs from the lock file. If they differ, the scans cover different packages. npm's documentation notes that running audit without a lock file can give different results every run, since the tree is rebuilt each time.
2. Different data age. One tool may cache vulnerability data locally and refresh rarely. The other may fetch fresh data at every run. A new advisory then appears in one place first.
3. Different scopes. One scan may include dev dependencies, optional ones, or test only packages, and the other may not. Some builds omit development dependencies in production mode, which changes what is installed.
4. Different rules. Severity thresholds, ignored advisories, and whether unfixable findings are shown can all differ between a plugin setting and a pipeline config.
5. Different matching. Tools can map a package to an advisory with different logic, especially for packages that were renamed, vendored or repackaged.
A debugging routine
- Pick one finding that differs and write down the exact package and version in each place.
- Check whether both tools scanned the same lock file at the same commit.
- Compare the include or omit settings for dev and optional dependencies.
- Compare the timestamp of the vulnerability data each used.
- Compare the severity filter and ignore lists.
- If it still differs, run both against one frozen input, such as a lock file checked out to a clean directory.
Which one do you trust?
| Situation | Trust |
|---|---|
| CI used a frozen lock file install, the IDE did not | CI |
| IDE has newer data than the last CI run | Re-run CI, then act on the finding |
| Findings differ only in severity label | Check which rule set is current policy |
| Package is missing from one tool | Check ecosystem support and resolution |
Preventing the mismatch
- Use one policy file shared by editor, pull request and build stages.
- Keep lock files committed so all stages read the same versions.
- Show data freshness in the output so a stale result is visible.
- Treat IDE output as guidance and CI as the record, and say so in your developer docs.
When developers cannot predict CI from what they saw in the editor, they stop using the editor warnings. Consistency is worth more than an extra feature.
Where Safeguard fits
Safeguard offers VS Code and JetBrains extensions, a CLI and gates for pull requests, so the same scanning and policy can run at each stage. Try a free scan at gold.safeguard.sh/scan.
Quick check
The IDE shows a finding that CI does not. Should I ignore it?
No. First check whether CI used the same lock file and fresh data. The finding may be real and CI may simply be older.
CI shows a finding I cannot see locally. Why?
Likely a different tree or scope, for example a transitive dependency or a dev dependency that your local resolution did not include.
Sources
Last reviewed: 19 October 2026.
