An entry point is where execution can begin: a main function, an HTTP handler, a message consumer, a scheduled job. Reachability asks whether a path runs from an entry point to a vulnerable function. If the tool starts from the wrong set, it will call real paths unreachable or dead paths reachable.
What counts as an entry point
- The main function or program start.
- Web routes and API handlers.
- Queue and event consumers.
- Scheduled jobs and command line commands.
- Exported functions of a library that others call.
- Framework hooks that the framework invokes for you.
Some are obvious in code. Others exist only because a framework or config file wires them up.
Applications and libraries differ
For an application, entry points are the ways the program is started or triggered. For a library, almost every public function is an entry point because you cannot know who calls it. A library scan can therefore look much more reachable than an application scan that uses a small slice of the same code.
How a wrong set skews the answer
| Mistake | Effect |
|---|---|
| Missing a framework registered handler | Real paths look unreachable |
| Counting test code as an entry point | Paths exist that never run in production |
| Treating every export as an entry point for an app | Too many reachable results |
| Ignoring a plugin entry | Plugin code and its dependencies look dead |
The Go vulnerability checker's documentation is a good model of transparency here: it explains what it does and does not see, including reflection and unsafe. Ask any tool for the same clarity about entry points.
How to check what your tool assumes
- Ask the tool or its documentation how entry points are found.
- Pick one endpoint you know is live and confirm its code appears in a reported path or at least in the analyzed set.
- Pick one dead function and confirm it is not an entry point.
- Review any framework your service depends on for hidden wiring.
Exposure is a second question
A path from an internal job is reachable but may not be exposed to outside input. Label entry points by who can trigger them: the internet, authenticated users, internal systems, or nobody outside the team. That labeling turns reachability into exposure, which is closer to risk.
For the basic concept, see what is a call graph.
A short example
A team scans a service and a dependency flaw comes back unreachable. Later they realize their message consumer is registered through a framework annotation, and the scan never treated it as an entry point. After declaring it, the same flaw shows a real path through a deserializer. The code and the dependency had not changed. Only the starting set had. Check entry points before you trust a quiet report.
Quick check
Should test files be entry points?
Usually not for production risk. Treat paths that start only in tests as lower priority, but keep them in view for CI exposure.
Why do libraries look more reachable?
Their public functions are all possible entry points because callers are unknown.
Safeguard's reachability analysis is part of its dependency scanning. A free scan shows how paths are reported.
Sources
Last reviewed: 19 October 2026.
