ServiceNow Vulnerable Item Explained

What is a Vulnerable Item?

A vulnerable item is a software installation on a device that is known to be affected by a documented security vulnerability. ServiceNow detects vulnerable items by comparing your installed software inventory against public and private vulnerability databases (like CVE databases from NIST NVD, vendor security bulletins, or threat intelligence feeds). When a vulnerable software version is found on any device, ServiceNow creates a Vulnerable Item record linking the software installation, the specific vulnerability, the affected device, and the remediation status. This enables security teams to track remediation (patch, upgrade, or retire the affected software) across the entire organization systematically.

How Vulnerable Items Work on the Platform

Vulnerability data comes from external sources (NIST National Vulnerability Database, vendor advisories like Microsoft Security Bulletins, third-party threat feeds) and is imported into ServiceNow’s vulnerability database. ServiceNow then compares your software installation records against known vulnerabilities: if you have a widely-used application installed on 12 devices and a known vulnerability is published as affecting that version, ServiceNow automatically creates 12 Vulnerable Item records (one per affected device). You can then track remediation for each device: which devices are patched, which are retired, which have compensating controls in place? The Vulnerable Item record links the vulnerability to a remediation ticket (incident or change request) so work is tracked and actionable.

Where Vulnerable Items Live

Vulnerable Items are part of the ITAM (IT Asset Management) or Vulnerability Management modules. Each Vulnerable Item record stores: the CVE (Common Vulnerabilities and Exposures) ID, CVSS (Common Vulnerability Scoring System) severity score, affected software installation record, affected device record, and remediation status (Open, In Progress, Patched, Retired, Accepted Risk). Vulnerability records store the vulnerability details (description, published date, affected versions, reference links). Software Installation records show which devices are vulnerable. Remediation can be tracked via related Incident or Change records linked to the Vulnerable Item, creating an audit trail of when and how the issue was resolved.

Worked Example: Critical Vulnerability Response

A critical vulnerability is announced for a widely-used database library (e.g., Log4Shell affecting Java applications). Discovery finds 47 installations of the vulnerable version across your organization on production servers, development servers, and workstations. ServiceNow automatically creates 47 Vulnerable Item records all flagged as Critical severity. The security team creates a remediation incident and assigns it to the infrastructure team for patching. As servers are patched to a non-vulnerable version, the team updates each Vulnerable Item record with the patch date and new software version. The vulnerability detection system scans again and confirms the patch was successful. Once all 47 Vulnerable Items are resolved and verified patched, the incident is closed and compliance for that vulnerability is confirmed.

Common Misunderstandings

Many organizations confuse vulnerabilities with security incidents. A vulnerability is a weakness or defect in software code; an incident is when that weakness is actively exploited or causing damage. Detecting a vulnerable item is preventive security work; you aim to patch before attackers can exploit the vulnerability. If an attacker successfully exploits the vulnerability, then you have a security incident and incident response procedures activate. Vulnerable items are upstream of incidents in the security lifecycle.

Another misconception: that all vulnerable items require immediate patching. This is true for Critical and High severity vulnerabilities, but Medium and Low vulnerabilities might have other acceptable mitigations: running on a segmented network isolated from the internet, disabling the vulnerable feature, or accepting the risk with compensating controls and management approval. Document your risk acceptance decisions in the Vulnerable Item record for audit trails and future reference.

Some assume vulnerability databases are complete and real-time. They lag behind actual threats. New vulnerabilities might not appear in ServiceNow’s imported database for days or weeks after public disclosure. Subscribe to vendor security advisories (e.g., Microsoft Security Updates, Adobe Security Bulletins) and manually import critical vulnerabilities if your automated import is delayed.

Related Concepts

Software Installations show what software is deployed on each device. Vulnerabilities are weaknesses in software code. CVE (Common Vulnerabilities and Exposures) is the international standard identifier for public vulnerabilities. CVSS (Common Vulnerability Scoring System) rates severity from 0 to 10. Remediation workflows convert vulnerable items into actionable tickets. Compliance reports track remediation progress and SLA compliance.

Managing Vulnerable Items

