Getting Data Into Vulnerability Response
About 29% of the CIS-VR exam — see all 5 domains.
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).
- By default a vulnerable item is unique per CI, vulnerability and integration instance, so two scanners that report the same CVE on the same host create two VIs. Show Duplicate VIs identifies them and Resolve duplicate VIs (on demand or automated) closes the duplicate.
- 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.
- Matching starts with a vendor ID lookup in Discovered Items, then the CI lookup rules run in Order and stop at the first rule that returns a single CI (if a rule returns several, the first is used). Hosts that no rule matches are flagged Unmatched in Discovered Items rather than dropped; an analyst can view, reclassify and reconcile them.
- Only when no lookup rule matches is the host sent to the Identification and Reconciliation Engine (IRE), which creates a CI (for example Unclassed Hardware or Incomplete IP Identified Device) without duplicating existing CIs; without the CMDB CI Class Models plugin a placeholder Unmatched CI is used. IRE does not do the matching itself; the VR CI lookup rules do.
- 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).
Sample questions from this domain
Three of the 80 in this domain, with the reasoning. The full set is in the question bank.
Which component is required to allow ServiceNow Vulnerability Response to communicate with an on-premises scanner such as Tenable.sc or a Rapid7 data warehouse?
- A. An import set
- B. A data source
- C. A MID Server ✓
- D. A Flow action
Why: A MID Server runs inside the customer network and gives the cloud instance a secure channel to on-premises scanners: the Rapid7 data warehouse integration requires one, and Tenable.sc uses one when the instance and the scanner are not in the same location. Cloud scanners such as the Qualys Cloud Platform or Tenable.io are reached directly over their APIs. An import set and a data source only stage and describe incoming data once a connection exists, and a Flow action runs logic on the instance; none of them opens a path into the internal network.
Which authoritative U.S. government source is commonly used to enrich vulnerability definitions with CVSS scores and CVE descriptions in Vulnerability Response?
- A. Common Weakness Enumeration (CWE)
- B. National Vulnerability Database (NVD) ✓
- C. CISA Known Exploited Vulnerabilities
- D. The Third-party library (QIDs)
Why: The National Vulnerability Database (NVD) is the U.S. government source that supplies CVE descriptions and CVSS scoring used to enrich vulnerability definitions in Vulnerability Response. The CWE library describes weakness types and is reference only, the CISA Known Exploited Vulnerabilities catalog flags CVEs that are exploited in the wild rather than supplying CVSS scores, and the Third-party library holds scanner-defined entries such as Qualys QIDs, which reference CVEs rather than being the government source.
During a scanner integration, host findings must be matched to existing configuration items. Which process is responsible for this matching to avoid duplicate CIs?
- A. Vulnerability Response CI lookup rules, with IRE creating a CI only when no rule matches ✓
- B. Discovered Items reclassification, performed by an analyst after each scanner import completes
- C. Remediation task rules, which group each scanned host's findings under the matching CI
- D. The vulnerable item key, which merges host records that share an IP address into one CI
Why: Vulnerability Response first looks up the scanner's host ID in Discovered Items, then runs its CI lookup rules in order (FQDN, NetBIOS, IP and so on) and stops at the first rule that returns a single CI. Only when no rule matches is the host sent to IRE, which creates a CI without duplicating existing records. Reclassifying Discovered Items is a manual follow-up for hosts that were already matched or unmatched, remediation task rules group Vulnerable Items after matching, and the vulnerable item key decides VI uniqueness rather than merging host records into CIs.