Ask directly: "What are the known limitations of this product, and which customers have hit them?" Every security product has limits. A candid vendor will name several, with workarounds and dates. A vendor who says there are none, or answers with a feature list, has told you something useful.
Why this question works
Marketing describes what a product can do. Limits describe where it stops. You need the second to decide, because your risk lies in the gaps. The question also reveals the vendor's culture: whether engineering feedback reaches sales, and whether honesty is allowed.
Five areas to probe
- Coverage gaps. Which languages, package managers, operating systems or build tools are weak or missing?
- Accuracy limits. Where does the product produce false positives or miss things? Ask for examples of both.
- Scale limits. What are the largest repositories, organisations or scan volumes in production? What happens past them?
- Integration limits. What does it not connect to, or connect to only partly?
- Maturity limits. Which features are generally available, in early access or planned?
For each, ask for the limitation in writing, with a workaround and a rough date if a fix is planned.
Candid versus deflecting answers
| Candid | Deflecting |
|---|---|
| "Reachability works for these languages. For others you get package level results only." | "We support all major languages." |
| "Large monorepos can take longer. Here is the setting that helps." | "Performance is never a problem." |
| "That feature is in early access, so not in production contracts yet." | "It is basically live." |
| "We do not detect this class of issue. Pair it with another control." | "We cover everything." |
A candid answer does not need to be long. It needs to be specific.
Follow up with a test
Choose one stated limit and test it yourself. If the vendor says large repositories are slower, try your largest one and time it. If they say a language is partly covered, scan a sample and see how partly. A match between what they said and what you saw raises trust far more than any claim. A mismatch tells you where to dig.
Use the answers
Add the limits to your ledger and your risk register. For each, decide whether you accept it, cover it with another control or treat it as a reason to choose differently. Share the list with your team so developers are not surprised after rollout.
When to ask
Ask early, before the demo, and again near the end of the trial. The first answer shows what the vendor volunteers. The second shows what your testing has turned up, and whether the vendor's description now matches your experience. Put both answers in your claims ledger with the dates, so you can see how the story changed.
Where Safeguard fits
Ask Safeguard the same question. Its capabilities include dependency and SBOM scanning, reachability analysis, policy gates, compliance evidence and zero-day discovery, and you should ask where each one stops for your languages. The free scan at gold.safeguard.sh/scan lets you check for yourself.
Quick check
What if the vendor says they have no limitations?
Treat it as unverified, and ask for an example of something a customer wanted that the product could not do. Then test.
Do limits mean a vendor is weak?
No. Every tool has them. What matters is whether you can live with yours.
Last reviewed: 19 October 2026.
