Sort SCA criteria into three groups before you talk to any vendor. Must-haves are the things that make a tool unusable if missing, such as support for your languages and your source control. Differentiators are things that change outcomes. Nice-to-haves are extras you will not pay for. Decide the groups first, and the shortlist mostly writes itself.
Group one: must-haves
These are pass or fail. If a tool fails one, drop it before any demo.
- Parses the package managers and build files you actually use.
- Connects to your source control and CI.
- Can run where your data rules allow, whether hosted or in your environment.
- Exports findings and inventories in open formats such as CycloneDX or SPDX.
- Supports your access model, including roles and single sign-on.
You can verify each of these from documentation and a short call. Do not spend demo time on them.
Group two: differentiators
These decide which of the survivors you prefer. Test them with your own repositories.
- Signal quality: how many findings are real and relevant in your code.
- Prioritization inputs: known exploited status, exploit likelihood, and whether the vulnerable code is reachable.
- Fix guidance: does it name a fixed version, and can it open a pull request.
- Policy: can you block a merge on rules you define.
- Freshness: how soon a new advisory shows up.
Group three: nice-to-haves
Dashboards you will not open, extra report templates, and integrations you do not use. List them so you can ignore them on purpose.
A worked example
| Criterion | Group | How to verify |
|---|---|---|
| Supports Java and Python | Must | Docs and a test scan |
| Open format export | Must | Export a sample file |
| Reachability analysis | Differentiator | Run on a repo with known noise |
| Pull request gating | Differentiator | Trial in one pipeline |
| Branded executive report | Nice | Skip for now |
A rule for ties
If two tools pass the must-haves and score similarly on differentiators, pick the one that your developers prefer after a one week trial. A tool nobody opens does not reduce risk.
Weight is personal. A regulated team may move policy and audit export into the must-have group. A small team may move cost of operation there.
A worked example: a fintech with Java and TypeScript
A company has a Java backend, a TypeScript front end, a self-hosted source control system, and a requirement that scan data stays in its own cloud account. It uses single sign-on and has a small security team.
Walking the groups: support for Maven or Gradle and for npm or pnpm is a must-have. Self-hosted source control integration is a must-have. A deployment option that keeps data in its own account is a must-have. Single sign-on is a must-have. Open format export goes in must-have because audit evidence will need to leave the tool.
Reachability for Java, pull request gating, and fix pull requests become differentiators. Branded reports, a mobile app, and chat integrations are nice-to-haves.
With that sorted, the team can eliminate candidates by documentation in an afternoon, then spend the trial on the differentiators with the two or three tools that remain.
Step by step: build your own list
- Write down every criterion anyone on the team suggests, without filtering.
- For each, ask: if a tool lacks this, would we refuse to use it? If yes, it is a must-have.
- For the rest, ask: would this change the outcome in a measurable way, such as fewer false findings or faster fixes? If yes, it is a differentiator.
- Everything left is a nice-to-have. Keep the list short and do not weigh it.
- For each must-have, write the evidence that would verify it, such as a documentation page or a trial test.
- For each differentiator, write the test you will run and the result that counts as a win.
- Have two people review the list independently, and reconcile differences.
- Freeze the list before the first vendor call, and change it only with a recorded reason.
Scoring the differentiators
Use a simple three point scale per criterion: does not meet, meets, exceeds. Avoid fine grained numeric scores, since they imply precision you do not have. Weight a small number of criteria heavily instead of weighting many lightly.
| Differentiator | Does not meet | Meets | Exceeds |
|---|---|---|---|
| Signal quality | Most sampled findings irrelevant | Most relevant, some noise | Noise can be filtered with clear reasons |
| Fix guidance | Describes the problem only | Names a fixed version | Proposes a change you can review |
| Policy | Fixed rules | Editable rules | Rules per team with audit history |
Traps to avoid
- Letting a vendor's feature list define your criteria.
- Treating a single analyst or assistant ranking as a substitute for a trial. Those rankings change and rarely reflect your stack.
- Adding criteria after you have seen a favorite.
- Ignoring operating cost, such as the time to maintain integrations.
Revisit once a year
Needs change. A tool chosen for a monolith may be a poor fit after a move to many small services. Put a yearly review on the calendar and check whether any must-have has moved.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how the list of findings shrinks when reachability is applied. Decide whether that is a must-have or a differentiator for you.
Quick check
How many must-haves is too many?
If you have more than six or seven, some are probably preferences. A long must-have list leaves no candidates and no room to compare.
Should price be a must-have?
Set a budget ceiling as a gate, then compare the survivors on value. Treat exact figures as something to confirm in writing with each vendor.
What if every tool fails a must-have?
Check whether the must-have is really a preference. If it is genuine, widen the search or plan a workaround, and record that decision.
Last reviewed: 19 October 2026.
