How do you run a two week trial of zero day detection?

A two week trial of zero day detection should answer one question: when something new and serious appears, how quickly do we learn whether it affects us, and who acts? Seed a known test case, check coverage against your inventory, and time the path from alert to owner to fix.

What does zero day mean in a trial?

A zero day is a vulnerability exploited or disclosed before a fix exists. Detection can mean different things: spotting a new flaw in your own code, learning of a newly exploited flaw in software you run, or noticing odd behavior. Decide which you are testing. This plan covers the middle one and the first, since they matter to application teams. For the third, see a SOC or EDR trial.

Days 1 to 3: build the ground truth

You cannot judge detection without knowing what you have. Export an inventory of applications, services and their dependencies, including versions. Mark which are internet facing and which handle sensitive data. Note gaps: repositories that are not scanned, build outputs that have no manifest, containers pulled from outside.

Then write a short list of past events you can replay as a test. Choose two or three real, public vulnerabilities from CISA's Known Exploited Vulnerabilities catalog that affected software similar to yours. Using a historical case avoids pretending to find something new.

Days 4 to 6: seed and measure

Pick a safe test application and deliberately use one of the known vulnerable versions in a non production branch. The test asks:

• Does the tool find the component?
• Does it say whether the vulnerable code is reachable from your code?
• How does it rank it against other findings?
• Does it identify the owner of the repository?

Record the time from introduction to alert. If the tool takes a day, ask if that is scan frequency or feed delay.

Days 7 to 9: the loop

Create a mock announcement of a new exploited flaw. Name the affected library and version range. Time how long it takes your team, with the tool, to produce a list of affected applications. Then compare it with a manual search. The gap is the value you are buying.

Next, test the owner path. Does the right team get notified? Can they see a fix version? NIST SP 800-40 Rev. 4 describes patching as identify, prioritize, acquire, install and verify; time each step in your trial.

Days 10 to 12: noise and fix

Review ten alerts the tool produced. How many were in code that is never called? How many had a fix available? A tool that pushes every listed flaw to the top is not helping with prioritization. EPSS, published by FIRST, gives probability scores that can sit beside reachability in your ranking.

If the tool opens fix pull requests, test on the safe application only, and keep review on.

Days 13 to 14: score

Try it yourself

Open the zero day watch demo

Where Safeguard fits

Safeguard offers zero day discovery in agentic and scanner modes, reachability analysis to show whether a flaw can actually be hit, and autonomous remediation that opens fix pull requests. That remediation is off by default and each category starts on Manual. You can run any of this plan against it using your own repositories and the seed test above.

What to do

1. Export an inventory and note unscanned repositories.
2. Choose two or three real, public exploited flaws to replay.
3. Seed one in a safe branch and time detection.
4. Run a mock announcement and time the affected application list.
5. Check owner routing and fix versions.
6. Score six measures and record the gaps.

Quick check

Sources

• CISA Known Exploited Vulnerabilities Catalog
• NIST SP 800-40 Rev. 4, Enterprise Patch Management Planning
• FIRST, Exploit Prediction Scoring System

Last reviewed: 18 October 2026.