When severity is equal, fix the internet facing service first, because an outsider can reach it without any other foothold. But exposure is not the only input. Check whether the vulnerable code is reachable, whether the service handles sensitive data, and whether the finding is on a known exploited list.
The default rule and why it holds
An internet facing service can be probed by anyone. An internal service usually needs an attacker to be inside the network first. So the same flaw is usually more urgent on the outside facing system.
The rule is a default, not a law. Three situations flip it.
When internal goes first
- The internal service holds far more sensitive data, such as a database gateway.
- The finding is on a known exploited list and the exposed service's flaw is unreachable.
- The internal service is reachable from many other services, so one compromise opens a path to the rest.
Decision table
| Question | If yes | If no |
|---|---|---|
| Known exploited? | Fix first, any service | Continue |
| Reachable from your code? | Keep priority | Lower, not zero |
| Internet facing? | Move up | Keep or lower |
| Holds sensitive data? | Move up | Keep |
| Many services trust it? | Move up | Keep |
Work through it top to bottom for each pair of candidates.
Reachability and exposure are different
Exposure asks whether an attacker can reach the service. Reachability asks whether the vulnerable function can be called from your code. A service can be fully exposed and still not call the vulnerable code path. It can also be internal and fully reachable. Use both signals together.
A quick worked pair
Service A is public, uses a library with a high severity flaw, and never calls the affected function. Service B is internal, uses the same library, and calls the affected function on user supplied data from a queue. Many teams would fix B first, or at least in the same day. The labels exposed and internal did not decide it. The code path did.
Avoid the trap of perfect ordering
If two items are close, fix both. Ordering matters most when capacity is tight. If you have the capacity, the cost of debate exceeds the cost of doing both. Keep the reasoning in the ticket so the next person sees it.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which findings drop in priority when reachability is considered.
Quick check
Is an internal service ever safe to leave?
Only when the finding is low impact and unreachable. Record it with an owner and review date.
Does reachability replace exposure?
No. They answer different questions, and the best order uses both.
Safeguard includes reachability analysis, and you can run a free scan to see results on one project.
Last reviewed: 19 October 2026.
