Getting Data Into Vulnerability Response

This is the single largest domain. It is about how external scanner and feed data lands in the platform, becomes meaningful records, and is matched to the right configuration items.

Core record types

Three record types form the spine of VR. Keeping them straight is the most testable single concept in this domain:

• Vulnerability (Vulnerability Entry): the abstract definition of a weakness — for example a specific CVE. These live in the Third-Party Vulnerability Entries table (third-party entries are scanner-vendor-defined, such as a Qualys QID) and the National Vulnerability Database (NVD) Entries table (the authoritative CVE library). A vulnerability is not tied to any one host; it is the catalog definition.
• Vulnerable Item (VI): the intersection of one vulnerability with one configuration item (CI). A VI is "CVE-X is present on Server-Y." This is the unit of remediation work. Every VI created by an integration is the join of a detection (what the scanner reported) and a CI (what it maps to in CMDB).
• Remediation Task (historically "Vulnerability Group"): a grouping of many vulnerable items so they can be triaged, assigned, and worked in bulk rather than one VI at a time. Grouping is driven by rules (see Domain 3), not manual effort, although manual addition is possible.

A useful mental model: a vulnerability is a kind of problem; a vulnerable item is an instance of that problem on a specific asset; a remediation task is a batch of instances handled together.

Scanner integrations: Qualys, Tenable, Rapid7

VR ingests detection data from third-party scanners through dedicated integration applications installed from the ServiceNow Store and configured (in current releases) through the Setup Assistant. The three you must know cold:

• Qualys Vulnerability Integration — pulls QIDs and host detections from the Qualys Cloud Platform. Qualys vulnerabilities are identified by QID; these become third-party vulnerability entries.
• Tenable Vulnerability Integration — supports Tenable.io (cloud), Tenable.sc (on-prem), and Tenable.cs (container/cloud security). Each Tenable product has its own connector flavor and supported-records list.
• Rapid7 Vulnerability Integration — supports both the InsightVM cloud API and the Rapid7 data warehouse path.

All three rely on IntegrationHub / REST messages to call the vendor API, an import/transform layer to land raw data, and scheduled integration runs that you can monitor through integration-run (VINTRUN) records and run-status dashboards. You can also trigger a manual import and, for several scanners, initiate a rescan from within ServiceNow.

Key shared behaviors to remember:

• Each integration creates vulnerable item detections — the per-scan evidence records — which roll up into vulnerable items.
• The vulnerable item key controls deduplication: it defines what combination of fields makes two detections "the same" VI. You can configure the key (and, for Rapid7, add "proof" to it).
• Detections from multiple scanners can be correlated/deduplicated so the same real-world weakness on the same host is not counted twice.
• Imports can be domain-separated for MSP/multi-tenant deployments; a user in the target domain runs the integration.

NVD and other enrichment feeds

• NVD (NIST National Vulnerability Database) integration imports the authoritative CVE library and CWE (Common Weakness Enumeration) records on a scheduled job. NVD entries provide CVSS base scores and descriptions that enrich the scanner-supplied third-party entries. Scanner QIDs are linked to CVEs so that one NVD entry can relate to many third-party entries.
• CWE records categorize weakness types; a scheduled job keeps them current.
• Exploit enrichment feeds raise the real-world urgency of a vulnerability beyond its static CVSS score:
  • CISA KEV (Known Exploited Vulnerabilities) integration flags CVEs that CISA confirms are being actively exploited in the wild — a strong signal to prioritize.
  • EPSS (Exploit Prediction Scoring System) integration adds a probability that a CVE will be exploited; EPSS score can be wired into the risk calculator business rule.
  • Shodan Exploit integration correlates exploit availability/exposure data.
• You can add CVEs to third-party entries manually so that vendor entries lacking a CVE mapping become enriched.

CMDB matching: CI lookup rules, reconciliation, and unmatched CIs

When a detection arrives, VR must decide which CI it belongs to. This is where exam questions concentrate inside this domain.

• CI Lookup Rules (a SecOps-common construct) define, in priority order, how an incoming detection's host identifiers (IP, DNS name, MAC, NetBIOS, hostname, cloud instance ID, etc.) are matched to an existing CI in the CMDB. Rules run in sequence; the first match wins.
• Detections that match become vulnerable items tied to the right CI. Detections that do not match any CI are held as Unmatched CIs / Discovered Items rather than silently dropped. An analyst can view, reclassify, and reconcile these.
• VR can create CIs for genuinely new assets using the Identification and Reconciliation Engine (IRE) — the same CMDB engine that enforces identifier rules and reconciliation rules so duplicate CIs are not created and the authoritative data source wins on each attribute.
• Housekeeping options: ignore CI classes, filter decommissioned CIs, auto-promote CIs, reapply CI lookup rules on selected discovered items, and de-duplicate existing CIs. Knowing that lookup rules can be reapplied (not just applied once at import) is a common test point.
• Unclassed hardware can be reclassified into the proper CMDB class.

Manual ingestion

Beyond automated integrations, VR supports manual ingestion of vulnerabilities (via a provided template), manual creation of vulnerable items, and the generic framework to define a brand-new custom vulnerability integration (single-call vs. multiple-call patterns, report processor strategies, integration factory scripts).