Notifications
Clear all
Topic starter
22/07/2026 4:35 pm
TL;DR: Aqua’s ServiceNow integration correlates code-level vulnerability data with what is actually running in production, so Vulnerability Response can prioritise exploitable container risk instead of raw CVE volume, according to Aqua Security. The governance shift is away from severity-led backlog management and toward runtime-informed exposure control.
NHIMG editorial — based on content published by Aqua Security: Integrate Aqua and ServiceNow to Prioritize Vulnerabilities by Runtime Reality
Questions worth separating out
Q: How should security teams prioritise container vulnerabilities in production environments?
A: Prioritise vulnerabilities by whether they are present in a running, reachable workload and whether exploitation is plausible now.
Q: Why do severity-only vulnerability queues create remediation debt?
A: Severity-only queues ignore deployment state, so teams waste time on issues that exist only in unused images while live exposures wait.
Q: What do organisations get wrong about container security?
A: Organisations often treat container security as a runtime hardening problem when the larger issue is lifecycle governance.
Practitioner guidance
- Prioritise only live workload exposures Configure vulnerability workflows to separate findings in running production workloads from findings that exist only in images, registries, or unused layers.
- Add exploitability signals to triage rules Combine CVE severity with exploit availability, vendor fix status, and workload reachability before a ticket is escalated.
- Carry runtime context into ServiceNow records Ensure ticket fields preserve image identity, workload instance, and whether the vulnerability is tied to a deployed service.
What's in the full article
Aqua Security's full post covers the operational detail this post intentionally leaves for the source:
- Exact ServiceNow configuration steps for the Aqua Security app, including the connection fields and scheduling options.
- The three ServiceNow record types that receive Aqua data, with the specific fields populated in each one.
- Filter logic for deciding which vulnerabilities enter Vulnerability Response, including the running workload setting and severity thresholds.
- Auto-close behaviour that keeps ServiceNow aligned with Aqua's current findings as remediation progresses.
👉 Read Aqua Security's integration guide for runtime-prioritised container vulnerability response →
Container vulnerability triage: what runtime reality changes for teams?
Explore further
22/07/2026 4:40 pm
Runtime exposure is the real prioritisation boundary: vulnerability management fails when teams rank findings by severity without asking whether the asset is live, reachable, and relevant to production. Containers intensify that problem because image sprawl creates large volumes of findings that never translate into exploitable risk. The governance issue is not lack of scanning, but lack of exposure context. Practitioners should treat runtime state as the deciding factor for remediation order.
A question worth separating out:
Q: Which governance control matters most when integrating vulnerability data into ITSM workflows?
A: The key control is preserving exposure context all the way through triage, assignment, and closure. If the ticketing workflow strips out runtime details, the organisation loses the reason a vulnerability was prioritised in the first place. That weakens accountability and makes audit trails harder to defend.
👉 Read our full editorial: Runtime reality beats CVE severity in container vulnerability triage
