Yes. When you delete code and the libraries only it used, the findings tied to those libraries disappear, with no patching. It is often the cheapest fix in a legacy application, provided you prove the code is really unused before removing it.
Why legacy apps carry so much dead weight
Systems that have grown over many years collect features nobody uses, abandoned modules and libraries that remain in build files after the code that needed them left. Fowler notes that much of what a legacy system does is behavior that is not really wanted. A scanner does not know that. It reports every vulnerable component in the build, used or not.
Three kinds of removable weight
- Unused dependencies. Declared in the build, never imported.
- Dead modules. Compiled and packaged, but no route, job or caller reaches them.
- Dead features. Reachable in theory, but no user has touched them in a long time.
How to find them, safely
- Static analysis for unused imports and modules. Most build tools can report declared but unused dependencies.
- Reachability analysis. Flag vulnerable libraries whose vulnerable functions are never called. This points to candidates, though it does not prove a library can go.
- Runtime evidence. Check access logs, job schedules and metrics for the feature over a full business cycle, including month end and year end jobs.
- Ask owners. A short message to the owning team and to support often turns up a known customer.
| Evidence | Confidence the code is dead |
|---|---|
| No import found | Medium, reflection can hide use |
| No route or schedule reaches it | Medium to high |
| No logged use over a full cycle | High |
| Owner confirms | High |
How to remove it with a way back
- Put the feature behind a flag set to off, and watch for errors.
- Remove the code and the dependency in separate commits.
- Rebuild and rerun tests.
- Rescan and compare to the baseline.
- Keep the version control history so you can restore it.
The strangler facade helps here. If a route was never used, retire the route at the facade first. Requests that fail loudly tell you quickly whether someone needed it.
What to expect afterward
The count of findings drops, and the attack surface drops with it, because code that is gone cannot be exploited. Record the before and after numbers for your modernization report. See security findings in legacy code nobody owns for handling modules with no owner.
Try it yourself
Click through it at your own pace, or open it full screen.
See which findings sit in code that is never called. Those are your first deletion candidates, subject to the runtime checks above.
Safeguard's reachability analysis and dependency scanning can produce that candidate list, and the free scan at gold.safeguard.sh/scan is a quick start.
Quick check
Is unreachable code safe to leave in place?
It is lower risk, but it still adds findings and attack surface, and reachability can change with a later edit. Deleting it is better.
Can reflection hide usage?
Yes. Static analysis can miss code called by name at runtime, so back it with runtime evidence.
Sources
Last reviewed: 19 October 2026.
