A demo on a sample app is worth watching for the interface and the workflow, but not for the results. The app was chosen so the scan looks good. Treat it as a tour of features, then insist on a second session with your own repository.
Myth 1: The findings show what it will find in my code
Fact. Sample apps are built, or chosen, to contain a neat spread of issues. Your code has a different mix. The number of findings, their severity and their clarity on a sample tell you nothing about yours.
Myth 2: If it works on the demo app, it works on any app
Fact. Demo apps use common frameworks, standard layouts and clean lockfiles. Real repositories have drift, forks, vendored code and old build tools. Support for your specific ecosystem and layout has to be tested on your code.
Myth 3: A fast demo scan means a fast scan
Fact. A small sample scans quickly by definition. Timing on your largest repository can look completely different. Ask for it, and time it yourself.
Myth 4: The sample demo is useless
Fact. It has value. You can learn how navigation works, what a finding page contains, how a policy is set, and how fixes are presented. Use it to prepare better questions.
A good approach is to watch the sample demo with a notebook, listing every feature you want to see again on your own repository. The list becomes your script for the second session.
Myth 5: A recorded demo is as good as a live one
Fact. A recording shows what happened once, under ideal conditions. A live scan on your repo can fail, hesitate or surprise, and those moments are the informative ones.
What to ask for instead
| Instead of | Ask for |
|---|---|
| Sample app scan | A scan of your repository, live |
| Slides about accuracy | A check against a repo where you know the answers |
| A promise of ecosystem support | A scan of a repo in your language and package manager |
| A finished report | A report generated in front of you |
| Fix examples | A fix pull request on your code, run through your CI |
How to ask without sounding hostile
Say it plainly and early: "We would like the second half of the session to run on one of our repositories, read only." Vendors are used to it. If a vendor resists, that is information.
You can also offer a fair trade. Tell them which ecosystems you use in advance, so they can make sure support is configured, and keep the repository choice for the moment of the scan.
A note on trials
If the tool has a self-serve trial, the sample app step can be skipped altogether. Connect a repository and look at real output. The sample demo then serves only as orientation for colleagues who will not use the tool directly.
Where Safeguard fits
Safeguard publishes interactive demos you can click through, and a free scan at gold.safeguard.sh/scan so you can see output on your own code instead of a sample. The tool covers SBOM and dependency scanning, reachability analysis and policy gates.
Quick check
Should I skip the sample demo?
Not necessarily. Use it for orientation, then move quickly to your own repository.
What if the vendor cannot scan my private repo live?
Ask for a trial in your own environment or a scan of a sanitized copy. Note the limitation in your evaluation.
Last reviewed: 19 October 2026.
