sn_vul_vulnerable_item Table

Table Reference/sn_vul_vulnerable_item

The sn_vul_vulnerable_item table stores vulnerability response tracking records that link CVEs to Configuration Items in the SecOps module. The critical thing to know: this table creates the many-to-many relationship between vulnerabilities and affected CIs, so one CVE can have multiple vulnerable item records.

What This Table Is

The sn_vul_vulnerable_item table stores individual vulnerability tracking records that represent the relationship between a specific CVE and an affected Configuration Item. Each record represents one "vulnerable item" - essentially answering the question "which CIs are affected by which vulnerabilities?" This table is the backbone of vulnerability response management in ServiceNow's Security Operations (SecOps) module.

The SecOps module owns this table and uses it to track vulnerability remediation from discovery through resolution. When vulnerability scanners feed data into ServiceNow, they create records in this table to establish which CIs have which security flaws. The vulnerability response process then uses these records to assign remediation work, track progress, and measure risk reduction across the infrastructure.

This table extends the task table, inheriting standard workflow fields like state, assignment_group, and assigned_to. This means you get full task management capabilities - approvals, SLAs, notifications, and workflow - applied to vulnerability remediation. No child tables extend this one; it's a leaf table in the task hierarchy designed specifically for vulnerability tracking.

In large enterprises, this table grows rapidly - expect 50,000+ records per month in organizations with comprehensive vulnerability scanning. Performance remains solid because ServiceNow indexes key fields like vulnerability, configuration_item, and state. However, avoid queries that span multiple months without proper indexing - the volume can impact performance.

When You'll Script Against This Table

You'll primarily script against this table in Business Rules that automate vulnerability response workflows - like auto-assigning critical vulnerabilities to security teams, creating remediation tasks when new high-severity items are discovered, or updating CI risk scores based on vulnerability counts. Scheduled Script Executions frequently query this table to generate vulnerability dashboards, SLA compliance reports, and aging analysis for overdue remediations.

Access requires the sn_vul_read role minimum for queries, sn_vul_write for updates. The Security Operations application scope (x_swo_secops) controls most customizations, but global scope scripts can read and write with proper roles.

Common scripting patterns:

Auto-assign based on CI ownership or business service mapping
Calculate risk scores by aggregating CVSS scores across CIs
Create child remediation tasks for complex vulnerability fixes
Sync status with external vulnerability scanners via REST APIs
Generate compliance reports showing remediation timelines
Update CI records with vulnerability counts and risk ratings
Close duplicate vulnerable items when patches are applied

Table Gotchas

⚠️

The vulnerability field is NOT a direct reference to CVE records. It references sn_vul_vulnerability table records, which contain CVE details. Always join through the vulnerability table to get CVE numbers and CVSS scores.

⚠️

State transitions don't follow standard task workflows. States like 'Investigate', 'Remediate', and 'Verify' are vulnerability-specific. Don't assume task state logic applies here.

The configuration_item field accepts any CI class, but performance degrades with queries spanning multiple CI types. Filter by cmdb_ci subclasses when possible.
Records can exist without assignment_group values if auto-assignment fails. Always null-check before assuming assignment exists.

⚠️

The same CVE affecting the same CI can create multiple vulnerable item records if discovered by different scanners or scan runs. Check for duplicates before creating new records.

Queries filtering by vulnerability severity need to join to sn_vul_vulnerability - there's no direct severity field on vulnerable items.
Business Rules on this table fire frequently due to scanner integrations. Heavy processing in before rules can impact scanner performance.

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

The parent task table provides all the workflow infrastructure - states, assignments, approvals, and SLA tracking. When you need to understand vulnerability remediation processes, you'll often query task fields alongside vulnerability-specific data. The task inheritance also means vulnerable items appear in general task reports and assignment workbenches automatically.

The sn_vul_vulnerability table holds the actual CVE details, CVSS scores, and vulnerability metadata. You'll constantly join these tables together - vulnerable items for the "what needs fixing" and vulnerabilities for the "how bad is it" information. The cmdb_ci table and its subclasses (like cmdb_ci_computer, cmdb_ci_server) provide CI ownership, business service mappings, and environment details that drive assignment logic.

