Prioritising 34 Critical Findings and a Dismissed Egress Alert

Score by exploitability and exposure, with severity as a weight rather than the ranking.

Inputs worth combining: CVSS or vendor severity as a base; exploit maturity and EPSS-style probability of exploitation; whether a public exploit exists; internet exposure of the running workload; reachability of the vulnerable code path; business criticality and data sensitivity of the service; and existing compensating controls. The output is a risk tier that drives the sprint queue, with the raw scores kept for auditability.

Applied to the three findings: the API gateway CVE goes first. It is internet-facing, a working exploit is published, and it is three days old, which is the highest realistic combination of exposure and exploitability regardless of comparative CVSS. The two batch-job Criticals drop below it: no external input and no outbound access remove most exploitation paths, so they can wait behind documented acceptance of risk with a compensating control such as network policy and runtime monitoring. The gateway also justifies emergency handling outside the 15-per-sprint cadence, because a published exploit against an internet-facing component is measured in days.

The important habit is that the batch-job library no longer occupies the top slot purely because a scanner labelled it Critical; a queue ordered by CVSS alone will always under-serve the finding that is actually being exploited.

Map findings onto live entities, then look for evidence of use.

Attach the image digest, package name and finding identifier as tags to the deployed entities so a scanner row becomes a query against running workloads. From there, three evidence streams matter:

• Reachability: distributed traces and method-level instrumentation show whether the vulnerable library's code path is exercised in production. A library present on the classpath but never invoked is a different risk from one on the request path.
• Exposure: network telemetry and service topology show which entities accept inbound traffic from outside and which make outbound connections. The batch job's absence of external input and egress becomes a measured fact rather than a claim in a ticket.
• Runtime evidence: JVM attributes, process arguments, container image metadata and any runtime security signals confirm what is actually loaded at run time, which may differ from what the scan of the image suggests.

With that, the 2,100 findings collapse into a much smaller set of live, reachable, exposed findings. Record the query and its timestamp for each exception so that accepting risk on the batch-job library is a documented, revisitable decision rather than an assumption.

Create a defined handoff rather than a mute.

The alert is doing its job: an unexpected egress pattern from a payment service is exactly the kind of signal security needs, and dismissing it twice without a record is the failure. Two structural fixes are needed.

First, the alert needs an owner and a path. Route it to a queue that security reviews, or create a rule that any dismissal of a security-relevant anomaly requires a written justification and a review. Do not add it to a mute list; a mute on an egress anomaly removes the only detector watching for data movement from a payment path.

Second, reduce the legitimate noise so dismissals are rare. Baseline egress volume and destination sets per service, allowlist known destinations, and alert on novelty or deviation rather than raw volume. That converts a noisy alert into a specific claim: this service contacted a destination it has never contacted before.

Finally, correlate the alert with vulnerability data. If the payment service carries an unremediated finding, the anomaly and the finding should be visible side by side in the risk view, which is precisely the value of putting security findings and APM telemetry on one platform.