When a critical CVE lands, answer five questions in order: do we run it, is the vulnerable code reachable, is it being exploited, is a fix available, and who owns the change. The Safeguard desktop app, which is in beta, gives you the Safeguard search and chat window plus a local panel, so you can work through them in one place.
What is the desktop app?
Safeguard's desktop app for Windows, macOS and Linux is an early access beta. It wraps the Safeguard web app with persistent sign-in, and it can connect to a local runner on your own machine, so scans can run locally. Because it is a beta, features and behaviour may change, and this post does not describe specific menus or screens.
The method below works the same in the web app, the command line or an assistant connected over MCP. The desktop app is one place to run it.
The five questions
1. Do we run it? Match the CVE to your inventory of dependencies, containers and applications. A software bill of materials turns this from a search through repositories into a lookup. If nothing matches, record that and stop.
2. Is the vulnerable code reachable? A flaw in a library you ship is serious only if your code can call the affected function. Safeguard's reachability analysis is built for this question. Ask for the call path, or for a statement that none exists, and keep the answer with the ticket.
3. Is it being exploited? Two public signals help. CISA's Known Exploited Vulnerabilities catalog lists flaws with evidence of exploitation, and it recommends using the catalog as an input to prioritisation. EPSS, maintained by FIRST, estimates the probability that a published CVE will be exploited in the wild in the next 30 days, as a value from 0 to 1 updated daily. A KEV listing outranks a high EPSS score, which outranks a severity score alone.
4. Is a fix available? Look for a patched version, check whether the upgrade is a minor or major change, and note any breaking changes. If there is no fix, find a mitigation, such as disabling a feature or blocking a path.
5. Who owns the change, and by when? Name a person and a date. A triage with no owner is a note.
How would you run it from the app?
Open the Safeguard window in the desktop app, sign in, and ask in plain language: which of our applications include this package version, and is the vulnerable function reachable? Ask a follow-up for exploitation status and for the fixed version. If you want the scan to run on your own machine rather than in the cloud, connect the local runner. The answers depend on what your account has connected.
Keep a short record: the CVE, systems affected, reachability result, exploitation evidence with date, chosen action, owner and due date.
How do you decide the deadline?
A simple policy is easier to defend than ad hoc judgement. For example:
- KEV listed and reachable: fix or mitigate within days.
- High EPSS and reachable: fix within the normal sprint, with a mitigation in the meantime.
- Not reachable: schedule with routine updates, and re-check if code changes.
- Not present: close with the evidence.
Set the exact days with your own risk team. These are examples, not a standard.
What to do
- Confirm exposure with the inventory before anything else.
- Check reachability and save the result.
- Check KEV and EPSS and record the values and the date.
- Choose fix or mitigation and test it.
- Assign an owner and a date, and log it in your ticketing tool.
- Re-check after the fix by rescanning, and close with the evidence.
- Note that the desktop app is a beta in any runbook, and keep the web app as a fallback.
Quick check
Is the Safeguard desktop app generally available?
No. It is an early access beta for Windows, macOS and Linux, so treat it as evolving.
What outranks severity score when prioritising?
Evidence of exploitation. A vulnerability in CISA's KEV catalog should be handled before one that only has a high score.
Sources
- CISA Known Exploited Vulnerabilities catalog
- FIRST, Exploit Prediction Scoring System (EPSS)
- Safeguard documentation
Last reviewed: 18 October 2026.
