To triage a critical vulnerability, ask four questions in order: do we ship it, is it exploited, can our code reach it, and what is the smallest fix. The Safeguard web app at app.safeguard.sh is chat first, so you can put those questions in plain language and work from the answers.
Why triage by question?
A critical score tells you the worst case. It does not tell you whether you are exposed. The work is turning one scary number into a decision: fix today, fix this sprint, or note and move on.
Chat suits that because the questions come one at a time and each answer shapes the next. Safeguard's web app is built so the platform can be driven from chat, so you do not have to know which page holds which view.
We are not going to describe individual buttons or screens here. The routine matters more than the interface, and the interface will keep changing.
Question 1: Do we ship it?
Start with presence. Ask which of your applications include the affected package and which versions. You want a list of products and the dependency path, because a flaw three levels down is reached differently from one you import directly.
If the answer is none, write that down with the date and stop. That record is useful when someone asks next week.
Question 2: Is anyone exploiting it?
Check the Known Exploited Vulnerabilities catalog from CISA, which lists flaws seen exploited in the wild, and the EPSS score from FIRST, which estimates the chance of exploitation in the next 30 days on a scale from 0 to 1. Safeguard's prioritization combines these kinds of signals with reachability, so you can ask for them together.
An exploited flaw in an internet facing service moves to the front. A high CVSS score with no exploitation and no exposure can wait a little.
Question 3: Can our code reach it?
Reachability analysis checks whether your code path actually calls the vulnerable function. Ask Safeguard whether the affected code is reachable from your application. If it is reachable on a request path, treat it as urgent. If it is not, lower the urgency but keep the finding open until the dependency is updated, since code paths change.
Treat the answer as evidence, not as proof. A tool can miss dynamic calls, and you know your architecture better than any scan.
Question 4: What is the smallest safe fix?
Ask whether a patched version exists and what upgrading would change. Look for breaking changes between your version and the fixed one. A patch release is a small step; a major version jump is a project.
If no fix exists, ask for mitigations: a configuration change, a feature you can disable, a rule at the edge. Record the mitigation and an owner.
What to record
Keep a short note for each triage: the CVE, the products affected, the exploitation signals, the reachability result, the decision and the person who owns it. That note is your audit trail and your handoff to the next shift.
What to do
- Ask which of your applications include the package and which versions.
- Check KEV and EPSS for exploitation evidence.
- Ask whether the vulnerable code is reachable from your application.
- Ask for the smallest fix and any breaking changes, or a mitigation if no fix exists.
- Decide: fix now, fix this sprint, or monitor.
- Write the decision, owner and date in your tracker.
Quick check
Does chat replace the dashboards?
No. Chat is another way in. Use it to ask questions quickly, and use the views when you want to scan a whole list.
Should I act on a chat answer without checking it?
Check anything that leads to a production change. Use the answer to decide where to look, then confirm against the source advisory and your own code.
Sources
- CISA Known Exploited Vulnerabilities catalog
- FIRST, Exploit Prediction Scoring System
- Safeguard documentation
Last reviewed: 18 October 2026.
