A demo scorecard is a one page table with eight criteria, a score of 0, 1 or 2 for each, and a line of evidence. Fill it in during the call, not after. Scores written later drift toward whoever spoke last.
Why score at all
Without a record, a demo becomes an impression. The vendor with the best slides or the friendliest presenter can win by default. A scorecard forces you to separate what you saw from what you were told.
Keep it small. Eight rows fit on one page, and every attendee can fill one in without training.
The scale
| Score | Meaning |
|---|---|
| 0 | Not shown, or shown and wrong |
| 1 | Shown, with gaps or caveats |
| 2 | Shown clearly on my repository, and I could verify it |
Note the wording of 2. It requires your repository and your verification. A claim, however confident, scores 0 until it is shown.
The eight criteria
| Criterion | What to test | Score | Evidence |
|---|---|---|---|
| Coverage | Files read versus files that exist | ||
| Accuracy | Findings checked against your known repo | ||
| Explanation | One finding traced end to end | ||
| Prioritization | Severity, exploit data, reachability | ||
| Fixes | A fix pull request built in your CI | ||
| Controls | A gate blocked and allowed a change | ||
| Export | SBOM and findings opened outside the tool | ||
| Speed | Timed on your largest repo |
Leave the last two columns blank in the template and fill them in live. Evidence should be short and factual, for example "read 9 of 12 manifests" or "fix PR failed on test suite".
Rules for adding up
- Each attendee scores alone, before any discussion.
- Compare scores row by row. Where two people differ by more than one point, discuss that row only.
- Do not weight rows until you have scored a demo. Weighting beforehand tends to encode a favorite.
- Mark any row scored 0 that you consider essential. A single essential 0 matters more than a high total.
Adjusting for your situation
A small team with no dedicated security staff may care most about explanation and fixes. A regulated team may weight export and controls more. Decide this together, in writing, and apply it equally to every tool you assess.
If you add rows, remove others. A twenty row scorecard is not used.
After scoring
Keep the filled-in sheet with your notes. When a vendor asks why you went another way, the sheet is a polite and specific answer. It also helps you in six months, when someone asks why you chose what you chose.
For a deeper look, compare the evidence in rows rather than the totals. Two tools with the same total can differ completely in where they are strong, and that difference is often the real decision.
Where Safeguard fits
Safeguard offers dependency scanning, SBOM generation, reachability analysis, policy gates and fix pull requests (off by default). You can add Safeguard to your own scorecard by running the free scan at gold.safeguard.sh/scan.
Quick check
Should the vendor see my scorecard?
You can share the criteria, which keeps the demo honest. Keep the scores to yourselves.
What if two tools tie?
Look at the rows. Prefer the one with fewer essential zeros, then run a longer trial on your own repositories.
Last reviewed: 19 October 2026.
