Connecting Vulnerability Findings to Runtime Context

Why severity alone misleads

Base severity scores are computed without knowledge of your environment. The same library flaw can be irrelevant in an offline batch job and urgent in an internet-facing payments service.

Treat severity as one input. The questions that change priority are: is it deployed, is it reachable, and what can the process it runs in access?

Tracing code to runtime

Link each finding to the artifact it lives in (manifest, lockfile, image), then to the workload running that artifact, then to the environment and exposure of that workload.

Image digests and deployment metadata are the most reliable join keys. Repository names and tags drift; digests do not.

Evidence of exploitability

Useful signals include whether the vulnerable function is called, whether input reaches it from an exposed route, and whether public exploit code exists. Record each as evidence with its source, rather than folding everything into a single score.

When evidence is missing, say so. 'Reachability not established' is a valid and honest state that tells a reviewer exactly what to check.

A practical sequence

1) Filter to deployed artifacts. 2) Group by workload. 3) Annotate with exposure and identity. 4) Rank by the sensitivity of what the workload can reach. 5) Hand engineers the finding with that context attached.