Treat any ASPM vendor answer that names a benefit but not a mechanism as a prompt for a follow-up. Phrases like "we cover everything" or "AI handles it" are not wrong, but they are not evidence. Ask what exactly happens, on what data, and where you can see it.
Why follow ups matter
Buyers rarely get a flat lie. They get a true statement that is narrower than it sounds. A follow-up question widens the answer until you can tell what it really covers.
None of these phrases mean a vendor is bad. They mean the answer is incomplete.
Eight phrases and the follow up for each
| Phrase | What may be missing | Follow up |
|---|---|---|
| "We integrate with everything" | Depth of each integration | Which fields come across, and in which direction? |
| "AI prioritizes for you" | Inputs and explanation | Which signals feed it, and can I see them per finding? |
| "We eliminate false positives" | A measurement | How do you measure it, on whose data? |
| "Fully automated remediation" | Controls and review | Is it off by default, and who approves changes? |
| "Complete coverage" | Language and ecosystem limits | Which ecosystems are not supported today? |
| "Compliant out of the box" | Scope of the claim | What do I still have to do, and what is attested by whom? |
| "Coming very soon" | Date and status | Is it available now, in early access, or a plan? |
| "Customers love it" | Evidence | Can I speak with a reference in a similar setup? |
Special care with certifications
Claims about audits and attestations deserve exact wording. Ask for the report type, the period it covers, the auditor, and whether it is complete or in progress. A SOC 2 report, for instance, is an attestation issued by an independent auditor, so wording such as "we are certified" is imprecise. Ask for the real document under an NDA if needed.
Special care with AI claims
If a feature uses a language model, ask what data leaves your environment, whether it is used for training, and whether you can switch it off. Ask what a human reviews before anything changes in your code.
Special care with prioritization
Public signals are well documented. FIRST describes EPSS as an estimate of the probability a CVE will be exploited in the next 30 days, and CISA describes its KEV catalog as the authoritative source of vulnerabilities exploited in the wild. A vendor using these should be able to say how, and whether you can change the weighting.
How to record the answers
Keep a simple log: question, answer, date, who answered, and whether it was verbal or written. After the call, ask for the verbal ones in writing. A vendor who is comfortable with that request is showing you something useful.
A worked example: following up on one phrase
Suppose a vendor says: "Our AI prioritizes findings so you only see what matters." Here is how a follow up conversation could go.
- You: "Which inputs feed the prioritization?" A clear reply lists them, such as severity, exploitation data, reachability and exposure.
- You: "Can I see those inputs for a single finding?" A clear reply shows a detail view.
- You: "Can I change the weighting or override a result?" A clear reply describes how, and that overrides are logged.
- You: "What do you do with findings hidden by prioritization?" A clear reply says they remain visible in a filtered view.
- You: "Does any of my data leave my environment for this feature?" A clear reply gives specifics and a document.
By the end, the phrase has become a description you can judge. If any answer stays vague, note it and move on to another vendor or ask for a written reply.
Step by step: building your own follow up list
- Collect the phrases you hear in marketing pages and calls.
- Next to each, write the factual claim you think it makes.
- Write the question that would test that claim.
- Ask the question in writing after the call.
- Record the answers and date them.
Reading roadmap statements
Vendors often talk about what is coming. Treat roadmap language carefully. Ask three things: Is it available to customers now? If not, is there a date and a commitment you can put in a contract? What will you use in the meantime? Decisions should rest on what exists today.
Red flags in documents
- Marketing PDFs presented as technical documentation.
- Security statements with no date or version.
- Certification logos with no report type or period.
- Case studies with no named context or method.
None of these prove a problem, but each is a reason to request the underlying document.
Be fair
Vendors work under pressure to simplify. A fair evaluator asks the same questions of every product, accepts honest limits as a sign of maturity and avoids penalizing candor. A vendor who says "we do not support that yet" has just saved you time.
Where Safeguard fits
Safeguard offers autonomous remediation with fix PRs off by default, with every category on Manual. You can test the rest on your own code with the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Notice where a human decision sits in the flow.
Quick check
Is a vague answer a deal breaker?
No. It is a reason to ask one more question and get the answer in writing.
Should I ask for a reference customer?
Yes, ideally one with a similar stack and team size.
How do I handle a vendor who refuses to answer in writing?
Treat it as information. Note the refusal, weigh it in your scoring, and consider whether other evidence, such as documentation or a reference call, can fill the gap.
Sources
Last reviewed: 19 October 2026.
