Scans disagree when something differs between runs: scanner version, vulnerability data build, configuration, or the input itself, such as a lockfile or working tree. Align those four, record them in every result, and compare on the same commit. Most mismatches are explained by one of them.
The four usual causes
| Cause | How it shows up |
|---|---|
| Scanner version | A newer parser finds packages an older one skipped |
| Data build | One run used yesterday's database, the other today's |
| Configuration | Different severity threshold, exclusions or enabled rules |
| Input | Local branch has uncommitted changes, or CI installed different versions than the lockfile pins |
Each of these is reasonable alone. Together they mean a developer sees a clean IDE, a failing CI check and a platform dashboard with a third answer, and loses trust in all three.
A debugging routine
- Pick one commit. Check out exactly that commit on a clean tree.
- Compare scanner versions in the IDE extension, CI and platform. Note them.
- Compare the data build or database timestamp for each run.
- Print the effective configuration for each, including exclusions.
- Compare the dependency inventory, not the findings. If inventories differ, the cause is in resolution or parsing. If they match but findings differ, the cause is data or policy.
- Fix the lowest layer first: input, then version, then data, then configuration.
How to prevent it
- Use the same scanner engine across surfaces where you can, so parsing is identical.
- Distribute scanner version from one source, and publish the supported range.
- Make lockfiles authoritative. Fail the build if installed versions differ from the lockfile.
- Share configuration through the repository or organisation defaults, so IDE, CI and platform read the same policy.
- Expect small timing differences from the data, and design the gate to run in CI and the platform, with the IDE as an early hint.
- Show scanner version and data build in every output, including the IDE panel.
What is acceptable to differ
The IDE should be fast and approximate. It may skip heavy analyses and use cached data. CI is the authoritative gate. The platform is the system of record and re-evaluates over time, so its findings may include new advisories that appeared after the CI run. Tell developers this, so a later finding on unchanged code is understood as new data, not a bug.
Try it yourself
Click through it at your own pace, or open it full screen. See how a code scan reports findings you can then compare across surfaces.
Safeguard offers extensions for VS Code, JetBrains and Open VSX, a CLI, and a desktop app, which share the same platform. You can try the free scan at https://gold.safeguard.sh/scan.
Quick check
Which result should win?
The CI gate decides merges, and the platform is the record over time. The IDE is an early signal.
What is the quickest comparison to run?
Compare the dependency inventories. Differences there point to parsing or resolution, not to vulnerability data.
Last reviewed: 19 October 2026.
