Governance
Configure fix approvals, protected paths, and account settings in one place.
Security commentary
How Agents Can Improve Reachability Analysis in the Software Supply Chain
Connect dependency inventory to code paths while preserving uncertainty about runtime behaviour.
A dependency record is the starting point
A software inventory can show that an application includes a package with a reported vulnerability. The next question is whether relevant code can be reached from an input or operation available in that deployment. This is a different question from whether the package exists in a lockfile. A dependency may be included only in development, removed from a runtime image or used through a feature that is disabled in one environment and enabled in another.
Start with a precise component identity, version or build, and the vulnerable functionality described by the upstream advisory. Keep the evidence for that mapping. Similar package names or a broad version range can otherwise send an investigation toward the wrong implementation.
Follow the application boundary
Map the application's entry points to the dependency's relevant API. Consider HTTP routes, background workers, import jobs, command-line utilities and scheduled maintenance. A call graph can help identify candidate paths, while data-flow analysis can help investigate whether an untrusted value reaches a sensitive operation. The two analyses answer related but distinct questions: code may be called without receiving the input required to trigger a particular issue.
Dynamic loading, reflection, generated code and framework conventions can make this analysis incomplete. Treat a missing edge as an uncertainty to investigate rather than proof that the path cannot exist. Preserve the tool's assumptions and the source revision used to construct the graph.
Use an agent to investigate missing context
An agent can assist by reading configuration, locating wrappers and explaining how application code invokes a dependency. Ask it to return source locations and a chain of evidence for each conclusion. For example, a queue consumer might call a parser through a shared adapter rather than from the visible web route. The useful output is the documented connection, including the account or input boundary involved, not a confident label detached from the repository.
Constrain the investigation to authorised repositories and environments. Do not let a generated test fetch arbitrary external targets or assume access to production data. When execution is needed, use a controlled fixture and record whether it validates the claimed path or merely demonstrates that a component can be loaded.
Keep the verdict attached to its conditions
Use separate states for present, potentially reachable, confirmed reachable and not observed under the tested conditions. A reachability finding should include the relevant feature flags, runtime configuration and deployment artefact. Invalidate or review the conclusion when those conditions change. A new route or a dependency upgrade can make an older analysis stale without changing the application's top-level architecture.
Prioritisation should combine this evidence with impact, exposure and remediation options. Reachability can reduce wasted investigation, but it should not be used as an unexplained switch that suppresses an advisory forever. A defensible decision tells the next engineer why the path matters, what was checked and what change would require the team to look again.
