For the first demo, no. Let the vendor see your repository only when the scan starts, so the results are real and unrehearsed. A preview scan is reasonable for a later session, once you want depth, as long as you agree on what they may see and keep.
The case for a blind demo
A scan run live, in front of you, is the closest thing to what daily use looks like. Nobody has tuned the settings, hidden a noisy rule, or picked an easy branch.
If the vendor sees the repo first, three things can happen. They may prepare answers to the findings they expect you to ask about. They may adjust configuration quietly. They may choose which findings to show. None of this is dishonest by default, but it changes what you learn.
A blind demo also tests the vendor. Can they onboard a repository they have never seen, in front of a room, without a long setup? That is a fair proxy for how your own team will feel in week one.
The case for a preview
A blind scan can fail for dull reasons: a private package registry that needs a token, an unusual build layout, a network restriction. When that happens in a one hour call, the hour is gone.
A short prep step can prevent that. Keep it narrow. The vendor can check that the repo connects and that credentials work, without running or showing findings. Ask them to confirm, in writing, that no results are shared outside your team before the session.
A simple decision guide
| Situation | Suggested approach |
|---|---|
| First demo, public or low risk repos | Blind, live scan |
| Private registry or restricted network | Connection check beforehand, scan live |
| Second session focused on depth | Preview allowed, with agreed scope |
| Regulated data in the repo | Blind demo on a sanitized copy, or a trial in your own environment |
Terms to agree on, whichever you pick
- Access. Read-only, scoped to the named repositories, with an end date.
- Retention. What is stored after the demo, and how it is deleted on request.
- Sharing. Whether results can be shown to anyone outside your team, including in their own sales material.
- Who clicks. You, or them. If it is them, ask them to follow your list of requests rather than a script.
Put these in an email before the call. It takes five minutes and avoids an awkward argument later.
What to do if they insist on a preview
Ask why. A good reason, such as a need to install a connector, is easy to meet. A vague answer about "making sure we show you the best view" is a signal to slow down. You can still accept, then repeat part of the scan live and compare the two outputs.
Where Safeguard fits
You can run a scan yourself with no vendor present at gold.safeguard.sh/scan, which is a useful way to build a blind baseline. Safeguard's GA capabilities include SBOM and dependency scanning, reachability analysis, and policy gates.
Quick check
Is a blind demo unfair to the vendor?
Not if you tell them the format up front. Honest vendors prefer a realistic test, because it produces a decision you will not regret.
What if the blind scan fails?
Note why it failed and how the vendor handled it. Then reschedule with the fix in place. How a tool fails is part of the evaluation.
Last reviewed: 19 October 2026.
