Reducing Alert Fatigue with Container Scans: Correlate, Prioritize and Filter Based on Usage

The talk opens with a common scenario: an application built from twelve containers with about 400 packages, where a software composition analysis scan reports more than a hundred vulnerable components. Security teams want critical and high findings fixed, but development teams lack the capacity, and severity scores alone push effort toward issues that may never be reachable.

The speaker proposes a second generation of composition analysis that combines static scan output with runtime evidence. Six factors guide triage: runtime usage, reachability, exploit maturity, deployment topology, severity policy and applicability. A live demo on a multi-service sample banking application shows how filtering down to components that were actually loaded, then to those with known exploits, cuts a large list to a handful. In one Log4j example, only a few instances were both loaded and vulnerable. The talk also covers instrumentation options, including eBPF, user-space preloading and language agents, and notes that unused packages can be removed to shrink images and reduce debt.

The takeaway is to prioritise by demonstrated exposure rather than raw counts, give developers a short fix list, and track risk posture over time instead of vulnerability totals. Runtime data only reflects code that runs during the observation window, so the speaker recommends exercising applications through tests or canary deployments before trusting the baseline.