The Vulnerability Response lifecycle has six distinct stages. Knowing each one and the tables involved separates senior candidates from the rest.

A scanner (Qualys, Tenable, Rapid7) runs a scan and exports results. A ServiceNow connector or IntegrationHub action pulls that data into an Import Set on the ServiceNow instance.

A Transform Map processes each import row. It creates or updates records on the sn_vul_vulnerable_item table (Vulnerable Items) and links each VI to the matching vulnerability definition on sn_vul_vulnerability.

Each VI must be linked to a CMDB CI. The matching engine compares scanner asset identifiers (IP, hostname, FQDN) against CMDB records. Matched VIs gain CI context; unmatched VIs are flagged for review.

Risk scores are calculated per VI using CVSS, CI criticality, and threat intelligence. Calculator Groups apply the weighting formula. Remediation Task Rules then assign VIs into Remediation Tasks for remediation management.

Assignment Rules route each Remediation Task to the correct support group. Remediation Tasks and, where required, Change Requests are created. Teams remediate the underlying issue.

The scanner re-scans the asset. If the vulnerability is no longer present in scan data, the VI enters a grace period. After the grace period, the VI closes as "Not Vulnerable". Exceptions can close VIs early with approval.

A Vulnerability is the definition of a security weakness - what the flaw is. Records live on sn_vul_vulnerability. Most come from the National Vulnerability Database (NVD) and carry a CVE ID, CVSS score, description, and affected software version. This record is the catalog entry; it has no CI context.

A Vulnerable Item is an instance of a vulnerability on a specific CI. Records live on sn_vul_vulnerable_item. Each VI links a Vulnerability to a CI, carries a state, a risk score, a due date, and a scanner source. If CVE-2024-1234 affects 200 servers, there are 200 Vulnerable Items - one per affected CI.

A Remediation Task aggregates related VIs for operational remediation management. Records live on sn_vul_vulnerability_group. A Remediation Task is where SLAs, team assignments, and progress tracking live. Instead of handling 200 individual VIs, a team handles one Remediation Task that represents all 200.

Vulnerable Items are created through the import process - the Transform Map that processes scanner data creates or updates VI records. They can also be created manually, though that is rare in production.

vulnerability - Reference to the CVE/vulnerability definition. Required.
cmdb_ci - The affected CI. Required for assignment and risk scoring; without it, the VI is orphaned.
state - Drives the lifecycle: Open, In Review, Pending, Exception, Closed.
risk_score - Calculated score 0-100 used for prioritization.
risk_rating - Critical, High, Medium, Low, Informational - derived from risk score.
first_found - When this vulnerability was first detected on this CI. Used for SLA calculation.
last_found - When the scanner last confirmed this vulnerability is present. Used for reassessment logic.
source - Which scanner or import job created this VI. Critical for deduplication and audit.

ServiceNow provides certified connectors for major scanners. The general data flow is the same across all of them; the connector handles the scanner-specific API format.

The connector (or a custom IntegrationHub flow) authenticates to the scanner's API and retrieves scan results - either a full export or a delta since the last run. The raw scanner data is loaded into an Import Set. A Transform Map processes each row: it resolves the CVE to a Vulnerability record, matches the asset to a CMDB CI, and creates or updates the Vulnerable Item.

For on-premises scanners that are not publicly accessible, a MID Server handles the outbound connection from within the network to reach the scanner's local API or shared file location. Cloud-hosted scanners (Qualys Cloud, Tenable.io) can be reached directly via IntegrationHub without a MID Server.

Most production setups run scheduled import jobs - typically daily or after each planned scan cycle. On-demand imports can be triggered manually for urgent scans or as part of a post-deployment verification workflow.

The CMDB is the asset registry that Vulnerability Response depends on for everything downstream of import. Without CI matching, a VI is just a floating vulnerability report with no owner, no risk context, and no routing.

Ownership and assignment: the CI's support group and assigned_to fields feed Assignment Rules, so VIs reach the right team automatically.
Business criticality: the CI's criticality field feeds the risk calculator, so the same CVE scores higher on a production payment server than on a dev workstation.
Service dependency: CI relationships show which business services depend on the affected CI, influencing prioritization and blast radius assessment.
Environment context: production vs. non-production classification affects SLA targets.

