- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
3 hours ago - edited 3 hours ago
Your vulnerability management program tracks CVEs. Your scanners find them, your analysts prioritise them, your remediation owners patch them. But what about the misconfiguration that made three of those CVEs exploitable in the first place?
An overly permissive sudo policy. A default TLS setting nobody revisited. A storage bucket left open since migration. These aren’t missing patches — they’re configuration gaps, and they shift every time someone changes a setting. Without Configuration Compliance (CC), tracking them means a separate tool, a separate workflow, and a separate prioritisation model that lives outside your remediation engine.
If you’re already running Vulnerability Response (VR) inside the Unified Security Exposure Management (USEM) workspace, you’ve done most of the heavy lifting. Here’s why.
The operational backbone already exists
Think about what you’ve built for VR: assignment rules that route Vulnerable Items (VITs) to the right remediation owners. Exception rules that filter out accepted risk. Grouping rules that consolidate scanner noise into actionable clusters. Remediation target rules that set SLA expectations by severity. Approval chains. Notification preferences.
That’s not a small investment — it’s months of tuning to match how your organisation actually works.
CC uses the same rule framework. Test Results (TRs) — the CC equivalent of VITs — flow through the same assignment logic, the same exception workflows, the same grouping engine, and the same remediation target structure. You don’t rebuild from scratch. You extend what’s already there.
What “extend” looks like in practice
When you enable CC alongside VR in USEM, your existing rules don’t automatically apply to TRs — but replicating them is straightforward because the rule structure is identical.
Assignment rules. If you route critical VITs on Linux servers to your infrastructure team, you create a parallel rule that routes critical TRs on the same CI class to the same group. Same logic, same owners, new finding type.
Exception rules. If your VR exception workflow requires manager approval for deferring critical findings beyond 30 days, you apply the same approval chain to TRs. The exception model is shared.
Grouping rules. If you group VITs by business service to give remediation owners a single actionable view, you apply the same grouping to TRs. Misconfigurations on the same service land in the same queue.
Remediation target rules. If your VR SLAs define 15 days for critical findings and 30 for high, you extend those targets to include TRs. One rule update — TRs now carry the same urgency framework your team already operates under.
The point isn’t that this is zero effort. It’s that every decision you’ve already made about routing, prioritisation, exceptions, and SLAs carries directly over. You’re not starting a new conversation about who owns what.
Why this matters for your security posture
Consider CVE-2025-32463 — a critical sudo privilege escalation flaw (CVSS 9.3) that hit CISA’s Known Exploited Vulnerabilities catalog in 2025. The vulnerability allows any local user to escalate to root through sudo’s chroot option. But the exploit only works if the sudoers policy permits chroot usage — a permissive configuration many Linux environments carry by default.
VR tracks the CVE. CC tracks the configuration that determines whether the CVE is dangerous in your environment. When both are running in the same workspace, your team sees the full exposure picture — not just what’s vulnerable, but what’s misconfigured in a way that makes vulnerabilities exploitable. That changes how you prioritise, how you assign, and how you report posture to leadership.
Getting started
If you’re already on USEM with VR: Install the Configuration Compliance plugin from the ServiceNow Store, connect your scanner’s compliance data source, and start replicating your existing VR rules for TRs. Your scanner integration — whether Qualys, Tenable, or Wiz — already supports compliance data. CC gives it a place to land and a workflow to act on it.
If you’re on classic VR (not yet on USEM): Use the Migration Assistant for USEM to upgrade first. The assistant walks through VR and scanner plugin upgrades step by step. Once on USEM, CC enablement follows the same path.
Resources
Store links:
Qualys Integration for Security Operations
Vulnerability Response Integration with Tenable
Vulnerability Response Integration with Wiz
Documentation:
SecOps Resource Library — Configuration Compliance
USEM Release Highlights & Upgrade Information
USEM Migration Toolkit (Support KB)
What was your experience?
If you’ve enabled CC alongside VR, what rules did you replicate first — assignment, exception, grouping? Did your existing VR operational model translate cleanly, or did you find areas where CC needed different treatment? We’d like to hear how it went.
