Reachability: container-image runtime reachability (research)

[bomly-guy]

Goal

Research and prototype reachability for container-image scans, where the input is an OS image (apk / dpkg / rpm packages) rather than a source tree.

Why this is different from the source-based analyzers

The existing analyzers (govulncheck, jsreach, pyreach, jvmreach) walk application source and answer "does the app import this package?". For container images, there is no app source — only installed binaries. The equivalent question is "does anything in the image's startup / entry point actually load this binary at runtime?".

Possible approaches

1. ldd / dynamic-loader trace from the image's CMD / ENTRYPOINT: identify which .so / .dll files are loaded at process start. Reachable OS packages are those that provide a loaded library.
2. Static binary analysis of the entry-point binary: dump dynamic-section NEEDED entries from ELF / PE headers; resolve to OS packages via the package manager's dpkg -S / rpm -qf / apk info -W lookup.
3. eBPF runtime trace at boot: run the container briefly, capture execve and dlopen events, map back to packages. Out of scope for a static scanner but worth noting as the upper bound.

Approach #2 is the most attractive starting point: deterministic, no container execution required, no runtime trace.

Scope (research only)

This issue is exploratory. Concrete deliverables:

• A short doc in docs/REACHABILITY.md (new section) explaining why container reachability is a separate problem from source-tree reachability.
• A spike implementation that, given a Syft-resolved container SBOM and the image's entry-point ELF, lists the OS packages directly loaded at process start.
• Decision: whether to add a containerreach analyzer to the registry, or treat this as a separate feature behind a different flag.

References

• Detector: internal/detectors/syft already resolves container packages.
• The existing analyzers all run after matchers, so a container-aware analyzer would slot into the same pipeline stage.