What is the difference between a reachable dependency finding and an exploitable one?
answer
- two gates, not one
- does the code run at all
- can an outsider drive the input
- name the attacker or the claim is empty
basics
~10 sReachability asks whether your application ever executes the vulnerable code. Exploitability asks whether an attacker in some position can drive that code with input they control. Code can be reachable and still not exploitable.
solid answer
~50 sReachability is a property of your code: is there any execution path from an entry point of your application into the vulnerable function of the dependency? Exploitability is a property of your deployment plus a stated attacker: can someone in that position supply the data, or trigger the conditions, that turn execution into a compromise? The two come apart in both directions. A service that links a vulnerable XML parser but only parses its own config file at boot executes the vulnerable code every start — reachable — yet no tenant or internet user can influence what it parses, so it is not exploitable by them. The same library version in a sibling service that parses tenant-uploaded documents is both. You must always name the attacker position when you claim not exploitable, otherwise the claim is unfalsifiable and it will not survive review.
go deeper
Be able to state that reachability is about whether your code runs the vulnerable function, and exploitability is about whether an attacker can feed it, and that the two are not the same.
Explain how the two gates come apart with a concrete case — same library in two services, one parsing uploads and one parsing its own config — and why exploitability presupposes reachability but not the reverse.
Demonstrate the discipline of writing a falsifiable verdict: the attacker position, the input path and any control you are leaning on, so the decision can be re-tested when the service changes shape.
Own the policy consequence: verdicts belong to artifacts rather than to packages, so resist fleet-wide not-exploitable rulings and make sure the controls your triage leans on are themselves protected from quiet removal.
## Two questions, not one Triage of a dependency finding runs through two independent gates, and interviews probe whether a candidate keeps them apart. **Reachability — does the vulnerable code run?** This is a question about your program. Is there a path from any entry point your application actually has (an HTTP handler, a message consumer, a scheduled job, a CLI command, framework startup) into the vulnerable function of the dependency? If nothing in your program ever transfers control there, the flaw sits in your artifact like an unused book on a shelf. **Exploitability — can an adversary make it matter?** This is a question about your deployment *relative to a named attacker*. Given someone in a stated position — an anonymous internet user, an authenticated low-privilege tenant, an operator with legitimate access, a compromised upstream — can they supply the input or create the conditions the flaw requires, and does doing so yield something they want? Exploitability presupposes reachability, but reachability does not imply exploitability. That asymmetry is the whole content of this question. ## The worked case: one library, two services A multi-tenant document platform runs two services, both linking the same version of an XML parsing library with a known entity-expansion flaw. *Service A* accepts document uploads. Any authenticated tenant — the lowest-privilege account on the platform — can post a file that goes straight into the parser. The vulnerable code executes on attacker-chosen bytes, and a successful attack lets that tenant read files or exhaust the process, putting **other tenants' documents** at risk. Reachable: yes. Exploitable by an authenticated low-privilege tenant: yes. This is the finding that gets a remediation clock. *Service B* links the same library and calls it exactly once, at boot, to parse a configuration file baked into the image. The vulnerable function unquestionably executes — a naive reachability tool will light it up green. But the only party who can change that file is someone who can already change the deployed artifact. Reachable: yes. Exploitable by a tenant or an internet user: no. Exploitable by an operator who can already alter the image: yes, but that attacker has better options, so the finding carries almost no marginal risk. Same component, same version, same advisory, two different answers — and only the second gate produced the difference. ## Naming the attacker is not optional "Not exploitable" with no attacker named is the most common weak answer here. Exploitability is always relative to a position, and positions change: an endpoint moves from internal to internet-facing, a service acquires a public queue consumer, a partner is granted an API token. A claim written as "not exploitable by an authenticated tenant, because the parser is only invoked on the boot-time config file" states its own falsification condition. A claim written as "not exploitable" does not, and a year later nobody can tell whether it is still true. ## Other things that decide the second gate - **Input provenance.** Does the data reaching the vulnerable function originate outside a trust boundary, or is it entirely internally produced? - **Preconditions in the flaw itself.** Many require a specific non-default configuration, a particular feature to be enabled, or an authenticated session; if your usage cannot satisfy them, exploitability fails even where the code runs. - **Consequence.** A flaw that only crashes a stateless worker behind a restart loop is a different risk from one that discloses another tenant's data, even at identical technical difficulty. - **Existing controls in the path.** A size limit, a schema validation step or a sandboxed process can remove the precondition. Record the control you are relying on, because that control is now load-bearing and someone may delete it. ## Where the pair gets misused Two failure modes are worth naming. The first is calling a finding exploitable because the library is *installed* — that skips both gates and collapses back to a presence match. The second is calling it not exploitable because the input is "internal", without asking who can put data into that internal channel; in a multi-tenant system a great deal of "internal" traffic is originally attacker-authored. ## What to say in an interview Define both gates in one sentence each, say explicitly that exploitability presupposes reachability but not vice versa, give the one-library-two-services example, and finish on the discipline: a not-exploitable call must name the attacker position and the code path it depends on, so the claim can be re-tested when either changes.
- Can a finding be exploitable but not reachable?Not in the strict sense — an attacker has to make the vulnerable code run somehow. What happens in practice is that a tool reports unreachable and is wrong, so the finding looks unreachable while being fully exploitable. Treat "unreachable" as a tool's verdict about its own model of your program, not as a property of the program.
- You call a finding not exploitable because a size limit blocks the payload. What does that obligate you to do?Record the control as the reason, and make it durable. The claim now depends on that limit existing, so it belongs in the triage note by name, ideally with a test that fails if the limit is removed. Otherwise a routine refactor silently invalidates a risk decision that nobody re-reads.
- Why does the same component version get different verdicts in two services?Because both gates are properties of the consuming application, not of the component. Service-level call paths and attacker positions differ even when the resolved version is identical, so a fleet-wide verdict on a package is almost always wrong in one direction. Triage per artifact, and let inventory tell you where else to look.
Reachability asks whether the wire is live. Exploitability asks whether anyone outside the building can touch it.
saying these in an interview costs you the question
- Uses reachable and exploitable interchangeably
- Calls a finding exploitable because the library is installed
- Says not exploitable without naming an attacker position
- Assumes internal input is inherently trusted
- Ignores the flaw's own preconditions and required configuration