Before signing with a vendor that sells zero day detection or response, ask how quickly it matches new advisories to your code, how it validates the flaws it claims to find, what it can enforce, where your code goes, and what you can take with you. Ask for evidence from your own applications, not slides.
What does "zero day" mean in a sales call?
NIST defines a zero day attack as one that exploits a previously unknown vulnerability. Vendors use the phrase for different things: discovering unknown flaws in code, matching fresh advisories to your software, or detecting exploitation on running systems. Pin down which one is being sold. These questions concern the software side. They rank no vendors.
Questions about speed and coverage
1. After a public advisory, how long until you tell me where I am affected? Ask for two recent examples with timestamps of the advisory and of customer notification.
2. Which ecosystems and artifact types do you cover? Languages, package managers, container images, vendored code, infrastructure as code. Ask what is not covered.
3. Do you resolve transitive dependencies, and how? A constructed test helps: add an obscure package three levels deep and see if it appears.
Questions about quality
4. How do you separate "present" from "exploitable"? Ask about reachability analysis, the languages supported and known blind spots, such as reflection or dynamic loading. Ask about a case where it said "not reachable" and was wrong.
5. How are findings prioritized? Look for use of exploitation evidence such as CISA's Known Exploited Vulnerabilities catalog and FIRST's EPSS, not severity alone.
6. If you claim to discover unknown flaws, how are they validated before they reach my engineers? Ask what share is confirmed by a human, what proof is attached and what happens to false positives.
7. What is your disclosure process for flaws found in third party code? A responsible answer names coordinated disclosure and who contacts the maintainer.
Questions about control and safety
8. What can you enforce, and where? IDE, pull request, CI, registry, release. Can enforcement start in warn mode?
9. Can you change my code or settings? If it proposes fixes as pull requests, ask whether that is off by default, who approves and how it is logged.
10. What happens when your service is down? Does the build fail open or closed?
Questions about data and trust
11. Does my source code leave my environment? Ask about local or private scanning, and what metadata is sent. Ask who at the vendor can see it and how long it is kept.
12. What independent assurance do you have? Read the audit report's scope. Check any certification claim at the source. A claim that something is underway is not the same as completed.
Questions about money and exit
13. What is the price based on? Repositories, developers, scans, applications? Ask what happens when numbers grow.
14. What can I export if I leave? Inventory, policies, exceptions and history, in a usable format.
15. What is shipped today and what is planned? Count only what you saw working.
How to use the answers
Mark each answer as demonstrated, claimed or unclear. Then pick three claims, such as items 1, 4 and 9, and test them in a two to four week pilot on real applications. A vendor that welcomes this is confident. One that avoids it is telling you something.
Where Safeguard fits
Safeguard offers dependency inventory, reachability analysis, zero day discovery in agentic and scanner modes, and policies enforceable at build, CI and release. Fix pull requests exist but are off by default, with categories starting on manual approval. It does not detect exploitation on endpoints or networks. Put the same fifteen questions to us.
What does a good pilot cost you?
A pilot takes your engineers' time, so plan it. Choose three applications of different ages and languages. Give one engineer a few hours to connect each. Set a fixed review meeting at the end where the vendor and your team look at the same twenty findings.
Decide the pass marks beforehand. For example, the tool must list every application you already know uses a given library, must flag a planted vulnerable dependency in a test branch within one build, and must produce a fix proposal that a reviewer judges reasonable. Pass marks written after the pilot tend to bend toward the answer people already like.
Keep notes on setup effort. If connecting one repository takes a day of back and forth, multiply by your number of repositories before you believe the sales timeline. Also record what the vendor needed from you, such as broad repository permissions, since access you grant becomes risk you carry.
What to do
- Decide whether you are buying inventory, discovery, enforcement or all three.
- Send the questions in writing before demos.
- Run a pilot on three real applications.
- Review sample findings with the engineers who will fix them.
- Settle data handling and export in the contract.
Quick check
Which question exposes the most?
How unknown flaws are validated before an engineer sees them. It shows whether the tool reduces work or creates it.
Is reachability enough to ignore a finding?
It is a strong signal for ordering work, but sample its results by hand and still fix unreachable issues on the normal schedule.
Sources
Last reviewed: 18 October 2026.
