In an ASPM demo, ask the vendor to use your data, then ask how findings are matched, how owners are assigned, how priority is calculated, what happens to exceptions, and how you can export everything. Clear, specific answers to those five are worth more than any dashboard.
Why demos need a script
A demo is built to show strengths. That is fair, but it means you have to bring the questions that test the edges. Send them ahead of time and ask for written answers, so a gap in the room does not become a gap in your decision.
The questions, grouped
Data in
- Which sources can you ingest today, and which need custom work?
- What do you do when a tool's export format changes?
- How fresh is the data, and what triggers an update?
Matching and context
- Which fields do you use to merge duplicates, and can I see why two findings were merged?
- How do you learn which repository belongs to which team?
- How do you tell whether a vulnerable component is actually used by the application?
Priority
- What inputs feed the priority order? Can I see them for a single finding?
- Can I change the weighting?
- Which public sources do you use, for example exploitation data or scoring standards?
Workflow
- How do tickets sync, and in which direction?
- How are exceptions recorded, who approves them, and do they expire?
- What does a developer see when a rule fails a pull request?
Exit and trust
- Can I export findings, owners and decisions in an open format?
- Where is my data stored, and who can access it?
- What can you tell me in writing about your own security assurance?
What good answers sound like
A good answer names a specific behavior and offers to show it. "We match on the identifier, component and version, and here is the merge history" is better than "our engine handles that." Be cautious about answers that rely on adjectives, or that move quickly to a different feature.
Watch for claims that sound like certainty about the future. A vendor describing a roadmap item should say it is a roadmap item.
Reference points you can use
Public sources give you a shared vocabulary. FIRST's EPSS publishes a daily probability that a CVE will be exploited in the next 30 days. CISA's KEV catalog lists vulnerabilities known to be exploited in the wild. CVSS expresses severity. Ask the vendor how each is used, and whether you can see them side by side.
After the demo
Score each answer yourself as clear, partly clear or unclear, before comparing notes with colleagues. Combine scores only after everyone has written theirs, so the loudest voice does not set the result.
A worked example of scoring one answer
Suppose you ask: "How do you decide which team owns a finding?" Compare two responses.
Response one: "Our engine automatically figures that out for you."
Response two: "We read the code owners file in each repository first. If there is none, we fall back to a mapping you provide, and if there is neither, the finding goes to an unassigned view with a count on the dashboard. Here is that view."
Response two names the mechanism, the order of fallbacks and the failure case, and shows it. Score it clear. Response one names a benefit and nothing else. Score it unclear, and ask the follow up: "What does it read, and what happens when it has nothing to read?"
You will meet this pattern often. The clear answers describe what happens when things go wrong. The unclear ones only describe what happens when everything works.
Step by step: running the session
- Send the question list a week ahead and ask which items they can show live.
- Provide a small sample of your own data or a safe public repository.
- Assign each question to one of your attendees to score.
- Note any item the vendor says they will follow up on, with a date.
- After the session, compare scores and write the open items into a shared list.
- Hold the vendor to the follow up dates. Delays are information.
A scoring sheet
| Area | Question count | Clear | Partly clear | Unclear |
|---|---|---|---|---|
| Data in | 3 | |||
| Matching and context | 3 | |||
| Priority | 3 | |||
| Workflow | 3 | |||
| Exit and trust | 3 |
Fill it in privately, then compare. Areas with many unclear answers are where to focus in a second session or a proof of concept.
Questions about the vendor, not only the product
Ask about support response times, release cadence, how breaking changes are communicated, and how incident notifications work if the vendor has a security problem of its own. A tool that holds your vulnerability data is a sensitive system, so treat the vendor with the same scrutiny you would apply to any supplier.
Where Safeguard fits
Safeguard provides reachability analysis, policies and gates, and SBOM and dependency scanning. The same questions apply to us, and a free scan at gold.safeguard.sh/scan lets you test on your own code.
Try it yourself
Click through it at your own pace, or open it full screen. See which signals appear next to a finding.
Quick check
Should I share my own data in a demo?
Yes, if your policies allow it. Use a non sensitive repository if you are unsure.
How many vendors should I demo?
Two or three is enough to learn the differences without exhausting your team.
Should the whole team attend the demo?
Invite the people who will use it daily, not only decision makers. Their questions are often the most practical ones.
Sources
Last reviewed: 19 October 2026.
