Explain CVE reachability as a claim about a particular vulnerable behavior, application path, build and deployment. State what evidence connects an actor's input to that behavior, what controls or prerequisites interrupt the path, and what remains unknown. “We found no path in the reviewed source” is a bounded result; it is not the same as “this application is safe.” “The package is installed” is also narrower than “an attacker can exploit it.” If you cannot establish a decisive link, call the case under investigation and name the next check. The answer can change when a new route, configuration, dependency version or deployment appears.
The NTIA SBOM minimum elements report explains why a vulnerable upstream component does not always create risk in the downstream product: affected code may be removed, unreachable, or protected. CISA's VEX status guidance gives specific reasons for a “not affected” assertion, including vulnerable code not present, not controllable by an adversary, or not in an execution path. Each assertion needs a product and version scope and evidence adequate for the decision it supports.
The four questions hidden in “reachable”
People use the word for several different claims. Separate them in the finding note:
| Question | Evidence to seek | What a yes does not prove |
|---|---|---|
| Is the affected component in the resolved build? | SBOM or lockfile, package identity, artifact mapping | That the vulnerable function is included or called. |
| Is the vulnerable behavior present in the shipped code? | Source or binary evidence for the affected version and platform | That an attacker can provide the required input. |
| Can the application's path invoke it? | Callers, routes, jobs, configuration, feature flags and relevant controls | That the path is exposed in production or can be exploited. |
| Can a relevant actor meet the prerequisites and cause the effect? | Actor privileges, input control, authorization, parser settings, deployment and impact | That an exploit was executed or every alternative path is known. |
The OWASP dependency graph guidance distinguishes an inventory from the relationships among components. Even a useful dependency graph does not by itself show all application routes and controls. A source call graph is also only as complete as its language, dynamic behavior, configuration and reviewed scope permit. Record those limits rather than silently filling them with assumptions.
Illustrative case: a PDF parser in a report worker
Illustrative case, invented package and advisory: Atlas Portal's report service resolves pdf-reader@5.1.0; advisory DEMO-ADV-09 concerns a crafted document that triggers a parser flaw in that version. The package appears in a production service lockfile. A code search finds one direct call from an internal monthly report job. The job reads PDFs from a company-controlled template store. The security engineer has reviewed the job at revision r70, but has not reviewed who can write templates, whether a second route invokes the parser through a wrapper, or whether the same artifact is used by the public upload service.
The useful conclusion is: “The affected version is present. The one reviewed call site is not exposed directly to ordinary portal users; template-store write authority and the public upload artifact mapping remain unverified. Application exploitability is unresolved.” Calling it “unreachable” would assert more than the evidence allows. Calling it “critical customer-upload RCE” would invent a path that has not been traced. The security engineer can still recommend a patch, temporary restriction, or urgent investigation according to the potential impact; a precaution is not proof of exploitation.
Revise the explanation three times
Keep each version of Atlas's synthetic evidence note. An evolving conclusion should expose which fact changed it.
Version 1: one internal call found. The report job reads a company-controlled template store. The caller search has not established who can write it. The correct sentence is: “No ordinary-user entry was found in the reviewed job; template-write authority and indirect callers remain unresolved.” “Internal” describes the current observation, not a security boundary.
Version 2: template writers identified. The supplied policy allows a small administrator group to upload templates, and the reviewed deployment mapping ties the package to the report worker. This narrows the direct input actor to those administrators for that path. It does not remove the vulnerable operation or prove the input harmless. The note becomes: “The assessed monthly-report path can parse administrator-supplied templates; ordinary portal-member access to that input was not found in the reviewed policy.” Privileged input is still input.
Version 3: public import wrapper discovered. A second service accepts customer documents, but its mandatory converter emits a constrained intermediate representation before the parser call. In the fictional advisory, the triggering feature requires raw embedded object type X, and the supplied converter contract rejects X and cannot emit it. The reviewer checks every route to that parser in this named build rather than assuming all wrappers behave identically.
| Path at assessed build | Actor/input | Decisive condition | Defensible wording |
|---|---|---|---|
| Monthly report | Authorized template administrators, raw PDFs | Vulnerable parser behavior remains available | Restricted-actor path; applicability still needs precise prerequisite/effect review |
| Customer import | Customer upload converted through mandatory restricted representation | Triggering feature X cannot reach the parser under the supplied contract | Specific customer-import hypothesis defeated for this build and converter configuration |
| Unmapped older worker | Artifact/configuration unknown | No reliable path conclusion | Under investigation |
The converter conclusion is conditional on the mechanism: all input routes use it, its output cannot encode X, and the deployed build uses that contract. A size cap or an “internal service” label would not establish the same thing. Actual parser and converter behavior requires technical validation; these are invented semantics for the reasoning exercise.
If the organization publishes a product-specific VEX assertion, it must choose the narrow product/build scope its evidence supports. It cannot label the entire Atlas suite not affected while the administrator path and older worker remain open. The public communication can instead say that the assessed customer-import route is protected by the specified conversion boundary, while other named paths are being reviewed. That is useful assurance without promising global safety.
Build a defensible explanation
- Name the vulnerability precisely. Identify the CVE or advisory, the exact affected package and version range, the triggering behavior, and any platform or configuration conditions from the primary advisory. A generic description such as “parser issue” is too broad to decide reachability.
- Pin the product under discussion. Specify the application, component, source revision, dependency artifact, deployment and assessment date. A VEX statement for one product version cannot automatically cover later builds. CISA's VEX use-case document distinguishes affected, not affected, fixed and under investigation product statuses.
- Trace one path from actor to effect. Ask who can supply input, what entry point receives it, which transformations and controls apply, and which vulnerable function would run. Check a lower-level service or queue consumer when it is part of the path. A similar route with a check is not proof that this one has the same check.
- Try to defeat the proposed path. Look for a necessary authorization check, inaccessible feature, removed vulnerable code or input restriction. Worker isolation can limit consequences without preventing the vulnerable operation; do not count it as defeating reachability unless it blocks a specific prerequisite. Verify the control is on this path and active in the relevant environment. Record contrary evidence even when it lowers urgency. If source cannot establish a deployment condition, request release or runtime evidence from the owner.
- Choose wording that fits the evidence. “Reachable in reviewed source” means a supported call path, not a live exploit. “No path found” must name the search scope and blind spots. “Not affected” needs a narrow product/version statement and a defensible reason. “Under investigation” is the honest status when a decisive fact is missing.
Turn a reachability claim into a maintenance obligation
A reachability conclusion has a useful lifetime only while its decisive facts remain true. For Atlas's customer-import route, those facts are the mandatory converter, its inability to emit feature X, and the absence of a bypass to the parser in the named build. Record those dependencies alongside the conclusion. A later change that adds direct PDF import deserves a new review even if the parser version is unchanged. A documentation-only change does not necessarily invalidate the entire analysis.
The code owner can make this concrete in a change checklist: does the change add a new parser caller, broaden accepted input, alter the converter's output contract, or deploy the artifact to a new service? These questions connect the security conclusion to ordinary maintenance. They do not require every developer to reproduce the whole advisory investigation. The reviewer should explain which answer would reopen the claim and which evidence could preserve it.
Use equally careful language when a call search finds nothing. Record the searched source roots, entry points, wrappers, generated interfaces and unresolved dynamic behavior relevant to the question. A search for the package's public name might miss an alias or an indirect wrapper. Instead of turning that possibility into an endless investigation, identify the caller or deployment inventory that would meaningfully reduce uncertainty. If that evidence is unavailable, the report can still describe the bounded search and recommend an update on maintenance grounds.
A useful peer review asks the second person to challenge one link. In the Atlas example, ask whether every customer document must pass through the converter before reaching the parser. Provide the entry-point map and the proposed conclusion, then invite contrary routes. This is more focused than asking whether the application “looks safe.” The answer may confirm the reviewed boundary, reveal a bypass candidate, or leave an interface unresolved. Each outcome improves the wording without requiring an exploit.
Finally, make the communication match the recipient's decision. Engineering needs the exact caller and control dependency. A product owner needs to know whether restricting imports changes the exposure while a patch is prepared. A customer may need the affected product version and the status of the investigation without private source paths. These are different views of the same evidence, not different technical verdicts. When one view says “unreachable” and another says “under investigation,” reconcile them before sending either. The strongest accurate sentence is the one whose scope survives being copied out of the original report.
Keep scores and decisions distinct
A CVSS score describes attributes of a vulnerability under its specification; FIRST's CVSS v4.0 specification separately defines attack vector, complexity, requirements, privileges and user interaction. It does not replace a review of this application's code and environment. FIRST's EPSS guidance describes an estimate that exploitation activity for a CVE will be observed across its data partners in the next 30 days; it is not the probability that Atlas Portal will be compromised, nor proof that its parser path is exposed. Neither metric should overwrite the source and deployment evidence in the finding.
Business priority is another decision. A hard-to-reach path in a sensitive service may still deserve early work; a reachable low-impact path may be scheduled differently. State technical severity, practical exploitation difficulty, uncertainty and business priority separately so engineering and leadership know which judgment they are approving. The person explaining reachability should not silently convert “unknown” into “low risk.”
For the next disputed CVE, fill the four-question table and write a short evidence note naming the build, actor, input path, decisive control, remaining unknown and next check. If the package may not ship at all, start with how to check whether a vulnerable package is deployed. For the broader inventory boundary, read what an SBOM cannot tell you about exploitability.