Assess vulnerable code paths without overstating certainty
Trace an affected dependency from application entry points to the vulnerable behavior. Record supporting evidence, counterevidence, dynamic paths, and unknowns.
Reachability review asks whether the affected behavior can be invoked in a particular application and configuration. It follows an accurate version match. Do not start by searching for the package name once and closing the alert when the search finds nothing. Wrappers, plugins, reflection, and build-time execution can hide relevant paths.
GitHub describes reachability as a prioritization input for dependency alerts. Treat automated analysis as evidence with stated coverage, not as proof that all unobserved paths are impossible.
Describe the vulnerable behavior first
Read the maintainer's advisory and identify the affected function, feature, or configuration. Record the input conditions and required authority at a level useful for defensive review. You do not need to run a public exploit against production to map the call path.
| Review element | Evidence | Possible conclusion |
|---|---|---|
| Package occurrence | Release artifact and exact version | Component present or unresolved |
| Application entry point | Route, job, plugin, or build step | Candidate path identified |
| Affected feature | Calls and configuration | Enabled, disabled, or unknown |
| Input control | Source and validation boundary | Attacker influence bounded or unresolved |
| Counterevidence | Exclusion or removed code | Narrow reason a specific path is absent |
Keep runtime and build-time use separate. A component absent from the server bundle may still execute in a privileged release job.
Follow real application transitions
Trace imports and callers through wrappers to the affected operation. Inspect feature flags, optional adapters, and environment-specific configuration. When using tests, choose harmless fixtures in an authorized isolated environment and record what they actually exercise.
A test that did not execute the feature is not negative evidence. A static analyzer's unsupported language or missing generated code should remain an explicit limitation. Also consider alternate entry points such as administrative imports and background jobs.
Write an evidence-bounded decision
Use conclusions such as reachable, not demonstrated, or excluded under a named configuration. Explain the evidence behind any stronger claim. Assign a reviewer and a trigger for rechecking, such as enabling a plugin or changing the deployed artifact.
Retain the upgrade task when uncertainty remains material. Do not let a temporary configuration assumption become a permanent suppression. The useful output is a call-path record that supports a remediation decision for a specific release, while separating demonstrated behavior from absence of observation.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.
Sources
- GitHub: Dependabot alertsAccessed