Unmatched VIs have no support group assignment, no risk score context from CI criticality, and cannot be grouped by business service. In large deployments, a 40% match rate means 60% of vulnerabilities are invisible to the teams responsible for them.

The Risk Score is not just the CVSS score - it is a composite score calculated by a Calculator Group that weights multiple inputs. The output is a 0-100 score, which maps to a Risk Rating (Critical, High, Medium, Low, Informational).

CVSS Base Score - the raw vulnerability severity from NVD or the scanner. This is the largest single contributor.
CVSS Temporal Score - modifies the base score based on exploit availability and patch maturity.
CI Business Criticality - the criticality classification of the affected CI from CMDB (Mission Critical, High, Medium, Low).
Asset Exposure - whether the CI is internet-facing or internal-only.

Inside the Calculator Group, each factor is a Calculator Rule with a condition and a score contribution. Rules are evaluated against the VI, and the total of matching rule scores determines the final risk score. This design allows organizations to add custom factors - internal threat intel feeds, compliance scope flags, or asset lifecycle state.

A Remediation Task (RT) is a logical container that aggregates related Vulnerable Items to make remediation manageable at scale. Without groups, a team responsible for patching 10,000 VIs would need to manage 10,000 individual records.

Single assignment: one Remediation Task can be assigned to one support group, regardless of how many VIs it contains.
Task-level SLA: the RT carries one due date, one SLA record, and one state - much easier to track than thousands of individual SLAs.
Clear ownership: the Remediation Task represents the work, with no need to create individual records per VI unless sub-team tracking is needed.
Progress visibility: closing one Remediation Task closes all its member VIs, giving clean reporting metrics.

By CVE: all instances of the same CVE across all CIs form one group (the default approach).
By support group: all VIs owned by the Windows team form one group.
By business service: all VIs affecting the Payment Service form one group.
By CI class: all VIs on network devices form one group.

The Remediation Task Rules engine evaluates each new or updated VI against a set of configured conditions and assigns the VI to the first matching Remediation Task - or creates a new one if no matching Remediation Task exists.

Rules are evaluated in priority order. Each rule defines match conditions using VI attributes or CI attributes - for example: "vulnerability.cvss_score >= 7.0 AND cmdb_ci.support_group = Windows Team". The first rule whose conditions all match wins, and the VI is placed into that group.

If no existing Remediation Task of the right type exists for the matched criteria, a new Remediation Task is created automatically. For CVE-based grouping, one Remediation Task per CVE is created on first match; subsequent VIs for the same CVE are added to the existing Remediation Task.

VIs that do not match any Remediation Task Rule can be directed to a default "catch-all" group or left ungrouped for manual assignment. Ungrouped VIs are visible on the VR Overview dashboard and represent a configuration gap.

Remediation Task creation in VR follows two paths: automatic via the Remediation Task Rules engine during import, and manual by a security analyst from the VI or RT list.

When VIs are created or updated, the Remediation Task Rules engine evaluates conditions and places each VI into the appropriate Remediation Task. If no matching RT exists yet, one is created automatically. The RT carries the SLA, due date, and state for all its member VIs.

Assignment Rules evaluate RT (or VI) attributes and set the assignment group. Conditions can reference: CI support group, CI class, vulnerability category, business service, or risk rating. When conditions match, the RT is routed to the specified team and a notification can be triggered automatically.

For remediations that require a formal change (production server patching, firewall rule changes), a Change Request is raised from the Remediation Task. CAB approval follows the standard Change Management workflow. Once the Change Request closes as successful, the VI is updated accordingly.

Entries sourced from the National Vulnerability Database carry a standardized CVE identifier (e.g., CVE-2024-12345), a CVSS v3 base score, a description, and affected product version ranges. ServiceNow's NVD feed keeps these synchronized on a regular schedule. The source field on the vulnerability record is set to NVD.

Some scanner vendors publish proprietary vulnerability identifiers for weaknesses that are not yet assigned a CVE, or for configuration-level findings that NVD does not cover. These land in ServiceNow as third-party vulnerability entries with a scanner-specific ID. They may have a custom CVSS score set by the vendor rather than NVD.

