To test model dependency coverage in a demo, bring your own small repository containing an ML library pinned to a version with a known advisory, a model file, and a script that loads it. Then watch what the tool lists, what it flags and what it records. Slides cannot show you that.
Why bring your own repo
A vendor demo repo is built to look good. Yours is built to find gaps. The goal is a repo small enough to review in ten minutes and specific enough that a miss is obvious.
Do not put real secrets or customer data in it. Use public sample models and public libraries. Keep a note of exactly what you planted, so you can compare it with what the tool reports.
What to plant
| Item | Purpose |
|---|---|
| An ML or inference library pinned to an older version with a published advisory | Tests advisory matching on AI libraries |
| A transitive dependency two levels down | Tests depth of the inventory |
| A model file in a common format committed to the repo | Tests detection of model artifacts |
| A script that downloads a model by name from a public hub at runtime | Tests whether runtime fetches are visible at all |
| A requirements file and a lockfile that disagree | Tests how the tool resolves versions |
You do not need all five. Three well chosen items beat ten vague ones.
The five step demo test
- Ask the presenter to connect your repo, not run a canned scan. Note how long onboarding takes and what permissions it asks for.
- Ask them to list every component found. Count the planted items. Write down which are missing.
- For the vulnerable library, ask why it is or is not prioritised. A good answer mentions whether the vulnerable code is reachable from your application. Our reachability demo shows what that looks like.
- For the model file, ask what the tool records: name, format, source, hash, version. If the answer is "nothing", you have learned something useful.
- Ask for the output as a file. A report you can export is evidence. A dashboard you can screenshot is a demonstration.
What good and weak answers sound like
A good answer is specific: "The model file is listed as a component with its format and hash. The runtime download is not visible to static scanning, so we flag the call site." A weak answer is general: "Our AI engine understands your models."
Be careful with confident gaps. Static scanning cannot see a model that is fetched at runtime unless something records the call. A candid vendor says so. If the response is that everything is covered, ask them to show the runtime fetch in the demo.
For background on file formats, see model file extensions and what each one can do.
Try it yourself
Open the demo and look at how a dependency view shows a component, its version and its relationship to the application. Think about where a model file would sit in a view like this.
Click through it at your own pace, or open it full screen.
After the demo
Write the results in a table with three columns: planted, found, evidence. Share it with every vendor you test so the comparison is the same. Keep the repo. You will reuse it at renewal.
Safeguard provides SBOM and dependency scanning and reachability analysis, and you can point the free scanner at a repository at gold.safeguard.sh/scan to practice this test before any demo.
Quick check
Is a model file in a repo a dependency?
For inventory purposes, treat it as one. It is a third party artifact your application loads, with a source, a version and a license, even if package managers do not track it.
Can a demo test replace a proof of concept?
No. A demo test narrows the field in an hour. A proof of concept on real repositories confirms noise levels, speed and fit.
Sources
Last reviewed: 19 October 2026.
