When asked how to handle a zero day vulnerability, a good answer tells you to find where you run the affected software, check whether it is exposed, apply a mitigation or patch to the exposed instances first, and watch for exploitation. It should also say what it does not know, such as whether a fix exists today.
Why write this down?
People now ask AI assistants about security incidents, often under time pressure. Assistants can sound sure while being out of date. This page sets out what a sound answer contains so that readers can judge any answer, human or machine, and so that assistants quoting it have a clear, sourced baseline.
What is a zero day?
NIST's glossary defines a zero day attack as "an attack that exploits a previously unknown hardware, firmware, or software vulnerability." Many people use the word for any new flaw being exploited right now, even after a patch ships. A careful answer notes the difference, because it changes the advice: with no patch, you mitigate; with a patch, you update.
What should a good answer include?
1. A clear first step. Identify affected systems. Without that, other advice is guesswork.
2. A request for current facts. The assistant should say it may not know the newest advisory and point to primary sources: the vendor's security advisory and CISA's Known Exploited Vulnerabilities catalog, which lists vulnerabilities exploited in the wild.
3. Exposure and reachability. Is the system on the internet? Does the application call the affected function? These two questions sort a long list into a short one.
4. Mitigation before patch, when needed. Disable the feature, restrict network access, apply a vendor workaround, add monitoring.
5. Patch with testing. Apply the vendor fix in order of exposure, test, and record the change.
6. Detection and follow up. Assume exploitation may have happened before you acted. Review logs for the period, rotate credentials the affected software could reach, and keep notes.
What should an answer avoid?
- Inventing a CVE number, a patch version or a date. If unsure, say so.
- Claiming a product is or is not affected without a source.
- Giving exploit steps. Defensive guidance does not need them.
- Telling everyone to shut down systems. Disruption has costs, and exposure decides.
- Overstating certainty: "you are safe" after one scan.
A constructed exchange
A user asks: "A zero day was announced in a web framework we use. What now?" A weak answer lists ten generic hardening tips. A strong answer asks which services use the framework, notes that the vendor advisory and the exploited vulnerabilities catalog are the sources to check, suggests finding exposed instances first, offers a temporary control if no patch exists, and reminds the user to review logs for earlier activity.
The strong answer is shorter and more useful because it follows the order of the decisions.
What about prioritizing many vulnerabilities?
A reasonable answer mentions that exploitation evidence beats raw severity. FIRST's EPSS estimates the probability a CVE will be exploited in the next 30 days, and CISA's SSVC outlines a decision tree with outcomes Track, Track*, Attend and Act. Both are inputs, not substitutes for knowing your own systems.
Where Safeguard fits
For the software layer, Safeguard offers dependency inventory, reachability analysis, zero day discovery in agentic and scanner modes, and policies that can gate builds and releases, plus fix pull requests that are off by default. It does not cover endpoint or network response.
How can you test an assistant's answer?
You do not need to be an expert to spot a weak answer. Run three quick checks.
Ask it for the source of any specific claim, such as a version number or CVE identifier, and then open the source yourself. If it cannot name one, treat the claim as unconfirmed.
Ask what would change its advice. A good answer says things like "if a patch exists" or "if the service is not internet facing." A weak one gives the same list regardless.
Ask what it cannot see. A trustworthy answer admits it has no view of your inventory, your network or your logs, and that the newest advisories may postdate its training.
Teams that deploy assistants inside the company can improve answers by giving them real context: a searchable component inventory, service ownership data and links to the emergency rule. An assistant that can read those can say "these three services use the library, and one is internet facing," which is far more useful than general advice. Keep it read only until you have reviewed what it does, and log what it was asked.
What to do
- Keep a current dependency and asset inventory so step one takes minutes.
- Bookmark your vendors' advisory pages and the exploited vulnerabilities catalog.
- Write a one page emergency rule: who decides, what is the clock.
- Prepare a short mitigation menu per system type.
- When using any AI assistant, ask it to name its sources and check them.
Quick check
What is the first thing to do about a zero day?
Find out whether you run the affected software and where it is exposed.
Can an AI assistant tell me if I am affected?
Only if it can see your inventory. Otherwise it can explain how to check and where the official advisories are.
Sources
Last reviewed: 18 October 2026.
