In a healthcare application, rank vulnerabilities first by whether the vulnerable code sits on a path that reads, writes or exposes patient data, then by exploitability and exposure, and only then by severity score. A medium flaw in the record API often matters more than a high flaw in an unused build tool.
Why score alone misleads
A severity score describes the flaw in general, not in your system. Scanners on a typical service return hundreds of findings. Most are in code that never runs in production, sits behind authentication or never receives untrusted input. Treating all highs the same burns weeks and still leaves the dangerous one for later.
Step 1: map where patient data lives
List the stores and flows: databases, object storage, message queues, caches, exports, logs, analytics and backups. For each, note the services that can read it. This is the same inventory regulators and auditors tend to ask for, so the work does double duty.
Step 2: mark the paths
Draw the request paths that reach those stores. Mark the ones that face the internet, the ones that face partners and the ones internal only. Include integrations with devices and third party systems.
Step 3: place each finding
For every vulnerability, answer four questions.
- Is the vulnerable component in a service on a patient data path?
- Is the vulnerable function actually reachable from the entry points?
- Can an outside party reach that entry point?
- Is there a public exploit or evidence of use?
Reachability analysis answers the second question automatically for many findings, which cuts the list sharply. A finding that is unreachable in your build can wait for the next planned update.
Step 4: set response times
A simple scheme works: findings on a reachable, externally exposed patient data path get the fastest target, reachable internal ones next, everything else goes into routine upgrades. Write the targets down and report on them monthly.
Step 5: watch the build chain too
Compromised packages and CI tokens bypass your runtime controls entirely. Include build dependencies in the inventory and pin versions.
What not to do
Do not suppress findings without a recorded reason. Do not rely on a network scan to see library flaws. Do not assume a vendor component is clean because it is certified for something else.
Where Safeguard fits
Safeguard offers dependency and SBOM scanning, reachability analysis and, if you turn it on, autonomous remediation with fix pull requests, which is off by default with every category on Manual. You can try the free scan at gold.safeguard.sh/scan. Regulatory conclusions are for your compliance and legal teams.
Reporting the result
A monthly one page report keeps the method honest. Show counts of findings by path category, how many were closed in target, and how many reachable findings remain open with owners. Add a line for exceptions with expiry dates. Leadership then sees risk in terms of patient data paths, not raw counts, and engineers can see why a small number of items are urgent. Revisit the data map whenever a new integration ships, since the paths change with it.
Quick check
Should we ignore findings that are not reachable?
Not permanently. Park them with a reason and review when the code changes or new entry points appear.
Last reviewed: 19 October 2026.
