Use an analyst compass early to build a long list, narrow it to a short list with your own priorities, then send a tailored RFI and run a proof of concept. KuppingerCole's own analysts say the Compass helps with the first two steps and cannot replace the last two. Plan the test before you read the chart.
What the analysts themselves say
A KuppingerCole analyst blog says the Leadership Compass views are quite helpful for identifying a long list of vendors, and that the leadership categories and matrices can help build a short list by showing trade-offs, such as vendors that are highly innovative but still developing as product or market leaders. It adds that the Compass should not replace an RFI tailored to your challenges and cannot replace a proof of concept. The methodology page repeats that the report alone is not enough.
Step 1: long list from the report
Pull every vendor in your market segment, including the ones in the vendors to watch chapter if it exists. Do not cut anyone yet. Note which leader categories each falls into.
Step 2: short list with your own weights
Decide what you value: product depth, global presence, innovation, or a mix. Use the matrices to find vendors strong on that view. Keep one or two Challengers or Followers if they match a niche you have, such as a language the market leaders support weakly.
Step 3: a tailored RFI
Write questions from your environment, not from the report. Examples: which package ecosystems do you cover, how do you handle private registries, can you run self-hosted, what evidence can you export for an audit, how are false positives handled.
Step 4: proof of concept on your own code
This is where claims meet reality. Set success criteria in writing before you start.
- Pick three to five repositories that reflect your real mix, including one with a messy dependency tree.
- Define what counts as a true finding and who will judge it.
- Time how long set-up takes and how much tuning you need.
- Record how findings reach developers and how many get fixed.
Try it yourself
Open the demo and look at how a dependency inventory is produced from a project. When you run your own proof of concept, this is the inventory every other claim rests on.
Click through it at your own pace, or open it full screen.
Mistakes that waste a proof of concept
- Starting without success criteria, so the result becomes a debate about taste.
- Testing only clean sample projects. Use at least one repository with years of accumulated dependencies.
- Letting each vendor choose the test data. Use the same repositories for everyone.
- Measuring detections and ignoring what happens next. Track time from finding to merged fix.
- Skipping the people who will use the tool. Ask two developers to try it without help.
Quick check
Can an analyst compass replace a proof of concept?
KuppingerCole's analyst blog says no. It says further evaluation, including RFIs and proofs of concept, is needed.
Should I drop Challengers and Followers?
Not necessarily. The methodology page suggests considering them if they match a niche use case well.
Safeguard's free scan at gold.safeguard.sh/scan offers SBOM and dependency scanning you can use as a baseline in a proof of concept.
Sources
- Looking at vendors from various angles (KuppingerCole blog)
- About KuppingerCole's Leadership Compass
Last reviewed: 19 October 2026.
