Zero day maturity is mostly about how quickly you can answer two questions after an advisory lands: do we run this, and is it reachable? Basic teams answer in days by hand. Advanced teams answer in minutes from an inventory and also look for unknown flaws in their own code.
What counts as a zero day?
NIST's glossary defines a zero day attack as "an attack that exploits a previously unknown hardware, firmware, or software vulnerability." The defender had zero days to prepare. In practice teams also use the term loosely for any fresh, actively exploited flaw, and that looser use is what this model covers: the first hours after you learn of one.
Level 0: Reactive
No inventory. News arrives by social media or a customer email. Someone searches repositories by hand. Answers take days and are often wrong. Signs: "I think we use that library."
Level 1: Aware
You subscribe to advisories and keep a rough list of key systems. There is a named person who reads alerts. Remediation is still ticket based. You can say "we are probably affected" but not where. Improvement here costs little: one shared channel and one owner.
Level 2: Inventoried
You have a software bill of materials or dependency inventory for most applications, refreshed on every build. A search for a package name across all applications takes minutes. You also track where software runs, not only what it contains. The test: pick a library at random, and find every deployed version within an hour.
Level 3: Prioritized
You separate "present" from "exploitable." Reachability analysis asks whether your code actually calls the vulnerable function. You use exploitation signals such as CISA's KEV catalog and EPSS, and you have written rules for who decides to patch outside the normal cycle. SSVC from CISA and Carnegie Mellon is one published decision method, with outcomes Track, Track*, Attend and Act.
Level 4: Proactive
You do not wait for the advisory. You test your own code and key dependencies for unknown flaws, using fuzzing, code review and automated discovery, and you have a path to disclose responsibly when you find something. Fixes can be proposed automatically but go through review, and policies can block a vulnerable build from releasing.
How to place yourself
Ask these in order. The first "no" is your level.
- Can I list every application and its dependencies today?
- Can I find a given package version across all of them in under an hour?
- Can I tell which hits are reachable?
- Do I have a written rule for emergency patching and a rehearsed process?
- Do I test my own code for unknown flaws on a schedule?
Where Safeguard fits
For the software side of this model, Safeguard provides dependency inventory, reachability analysis to separate present from exploitable, zero day discovery in agentic and scanner modes, and policies that can gate a build or release. Autonomous remediation is available as fix pull requests, off by default, with each category starting on manual approval. It does not cover endpoint or network detection.
What stalls teams between levels?
The jump from level 1 to level 2 stalls on inventory quality. Teams generate dependency lists but only for some repositories, usually the newest. Old services, the ones most likely to hold a forgotten library, are left out. The fix is boring: a list of every deployable thing, compared with the list of things that have an inventory.
The jump from 2 to 3 stalls on trust. Engineers hear "not reachable" and suspect the tool is hiding something. Build that trust by sampling: take ten findings marked unreachable, have a person check them, and share the result. A tool that is right nine times and openly wrong once earns more trust than one that is never questioned.
The jump from 3 to 4 stalls on capacity. Hunting for unknown flaws in your own code produces findings that need disclosure handling, triage and fixes. Start with one critical service, not the whole estate, and decide in advance who receives a report.
A constructed timeline shows the payoff. Advisory published in the morning. At level 0 the team starts a spreadsheet. At level 3 someone searches the inventory, finds two affected services, sees one is reachable, and opens a fix for it before lunch.
What to do
- Place yourself with the five questions above.
- Aim for one level up, not three.
- Rehearse once: invent a package, ask the team to find it, time the answer.
- Write the emergency patch rule before you need it.
- Re-run the rehearsal each quarter.
Quick check
What is the cheapest improvement for a level 0 team?
Name an owner and create one channel for advisories. Then start generating dependency inventories in CI.
Does reachability replace patching?
No. It orders the work. Reachable and exploited issues go first; unreachable ones still get fixed on the normal schedule.
Sources
Last reviewed: 18 October 2026.
