No. Dead code removal shrinks what you ship by deleting code that cannot run, while reachability analysis tells you whether a known vulnerable function can run. They share the same idea, finding what is unreachable, but compilers and bundlers usually cannot see into every dependency, and they are not driven by vulnerability data.
What dead code elimination does
Dead-code elimination is a compiler optimisation that removes code which does not affect the program's results. Wikipedia describes it as reducing program size and avoiding unnecessary computation. It is aimed at performance and size. It is not designed as a security control, and the compiler does not know which functions have advisories.
Where it helps security
Less shipped code means a smaller attack surface in practice. If a bundler drops an unused module, a vulnerability in that module is not in your deployable artifact. That is real value, and in some ecosystems tree shaking removes a good share of unused library code.
Where it falls short
| Limit | Why it matters |
|---|---|
| Conservative removal | Compilers keep code when they cannot prove it unused, so reflection or side effects keep things alive |
| Scope | Often applies to your build output, not to every installed package on disk |
| No advisory data | It does not label which removed or kept function matches a CVE |
| Evidence | No record you can show an auditor of why a finding is not applicable |
So an artifact can still contain a vulnerable function that nothing calls. Dead code removal might not delete it, and without reachability you would not know it was safe to defer.
How the two fit together
- Use tree shaking and similar settings to reduce what ships. This lowers the number of findings before you analyse anything.
- Run reachability analysis on the artifact you ship, matched against advisory data.
- For findings marked not reachable, record the evidence and set a recheck trigger.
- For reachable findings, plan the fix.
Think of dead code removal as hygiene and reachability as a triage decision with evidence.
A caution on claims
Some teams say "we strip unused code, so we are not affected". That is only true if you verified the vulnerable function is absent from the final artifact. A check on the built output, such as searching the bundle or inspecting the symbols, is the evidence. The VEX vocabulary even has separate reasons for this, one for code not present and one for code present but not on an execution path, because they are different claims.
Safeguard includes reachability analysis alongside SBOM and dependency scanning, and you can run a free scan at gold.safeguard.sh/scan to see the output on your own repository.
Quick check
If a bundler removed the module, am I safe?
You are safe from that function in that artifact, if you confirmed it is absent from the built output. Keep the check as evidence.
Does reachability analysis remove code?
No. It labels findings. Removal is a separate build step.
Sources
Last reviewed: 19 October 2026.