The sys_user_group and sys_user tables matter for assignment workflows and escalation paths. Many vulnerability response processes also create related records in change_request for patch management and sc_req_item for software updates, making these common join targets in comprehensive vulnerability tracking queries.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
vulnerability	reference	Vulnerability	References sn_vul_vulnerability table (not direct CVE records). This is the many-to-many link allowing one CVE to affect multiple CIs.
configuration_item	reference	Configuration Item	References any cmdb_ci record. Can point to servers, applications, network devices - performance degrades with mixed CI type queries.
state	choice	State	Vulnerability-specific states like 'Investigate', 'Remediate', 'Verify' - not standard task states. Don't assume normal task workflow applies.
priority	choice	Priority	Inherited from task table but often auto-populated based on vulnerability severity and CI criticality scoring algorithms.
first_found	glide_date_time	First Found	When this vulnerability was first discovered on this CI. Key field for aging reports and SLA calculations.
last_found	glide_date_time	Last Found	Most recent scan confirming this vulnerability still exists. Used to determine if vulnerabilities have been resolved.
source	string	Source	Identifies which vulnerability scanner or source created this record. Critical for deduplication logic across multiple scanners.
external_reference	string	External Reference	Scanner-specific identifier for this vulnerability instance. Used to sync status updates back to scanning tools.
risk_score	integer	Risk Score	Calculated risk value combining CVE severity with CI business impact. Often auto-updated by Business Rules.
remediation_details	string	Remediation Details	Text field containing fix instructions or patch information. Can be auto-populated from vulnerability feeds or manually updated.
closed_code	choice	Resolution Code	Reason for closure: Fixed, Risk Accepted, False Positive, etc. Required for proper vulnerability lifecycle tracking and reporting.
business_criticality	choice	Business Criticality	Business impact rating often inherited from the CI record. Drives priority calculations and assignment routing.
patch_available	boolean	Patch Available	Indicates if vendor has released a fix. May be auto-updated from vulnerability feeds or manually set by security teams.
exploit_available	boolean	Exploit Available	Whether known exploits exist in the wild. Significantly impacts priority calculations and remediation urgency.
assignment_group	reference	Assignment Group	Inherited from task table. Can be null if auto-assignment fails - always null-check before assuming assignments exist.

Common Queries

Get all active vulnerable items

// Most basic query - active items not yet resolved
var gr = new GlideRecord('sn_vul_vulnerable_item');
gr.addQuery('active', true);
gr.query();

while (gr.next()) {
    // Process active vulnerabilities
    gs.info('Active vulnerability: ' + gr.getDisplayValue());
}

Find high priority items assigned to specific group

// Common assignment workbench query
var gr = new GlideRecord('sn_vul_vulnerable_item');
gr.addQuery('state', '!=', '6'); // Not closed
gr.addQuery('priority', '1'); // High priority
gr.addQuery('assignment_group', 'security_team_sys_id');
gr.orderByDesc('first_found');
gr.query();

while (gr.next()) {
    gs.info('High priority item: ' + gr.number + ' - ' + gr.short_description);
}

Get vulnerabilities for specific server with CVE details

// Real-world scenario: audit specific server's vulnerabilities
var gr = new GlideRecord('sn_vul_vulnerable_item');
gr.addQuery('configuration_item', server_sys_id);
gr.addQuery('state', '!=', '6'); // Exclude closed
gr.query();

while (gr.next()) {
    var vuln = new GlideRecord('sn_vul_vulnerability');
    if (vuln.get(gr.vulnerability)) {
        gs.info('Server has CVE: ' + vuln.cve_number + ' - ' + vuln.short_description);
    }
}

Count vulnerable items by state using GlideAggregate

// Dashboard metrics query
var ga = new GlideAggregate('sn_vul_vulnerable_item');
ga.addQuery('active', true);
ga.groupBy('state');
ga.addAggregate('COUNT');
ga.query();

while (ga.next()) {
    var state = ga.getValue('state');
    var count = ga.getAggregate('COUNT');
    gs.info('State ' + state + ': ' + count + ' items');
}

Wrong vs right way to query by vulnerability severity

// WRONG: vulnerable items don't have direct severity field
// var gr = new GlideRecord('sn_vul_vulnerable_item');
// gr.addQuery('severity', 'High'); // This field doesn't exist!

// RIGHT: join through vulnerability table
var gr = new GlideRecord('sn_vul_vulnerable_item');
gr.addQuery('vulnerability.severity', 'High');
gr.addQuery('active', true);
gr.query();
// Dot-walking works for simple queries, but use explicit joins for complex filtering

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue

sn_vul_vulnerable_item