With five minutes and a phone, rank findings by four questions: is the vulnerable package in something that is exposed, does your code reach the vulnerable function, is it being exploited, and is a fix available. Then route each finding to an owner. Do not fix anything from the phone unless it is small and tested.
Set a goal for the five minutes
Triage on a phone is not about solving. It is about making sure the right person knows the right thing, soon. The output is a short list: urgent now, this week, later, and noise. Anything else is wasted effort on a small screen.
The four questions
- Exposure. Is the affected component in an internet facing service, an internal tool, a test fixture or a build only dependency? Exposure changes urgency more than the severity label does.
- Reachability. Does your code call the vulnerable function or load the affected path? A finding in a library you import but never call in a vulnerable way is far less urgent than one on a hot path. Reachability analysis answers this for you, so you are not guessing from a package name.
- Exploitation. Is there evidence of active exploitation or a public exploit? Check whether the advisory or a known exploited vulnerabilities list mentions it.
- Fix. Is a fixed version out, and is the upgrade small? A patch release is a different task from a major version jump.
Write the answers as a line per finding: package, exposed or not, reachable or not, exploited or not, fix or not.
Click through it at your own pace, or open it full screen.
Sorting into four buckets
- Urgent now: exposed, reachable and either exploited or a trivial fix. Wake the owner.
- This week: reachable but not exploited, or exposed with no confirmed reach.
- Later: not reachable, not exposed, or build only. Schedule, do not ignore.
- Noise: false positives, duplicates, and test only code. Close with a note, or ask the owner to.
Keep a "later" list. Findings that are unreachable today can become reachable after a refactor, so review the bucket on a schedule.
Route, do not fix
Send each urgent finding to a named owner with the one line you wrote. A good handoff message has four parts: what, where, why it matters, and the fix version if there is one. "libfoo in checkout service, reachable, fix in 2.3.1, can we patch today?" is enough for a human to act.
If your tool creates fix pull requests, treat the phone as the place to look at them, not to merge them blindly. See reviewing vulnerability alerts from your phone safely for what to leave for a laptop.
Avoid these traps
- Sorting by severity score alone. A critical score on unreachable code is less urgent than a medium on a hot path.
- Opening every finding. Scan the list, pick the top few, and stop.
- Approving fixes you cannot read. A rushed merge can cause more trouble than the finding.
- Closing noise without notes. The next person will reopen it.
A short on-call routine
- Open the list. Filter to findings new since your last check.
- Run the four questions on the top five.
- Message owners for urgent items.
- Add a calendar note for the "this week" bucket.
- Close the app.
Where Safeguard fits
Safeguard's reachability analysis marks which findings your code can actually reach, and its iOS and Android apps show the same answers about your scanned projects and CVEs on a phone, as listed on the download page. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Should I rank findings by CVSS score alone on a phone?
No. Use exposure, reachability, exploitation and fix availability alongside the score. A high score on code you never call is less urgent than a medium score on an exposed hot path.
Can I fix a finding from my phone?
For small, tested changes your policy allows, yes. Otherwise route it to the owner and fix it on a laptop where you can read the full diff.
Sources
Last reviewed: 19 October 2026.
