An analyst report can seed a shortlist, but it should never be the only source. Reports have inclusion rules that leave out relevant products. Build your list from your requirements, add names from the report and from peers, then cut it with must-have tests. Aim for three finalists.
Why one source is not enough
Every report has inclusion criteria set by the analyst. Forrester's public methodology page says the analyst sets inclusion criteria, and it is fair to assume other firms do the same. A product can be left out because of size, geography, age or how a market is scoped, not because it performs poorly.
If your shortlist is only the names in one chart, you have outsourced your longlist to someone else's rules.
Four sources worth combining
- Your own requirements. Start here. A short list of must-haves, such as supported languages, deployment model and SBOM format, removes products fast.
- Analyst research. Good for finding names and learning how the category is described.
- Peers. Ask two or three people who run a similar stack what they use and what they dropped.
- Open and standards-based tools. Check what free or open source options cover. The OpenSSF Scorecard, for example, is a free tool that runs automated checks on open source projects, and it can inform dependency decisions even if it is not a product you buy.
A simple cutting method
- Write ten must-haves. Examples: scans your main package ecosystems, exports SBOMs in a format you need, runs in your CI, supports your deployment model.
- Mark each candidate yes, no or unclear using public documentation.
- Drop any candidate with a no on a must-have.
- Email the unclear ones with specific questions. Slow or vague answers are information.
- Keep three to five for a demo, then three for a test.
Watch for category drift
Supply chain security overlaps with several neighbouring categories. Depending on the analyst, the same product may be called composition analysis, application security testing or posture management. If you search for only one label, you will miss products filed under another.
Search for what the product does, such as "reachability" or "SBOM export", rather than only the category name.
Document why each product was cut
A one line reason per cut helps later. When someone asks why a well-known product was not tested, you can answer with the criterion it missed. That protects the decision and keeps the process fair if a vendor asks for feedback.
Safeguard offers SBOM and dependency scanning, reachability analysis and policy gates, and the free scan at gold.safeguard.sh/scan works for a quick first look.
Quick check
Is it risky to skip products that are not in a report?
Skipping them is the risk. Absence can reflect inclusion rules. Check them against your must-haves like any other.
How long should shortlisting take?
Two to three weeks of part-time work is usually enough. Longer lists tend to delay the test stage.
Sources
Last reviewed: 19 October 2026.
