Bring three repositories of your own: a typical service your team ships often, your messiest legacy repo, and one you already know well enough to judge the results. Together they show whether the scanner works in everyday conditions, under strain, and against a known answer.
Why three, and why your own
A vendor sample app is built to scan cleanly. Your code is not. It has lockfiles that drifted, a build step nobody remembers, and a dependency pinned to a fork. A demo only tells you something if it meets that kind of mess.
Three is a practical number. One repository proves nothing about variety. Ten turns a demo into a project. Three fits in a single session and still covers the main cases.
The three picks
| Pick | What it tests | What to look for |
|---|---|---|
| Typical service | Everyday fit | Does it find the manifests and lockfiles without help? |
| Messy legacy repo | Strain | Does it handle old build tools, vendored code, odd layouts? |
| Known repo | Accuracy | Can you check each finding against what you already know? |
Typical service. Choose something with active commits and a normal mix of direct and transitive packages. This is the repo where the tool would run most often, so speed and noise matter most here.
Messy legacy repo. Pick the one developers avoid. Old package managers, a monorepo with several languages, or a build that needs a special setup are all good candidates. You are not trying to make the tool fail. You want to learn how it fails, and whether it says so clearly.
Known repo. This is your answer key. Choose a repo where you already know at least a few real vulnerable dependencies, perhaps from a past audit or an upgrade you finished last quarter. If the tool misses something you know is there, you have learned something concrete.
What to settle before the session
- Get written approval to share the repositories, and confirm the access is read-only.
- Check that none of the three contains customer data in its history or fixtures.
- Note the language and package manager of each repo so you can ask about support by name.
- Write down, privately, three things you expect the scan to find in the known repo.
Keep the list of expected findings to yourself until the scan finishes. If the vendor sees it first, the demo becomes a rehearsal.
What not to bring
Avoid a repo that is half empty, a fork you do not maintain, or a repo so large that the first scan runs past the end of the meeting. If your biggest repo matters, scan it separately and time it on its own.
Also avoid choosing all three from one team. A single team's conventions can hide gaps that another team would hit on day one.
Where Safeguard fits
Safeguard covers SBOM and dependency scanning, reachability analysis and policy gates. You can try a scan on one of your own repositories for free at gold.safeguard.sh/scan before any demo, which gives you a baseline to compare against.
Quick check
Can I use public open source repos instead of private ones?
Yes, if approval for private code is slow. Public repos still show manifest handling and finding quality. They hide issues with private registries and internal packages, so test those later.
What if my known repo has no known vulnerabilities?
Then add a deliberately old dependency in a throwaway branch and see whether the scanner flags it. A clean result on a clean repo is not evidence of anything.
Last reviewed: 19 October 2026.
