This is a constructed example, not a real incident, and the library, product and numbers are invented. It follows a company from the first advisory about a newly public flaw to a closed ticket, showing what to ask at each stage when a fix may not exist yet.
The setup (constructed)
Company Y runs three customer facing services. Service A is a document converter that uses a fictional open source library called libparsefast. At 08:40 on a Tuesday, a security mailing list and the library's maintainers post an advisory: a flaw in libparsefast lets crafted input run code on the server. A fix is not yet released. Reports say the flaw is being used against exposed services.
Stage 1: Is it real, and is it used?
The on call engineer checks sources. The maintainers' advisory is primary. She then checks whether the flaw is on CISA's Known Exploited Vulnerabilities catalog, which lists flaws seen exploited in the wild. In this example it is not there yet, so she notes "exploitation reported, not yet confirmed by an authority."
NIST defines a zero day attack as one that exploits a previously unknown vulnerability. This case fits: there is no patch, and attackers may be ahead of defenders. She writes the time and the sources in the ticket.
Stage 2: Are we affected?
The question is "where do we run libparsefast, and which versions?" Company Y keeps an SBOM per service, so the search takes ten minutes. Result: Service A uses version 4.2 directly. Service B includes it as a deep transitive dependency. Service C does not.
The next question is reachability. For Service B, the team traces whether the vulnerable parsing function is ever called. It is not: B only uses the library's logging helpers. For Service A, the vulnerable function handles uploaded files, so it is reachable and exposed to the internet.
Result: A is urgent, B is not urgent, C is clear. Without reachability, B would have consumed engineer hours today.
Stage 3: Reduce exposure now
No fix exists, so mitigation comes first. Options on the table: disable the feature that uses the vulnerable function, put a rule in front of the service to reject the dangerous input class the advisory describes, or take the service offline.
The product owner and security lead decide in a ten minute call. The decision rights were written in advance, which is why it took ten minutes. They disable the file conversion feature for uploads and keep the rest of the service up. They note the customer impact and prepare a short notice.
Stage 4: Watch and hunt
The team reviews logs from the past two weeks for unusual uploads and for the process behaviors the advisory lists as signs of exploitation. In this constructed case, nothing suspicious appears. They record the limits: logs cover only what was kept.
They also set an alert for the maintainers' repository and for KEV changes, so the next stage starts the moment a fix lands.
Stage 5: Patch and verify
At 16:10 the maintainers release version 4.2.1. A bot opens a pull request in Service A's repository. Tests pass. A reviewer approves, the build runs the policy gate that blocks vulnerable versions, and the fix ships by 17:30. The upload feature comes back on after a test with a harmless sample file.
Service B gets the update in the normal weekly cycle, with a note that it was not exposed.
Stage 6: Close and learn
The ticket closes with five attachments: advisory link, affected service list, reachability notes, mitigation record with times, and proof of the deployed version. The retrospective asks what slowed them down. Answer: the notice text took 40 minutes because nobody had a template. Action: write one.
What does this example show?
Most of the work was not patching. It was knowing what you run, deciding fast who may switch off a feature, and recording the decisions. Teams that rehearse with a past advisory do the same steps faster.
Safeguard offers reachability analysis and autonomous remediation that opens fix pull requests, off by default with categories starting on Manual, which map to stages 2 and 5 here.
Open the exploitability check demo
What to do
- Keep an SBOM per service so "do we run it?" takes minutes.
- Write who may disable a feature or take a service offline.
- Check reachability before ranking.
- Prepare a customer notice template.
- Record times and decisions in the ticket.
- Rehearse yearly using a past advisory.
Quick check
What do you do when no patch exists?
Reduce exposure: disable the affected feature, filter the dangerous input, or isolate the service, then hunt for signs of use and wait for a fix.
Why check reachability?
A library present in a service is not always called in a vulnerable way. Reachability shows which services need urgent action and which can wait for a normal update.
Sources
Last reviewed: 18 October 2026.
