How do you trace one finding end to end in a scanner demo?

Pick one finding at random and ask the demo to show six things in order: the file it came from, the dependency path, the advisory, the affected version range, why your version matches, and the proposed fix. A scanner that can do this in two minutes is explaining its work, not just reporting.

Why one finding beats a hundred

Dashboards are built to impress at a glance. A single traced finding is harder to fake. It forces the tool to show its evidence chain, and it lets you check the chain against sources you trust.

Choose the finding yourself. Do not accept the vendor's pick, and do not choose the top item, which they have probably rehearsed. Scroll and click on something in the middle.

The six checkpoints

1. Source file. Which manifest or lockfile did the package come from? You should be able to open that file in your editor and find the line.
2. Dependency path. Is it a direct dependency, or pulled in by something else? The tool should show the chain, not just the package name.
3. Advisory. Which published record does the finding match? A link to the original entry, not only a vendor summary, lets you read it yourself.
4. Affected range. The advisory states which versions are affected and which version fixed the issue. Open source advisory formats such as the OSV schema record this as ranges with introduced and fixed events (see Sources), so the tool should be able to show them.
5. Match logic. Why does your installed version fall inside the range? Ask for the installed version and the range side by side.
6. Fix. What version does it suggest, and does that version satisfy your other constraints?

What to verify yourself

While the vendor talks, open the advisory in a second tab. Compare three details with what the tool shows: the package name, the affected range, and the fixed version. If they differ, ask why. Sometimes the tool uses a newer or more specific record, which is fine. It should be able to say so.

Then open the lockfile and confirm the installed version. A mismatch between the version in the manifest and the version actually locked is a classic source of wrong results.

Where tools often fall short

• The path stops at the first level and hides the chain.
• The advisory link goes to a vendor page that restates the entry.
• The fix suggestion ignores a version constraint elsewhere in the project.
• The tool cannot say whether the package is used at runtime or only in tests.

Each of these is a question for the follow-up email, not a reason to reject the product on the spot.

Where Safeguard fits

Safeguard's SBOM and dependency scanning keeps the component inventory behind each finding, so you can follow a result back to where it came from. The demo below shows an inventory view you can click into.

Try it yourself

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

Pick any component and see whether you can tell where it came from and which version is in use.

Quick check

Sources

• OSV schema, Open Source Vulnerabilities

Last reviewed: 19 October 2026.