Most organizations manage both. NVD entries are the majority and have well-established CVSS scores. Third-party entries require review to ensure their scoring is accurate before they influence risk ratings. Some organizations apply a manual review gate for third-party entries before they reach the remediation workflow.

Vulnerability Exceptions allow a VI to be formally deferred or risk-accepted without remediation, with documented justification and an expiry date. They are not the same as ignoring a vulnerability - every exception is tracked, approved, and time-bound.

Risk Accepted - Business accepts the risk as-is. Typically for low-risk VIs on non-critical assets.
Compensating Control - A mitigating control exists that reduces the actual risk (e.g., WAF rule blocks the attack vector).
Vendor Dependency - No patch available; vendor has not yet released a fix.
False Positive - Scanner reported a vulnerability that does not actually exist on this CI.

An analyst sets the VI state to "Exception Requested" and selects the exception type and justification. The exception request routes to an approver (typically a security manager or risk owner). On approval, a Vulnerability Exception record is created with an expiry date. The VI state moves to "Exception". On expiry, the VI automatically re-opens unless the exception is renewed.

The initial state when a VI is created by import. The vulnerability exists on the CI and has not been addressed.

The assigned team has acknowledged the VI and remediation work has started. Triggered manually or by a Business Rule when a Remediation Task is created.

Remediation is complete but the fix has not been confirmed by a rescan yet. Or the VI is awaiting a Change window.

An approved exception exists. Triggered by the exception approval workflow. VI is not actively being remediated - risk has been accepted or deferred.

The scanner confirmed the vulnerability no longer exists on the CI. Triggered by the reassessment job after a successful rescan shows no finding.

Manually closed by an analyst after confirming remediation. Used when a rescan is not available or the scanner does not confirm closures automatically.

CVSS (Common Vulnerability Scoring System) is the industry-standard scoring framework published by NVD. It rates a vulnerability's inherent technical severity on a 0-10 scale, independent of the environment it appears in.

CVSS Base Score and Temporal Score are stored on the sn_vul_vulnerability record. When a VI is created, the parent vulnerability's CVSS score is one of the inputs to the risk calculator.

CVSS measures the vulnerability itself - it does not know whether the affected CI is a production database or a test workstation. ServiceNow's Risk Score measures the risk of this specific VI on this specific CI. The same CVE-2024-5678 with a CVSS of 9.1 may produce a ServiceNow Risk Score of 95 on a critical payment server and 42 on an isolated dev server.

ServiceNow supports CVSS v2 and v3 scores. Most modern implementations use v3.1. Older vulnerability records may carry v2 scores. When both exist, the Calculator Group typically uses v3 as the primary input.

Open VI count by risk rating, trend over time (new vs. closed vs. aging), top CVEs by affected asset count, and total exposure summary. The primary operational dashboard for the security team.

VIs and RTs that are overdue, aging past their SLA, or not yet assigned. Used by security managers to escalate with support group leads.

Compares assets present in CMDB against assets covered by scanner imports. Highlights gaps - CIs in CMDB that have never been scanned. Critical for ensuring the program actually covers the full attack surface.

Active exceptions by type, expiry date distribution, and upcoming renewals. Used for compliance reviews to show all risk acceptances are documented and time-limited.

Aggregates VI risk scores to the business service level using CI relationships. Lets executives see which services carry the highest cumulative vulnerability risk without needing to understand individual CVEs.

Vulnerability reassessment is the mechanism that prevents premature VI closure due to partial or incomplete scans. It is one of the more nuanced areas of VR configuration.

Scanners do not always scan every IP in every run. A scanner that covers 10,000 assets may only scan 8,000 in a given run due to timeouts, network issues, or schedule configuration. Without a grace period, a VI for the other 2,000 assets would close incorrectly after the first run where they are absent.

When a VI was open and is absent from the latest scan data, its last_found date is not updated. A reassessment job compares the current date against last_found. If the gap exceeds the configured grace period (default is typically 7-14 days), the VI is eligible for auto-closure as "Not Vulnerable".

A scheduled job (sn_vul_reassessment) runs after each scanner import. It evaluates all open VIs for the relevant scanner source against the grace period threshold and closes eligible VIs.