Create a workflow: detect vulnerable items automatically via scheduled scans, assess severity and business impact, prioritize by criticality and asset importance, create remediation tickets, track progress, verify remediation (re-scan to confirm patching), and close the item. Set a remediation target for each severity level, with Critical vulnerabilities first. Low vulnerabilities can be batch patched during scheduled maintenance windows. Document your SLA for each severity level in your vulnerability policy and track compliance to those commitments.

Triage order when the list is longer than the team can work

A scan that returns many vulnerable items on the same day creates a sorting problem before it creates a patching problem. The vulnerability manager needs to decide which items are worked now, which are scheduled, which are fixed by removing the software, and which are accepted with a control in place. The mistake to avoid is sorting by severity score alone. A high score on an isolated lab machine can matter less than a medium score on an internet-facing host that holds customer data. Severity is one input. Exposure, the business service the device supports and whether an exploit is known in the wild should decide the queue order, and each decision should be written onto the item so the next person can see why it went where it did.

Stopping one vulnerability from being tracked twice

Duplicates are the quiet cost of running more than one detection path. A vulnerability may be imported from a public database and again from a vendor bulletin, and a host may appear under two configuration item records after a rename or a re-image. The result is a count that looks larger than the real exposure and a team that closes one record while its twin stays open. Agree on the primary source for each vulnerability and on the identity of each host before the first large scan. Where a host has two records, decide which one the discovery process treats as authoritative, and merge or retire the other rather than leaving both to diverge.

Closing an item only when the evidence says so

An item should close because the software is no longer present or no longer at a vulnerable version, not because someone wrote that the patch was applied. The ticket text is a claim; the discovery record is the evidence. A closure procedure that holds up under audit is short and mechanical.

1. Confirm the installed version on the software installation record, from a discovery run made after the change.
2. Check that the vulnerability no longer matches that version, or that the installation has been removed.
3. Record the closing reason as patched, retired, not applicable, or accepted, with the reference that proves it.
4. Reopen the item automatically if a later discovery run shows the same software at a vulnerable version, because reinstalls and restored images are common.

When the count will not fall after patching

Teams that patch steadily and still see the open count stay flat often have a data problem rather than a patching problem. The inventory may not have refreshed since the change, so the platform still sees the old version. A second copy of the software may exist inside a virtual machine template, a container image or a user profile that the discovery schedule never reaches. Renamed packages can escape the match rules, and a device whose name changed may be linked to a record that no longer represents it. Work through the inventory first, then the scan schedule, then the matching rules, before assuming that the remediation work has failed.

Risk acceptance that survives an audit

Accepting a vulnerability is a decision, and it needs the same record as any other decision. The record should name the approver, describe the compensating control in terms someone can check, state why patching is not possible now, and set an expiry date. Acceptance without an expiry tends to become permanent, which is the exact situation auditors look for. Tie each acceptance to a review trigger as well, such as a vendor fix becoming available or the host being upgraded, so the decision is revisited when the facts change.

Should remediation be tracked per device or per application?

Track the device, because the exposure lives there, and report the application view for owners of software. Reporting only by application hides the hosts that were missed. Reporting only by device makes it hard to see that one vendor release is responsible for most of the backlog.

What if the vendor disputes that a version is affected?

Record the disagreement on the item, keep the installed version evidence, and check whether the vendor’s affected-version statement matches the build you actually run. Where it does not, the acceptance decision should cite the dispute and the compensating control until it is resolved.

How should end-of-life software with no advisory be handled?

It does not appear as a vulnerable item until someone publishes a finding, so it needs its own tracking. Keep a short register of unsupported software in use, with an owner, a replacement date and an exception record for anything that must remain running.

Do exceptions need their own table?

Many teams keep them on the item itself, which is simpler to audit. A separate exception register helps when one decision covers many items, such as a single accepted control for a fleet of hosts. Either way, the link between the exception and each affected item must be explicit.

Looking at duplicate handling and closure evidence first can show quickly why the backlog looks larger than the real exposure. For the wider service view, see the vulnerability exposure response page, and the vulnerability ownership post covers the ownership side in more depth.