Reachability analysis or a pen test: which question does each answer?

Reachability analysis asks whether your code can reach a flaw that is already known in a package you use. A penetration test asks whether skilled testers can break into your system by any route, known or not. They answer different questions, run at different speeds, and work well together.

TL;DR

• Reachability analysis is a fast, repeatable check on known flaws in the software you depend on.
• A penetration test is a human led attempt to break in, which can find mistakes that no database lists.
• Neither replaces the other, and neither replaces a basic scan.
• Use reachability analysis every time code changes and a penetration test on a schedule or after big changes.

Definition: penetration test. A security test in which assessors, working under agreed limits, try to get around the protections of a system, imitating real attacks. The US standards body NIST describes it as a test in which evaluators mimic real-world attacks to find ways to circumvent the security features of an application, system or network.

What question does each method answer?

Picture a bank vault. A list from the lock maker says "locks of model 7 have a known weakness." That is a vulnerability alert. Someone checks whether your vault uses model 7, and whether the weak part is the part guarding the door. That is reachability analysis. Separately, you hire a team to try to rob the vault, using any trick they can think of, including ones the lock maker never heard of. That is a penetration test.

Reachability analysis takes a known flaw in a package and checks whether your own code can get to it. It works on the list of known flaws, which come from public databases. It follows the paths in your code. Its answer is: "this known flaw can be reached from your code," or "it cannot," or "we cannot tell." It runs automatically and can run on every build.

A penetration test does not start from a list. Testers look at your whole system, including your own code, settings, logins, and how pieces connect. They try things. They may chain small weaknesses into a big one. They may find a flaw nobody has reported. Their answer is: "here is how we got in, or here is what we tried and could not do." It is done by people, in a window of time, and it costs real effort.

NIST's glossary also records a related definition: a method of testing where testers target individual components or the whole application to determine whether vulnerabilities can be exploited to compromise the application, its data or its environment. The word "determine whether vulnerabilities can be exploited" is the link between the two methods. Both are trying to learn what is truly exploitable. They come at it from opposite ends.

What does each method miss?

Every method has blind spots. Knowing them stops you from over trusting either one.

What reachability analysis misses. It cannot find flaws that are not on a list. If a flaw has not been reported, the tool has nothing to match. It does not test your login system, your settings, or your business logic. It can also be wrong about reachability in code that works through plugins, reflection or other run time tricks. The honest tools say "unknown" in such cases. Reachability is also a view of your code at one commit, so it needs to be rerun as code changes.

What a penetration test misses. It is a snapshot. It reflects the system at the time of the test, in the scope that was agreed. Code changes the next day. It cannot cover every dependency and every version of every package in the way an automated scan can. Testers have limited time, so they may not test every path. A test that finds nothing does not prove nothing is there; it shows what the testers tried within their limits.

What both miss. Neither one fixes anything. Neither one watches your system after the report is delivered. And neither one replaces a daily habit of updating dependencies and watching for new advisories.

How do they work together?

Think of them as two lenses on the same question: what can an attacker do to us?

Reachability analysis handles breadth and speed. It checks every known flaw in every package against every build, so no known flaw escapes a look. A penetration test handles depth and creativity. It looks for the surprising route.

They also feed each other.

• Reachability results guide testers. A list of reachable flaws on internet facing services is a map of where to look. It saves tester time.
• Penetration test results guide the code. If testers get in through a particular library, you can check whether other places use the same weak pattern.
• Both produce evidence. A reachability result is evidence that you checked a known flaw on a given date. A test report is evidence that skilled people tried to break in and what happened.

The US directive BOD 26-04 shows how much weight CISA puts on exposure and on known exploitation when setting urgency. It names four variables: whether the asset is publicly exposed, whether the flaw is on the Known Exploited Vulnerabilities (KEV) catalog, whether the attack can be automated, and how much control the attacker gains. A reachability check supports the first and last of these for your own code. A penetration test gives a human check on whether an attacker could actually chain them.

What does this look like in a worked example?

The numbers here are invented for illustration.

A company runs a customer portal. In one quarter, the team does three things.

1. Every build, reachability analysis. Over the quarter, the tool checks 40 builds. It lists 300 known flaws across the packages. For 240 it finds no path from the portal's code. For 45 it finds a path but with conditions that are not met in production. For 15 it finds a live path. The team fixes the 15 in two sprints.
2. Once, a penetration test. In the second month, outside testers spend two weeks on the portal. They find a flaw in the portal's own password reset logic that allows an attacker to take over an account when a certain sequence of steps is followed. No database listed this flaw because it is the company's own code. They also find that an admin page is reachable from the internet when it should not be.
3. A shared review. The team compares the two results. The reachability list shows no flaws on the password reset path, which fits, because the problem was in their own logic. The admin page finding changes the exposure of three reachable flaws from "internal" to "internet facing," so the team moves them up the queue.

Neither method alone would have given the full picture. Reachability analysis could not have found the password reset mistake. The penetration test could not have checked 300 known flaws across 40 builds.

How do you decide what you need and when?

Use this simple decision guide.

1. Do you scan your dependencies for known flaws? If not, start there. It is the base layer for both methods.
2. Do you get hundreds of alerts and cannot tell which matter? Add reachability analysis.
3. Do you handle sensitive data, or do customers ask for proof of testing? Add a penetration test on a schedule, and after major changes to login, payments or data handling.
4. Did you make a big change? Run reachability analysis on the new code at once, and consider a targeted test of the change.
5. Do you need to answer a customer question about exploitable flaws? Use reachability analysis to supply the numbers, and a test report as supporting evidence if you have one.
6. Write down the results of both with dates. A result without a date goes stale fast.

If a customer or regulator asks for a penetration test, read their wording to see what they mean. This post is general guidance and not legal advice.

What can Safeguard do to help?

Safeguard covers the reachability side. It scans your dependencies, builds an SBOM, and runs reachability analysis that traces your call paths into each vulnerable function, so you can see which known flaws sit on a live path. An exploitability check adds evidence on whether a reachable flaw can be used today. Zero-day discovery matches new advisories to the versions in your projects. Policies and gates let you set rules for what blocks a release.

Safeguard does not replace a penetration test by skilled people. Autonomous remediation with fix pull requests exists too, off by default with every category on Manual. Try a free scan at gold.safeguard.sh/scan.

For related reading, see DAST versus penetration testing, reachability analysis questions and answers and what reachability analysis is.

Try it yourself

Click through it at your own pace, or open it full screen. Notice that the tour starts from a list of known flaws and traces your own call paths into each one, which is the known flaw question, not the break in question.

Quick check

Sources

• NIST CSRC glossary: penetration testing
• NIST CSRC glossary: vulnerability
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk

Last reviewed: 19 October 2026.