Read a vendor's feature comparison table as a list of the questions the vendor wants you to ask. A checkmark says a feature exists in some form. It rarely says how deep it goes, whether it is generally available, or whether it works in your environment. Rebuild the table from your own tests.
How the table was made
The author of a comparison table picks the rows, the columns and the scoring. Rows tend to be features the author does well. Features the author lacks, or that matter to you but not to their marketing, are quietly absent. That is not dishonest by itself. It is how every vendor table is built, so treat the row selection as information.
Ask who is not in the columns. If a tool you are evaluating is missing, the table cannot help you compare it.
What a checkmark can mean
One symbol can stand for very different things:
| Checkmark may mean | What to ask |
|---|---|
| Fully released and supported | Is it generally available, and since when? |
| Early access or preview | Can I get this in writing, and is it in my contract scope? |
| Works through a third party | Who owns the support when it breaks? |
| Works for some languages only | Which ones, and are mine included? |
| Needs a manual step | How many steps, and who does them? |
| Available on a higher plan | Which tier does my evaluation use? |
The question about maturity is the most useful one. Ask for each checked row whether it is generally available, in early access or on a roadmap, and ask for the answer in an email, not on a call.
Rebuild the table from tests
- List your own top eight needs from your trial plan, in your words.
- Turn each into a task a person can perform, such as "block a pull request that adds a package with a known exploited issue".
- Run the task in each tool you are testing, with a timer and a screenshot.
- Score each result as done, done with effort, or not done.
- Compare the table you built with the table the vendor gave you. The differences are the interesting part.
Your table will have fewer rows and more evidence, which is the point.
Footnotes and fine print
Check three small things on any vendor table:
- The date. Products change, and an undated table can be years old.
- The source. If the table cites a test or report, ask for it, and see whether it was funded by the vendor.
- The legal line. Phrases like "based on publicly available information" mean no one verified the other columns with those vendors.
Where Safeguard fits
When you test Safeguard, hold it to the same standard. Its capabilities include dependency and SBOM scanning, reachability analysis, policy gates and compliance evidence, and each row of your own table should be filled from what you can run on your repositories. Start with the free scan at gold.safeguard.sh/scan if you want a first data point.
Quick check
Should I ignore vendor comparison tables?
No. Use them to learn what the vendor thinks matters, then replace them with a table built from your tasks.
What is the quickest way to catch an overstated row?
Ask the vendor to do that row live on your repository, with no preparation. Overstated rows usually need preparation.
Last reviewed: 19 October 2026.
