Build a long list from five sources: peers in your industry, open standards and community projects, your cloud or software marketplace, your own developers, and public documentation. Then filter every name through written deal breakers. You will have eight to twelve credible candidates in a few days.
The five sources
1. Peers. Ask three or four people at similar companies what they run, what they dropped and why. The reasons for dropping a tool are worth more than the names.
2. Open standards and community projects. Standards bodies and open source foundations publish formats and requirements that vendors either support or do not. If you want SBOMs, vulnerability exchange data or a secure development attestation, the standard tells you which question to ask. NIST's Secure Software Development Framework, for example, describes itself as giving producers and acquirers a common language for describing secure software development practices, which makes it a handy source for requirement wording.
3. Marketplaces. Your cloud provider's catalog and your software repository's integration list show which tools already connect to your stack.
4. Your developers. Ask which tools they have already tried, which they cannot stand, and which ones they would install on a Friday afternoon without being told to. Adoption is half of any security purchase.
5. Public documentation. A vendor's docs, changelog, status page and disclosure policy tell you more about maturity than a landing page. If you cannot find the docs without filling in a form, note that.
Keep a simple log
A spreadsheet with six columns is enough:
| Column | Example content |
|---|---|
| Name | The product, not the company |
| Source | Peer, standard, marketplace, developer, docs |
| Category fit | Which of your requirements it claims to cover |
| Deployment | SaaS, self-hosted, both |
| Deal breakers | Pass, fail, unknown |
| Notes | One line you can defend later |
Mark unknown as unknown. Do not guess.
Filter with deal breakers
Deal breakers are yes or no facts that no amount of excellent features can fix:
- It does not support your languages or package ecosystems.
- It cannot be deployed the way your policy requires.
- It stores data in a region you cannot use.
- It cannot connect to your source control or CI system.
- It has no way to export your data.
Apply these before you read a single marketing page. It keeps the list honest and protects you from falling for a demo.
Watch for bias in your sources
Every source tilts. Peers favor what they already paid for. Marketplaces favor vendors that pay to be listed. Developers favor tools with a pleasant command line. Mix the sources so no one of them decides the list.
What to do next
Send the filtered list a short RFI, then cut to a shortlist. If you want a hands-on view before you write requirements, Safeguard offers a free scan at https://gold.safeguard.sh/scan, and its GA capabilities include SBOM and dependency scanning and reachability analysis. Treat it as one candidate among several.
A worked example: a long list in three days
A team of six engineers at a software company wants a dependency risk tool. Nobody has budget for an analyst subscription. Here is the plan.
Day 1 morning: peers. The security lead sends the same three questions to five contacts: What do you run for this? What did you drop and why? What would you ask a vendor now that you did not know then? Two replies arrive by lunch, and a call fills in a third. The result is four names and, more usefully, three reasons for dropping tools: noisy output, poor pull request behavior, and slow support.
Day 1 afternoon: standards. The lead reads the sections of public standards that match the requirement. If the team wants a bill of materials, it checks which formats are widely used and writes those into the deal breakers. If it wants to ask about secure development practices, it borrows phrasing from NIST's Secure Software Development Framework.
Day 2: marketplaces and developers. A developer survey with two questions, "Which security tools have you used?" and "Which would you refuse to use again?", takes ten minutes to answer and produces five more names. The cloud marketplace listing adds two. The source control platform's integrations page adds one.
Day 3: docs pass and filter. For every name, someone spends fifteen minutes reading the public documentation for the three deal breakers. The spreadsheet gets filled. Names that fail a deal breaker are marked out with a reason.
By Friday there are ten names, seven of them still standing.
Questions to ask each source
| Source | Question | What you learn |
|---|---|---|
| Peer | What would you change about your tool? | Real trade-offs |
| Developer | What did you stop using, and why? | Adoption barriers |
| Standard | Which formats and practices does it expect? | Wording for requirements |
| Marketplace | What connects to our stack today? | Integration reality |
| Documentation | Can I find installation, limits and release notes without a form? | Maturity and openness |
Signals worth recording from public documentation
- A visible changelog with dates.
- A status page with incident history.
- A public vulnerability disclosure policy for the vendor's own product.
- Clear statements of supported ecosystems and versions.
- Documented API and export options.
Absence of any of these is not a disqualifier, but record it. It tells you what the vendor will be like to work with.
What to avoid
- Accepting a list that came from one source.
- Skipping the developer survey because it feels informal.
- Searching only for product lists titled with superlatives. Those pages often exist to sell something and rarely state their method.
- Adding a name with no evidence just because it is popular.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the ecosystems and components an inventory records, then check whether each long-list name supports the ones you run.
Quick check
Do we need an analyst report to start?
No. Peers, standards, marketplaces, developers and docs give you enough to reach a defensible long list.
How long should this take?
A few working days for the long list, including a handful of peer conversations. Spending weeks here usually means the requirements are unclear, not that you need more names.
Should we ask vendors to nominate themselves?
Yes, with care. A short public notice or a note to your marketplace contact can surface candidates, but treat self-nominated names like any other and apply the same deal breakers.
Sources
Last reviewed: 19 October 2026.
