What should you check in a live vulnerability scanner demo?

In a live scanner demo on your own repository, check ten things: which files were read, how long the scan took, how each finding is explained, whether fixes build, and what was skipped. Write each answer down, because demos are easy to forget and easy to flatter.

The checklist

Use this list with the screen share open. Each item takes about a minute.

1. Files read. Ask for the list of manifests and lockfiles the scan used. Compare it with what is actually in the repo.
2. Wall-clock time. Start a timer when the scan starts, not when the vendor says it did.
3. First screen. Ask what the top number means and what it counts. Total findings and unique vulnerable packages are different numbers.
4. One finding, traced. Pick a finding at random and ask to see the dependency path, the advisory it matched, and the affected version range.
5. Severity source. Ask which score is shown, and whether exploit data is used as well.
6. Fix path. Ask what the tool proposes, and whether it has been built and tested.
7. Noise. Ask how a finding can be marked as not relevant, and who can do it.
8. Gate. Ask to see a pull request blocked or allowed by a rule you choose.
9. Export. Ask for an SBOM and a findings export, and open them.
10. Gaps. Ask what the scan could not read or did not cover.

What a good answer sounds like

A good answer is specific and checkable. "It read these four manifests and one lockfile, and skipped this folder because of an unsupported format" is a good answer. "We support all major ecosystems" is not.

If you hear a claim, ask to see it on your screen. If the tool cannot show it, write "not shown" in your notes. That is a legitimate result.

Red flags

• The scan has already been run and the demo only shows saved results.
• The vendor picks which repository to scan.
• Questions about skipped files get a general answer.
• A finding cannot be traced back to an advisory.
• The fix is described but never opened.

None of these ends a conversation alone. Several together tell you the demo was staged.

After the demo

Within the hour, write three lines: what surprised you, what was missing, and what you would test next. Memory fades fast, and the second meeting will blur with the first.

Keep the notes in a shared document so everyone who attended can add to them. Disagreements between attendees are useful. If an engineer liked the explanation and a manager did not follow it, that is worth knowing.

Where Safeguard fits

Safeguard offers dependency scanning, SBOM generation, reachability analysis and policy gates, and you can run the free scan at gold.safeguard.sh/scan on a repository of yours to see the output format before any call. The demo below walks through a vulnerability management flow.

Try it yourself

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

Open one finding and notice whether you can see where it came from and what the next step is. That is items four and six on the list.

Quick check

Last reviewed: 19 October 2026.