ServiceNow SecOps — Vulnerability Response & Security Incident Response

Security analysts and SOC managers do their triage inside ServiceNow Security Operations (SecOps), not in a CI tool. SARC connects your GitLab, GitHub, and Azure DevOps security scans straight into SecOps, so the security team sees your findings in the workspaces they already run — while engineering keeps working in the portal. The sync is automatic, idempotent, and closes itself when a finding is fixed.

User story

As a security analyst / SOC manager at a bank running SARC against our ServiceNow instance, I want every vulnerability our pipelines find to appear in ServiceNow Vulnerability Response — and every critical one to raise a security incident for the SOC, tagged with the compliance controls it breaks — so that we triage and remediate in our own SecOps workspaces with our own SLAs, and an auditor can trace a finding from the scanner, to the affected service CI, to the security incident, to its closure.

Two destinations — VR and SIR

Our finding	ServiceNow	Who works it
Every open finding	`sn_vul_vulnerable_item` (Vulnerability Response)	Security analysts
Critical findings	`sn_si_incident` (Security Incident Response)	SOC managers / analysts

Each VR item links the affected Application Service CI (cmdb_ci_service, the same CI the CMDB integration maintains) and, when the CVE is known, the CVE catalog entry (sn_vul_entry). Each SIR incident links the VR item and the CI, and tags the compliance controls the finding impacts — e.g. SOC2 CC7.1, PCI_DSS 6.3.2, DORA Art9 — so the SOC sees the governance context, not just a CVE.

How it flows

flowchart LR
  A[GitHub / GitLab / Azure DevOps scanners] --> B[Portal security-sync]
  B --> C[VulnerabilityRecord + CVE / CVSS / fix]
  C --> D[ServiceNow VR item · sn_vul_vulnerable_item]
  C -->|critical| E[ServiceNow SIR incident · sn_si_incident]
  D --> F[links service CI + CVE]
  E --> G[links VR item + CI + tags controls]
  C -->|fixed| H[VR item + SIR incident auto-close]

Findings are matched idempotently on a SARC-owned key, so re-syncing never creates duplicates — and the same key closes the record when the finding clears. If a fixed vulnerability is later reintroduced, a fresh VR item and incident are raised, so the security team’s queue never silently drifts from reality.

Where you see it in the portal

On the portal’s Vulnerabilities page, a Source column makes the two dimensions explicit:

a provider badge (GitHub / GitLab / Azure DevOps) shows where the finding came from — the scanner of record;
a green SN · VITxxxx badge shows it is mirrored into ServiceNow VR and deep-links to the item;
the row drawer’s ServiceNow Vulnerability Response section links the VR item and, for criticals, the SOC incident (SIR);
a Synced to ServiceNow KPI shows how many findings are in SecOps.

So at a glance you can tell what came from GitHub/GitLab/ADO and what is live in ServiceNow.

Turning it on

The sync is opt-in and uses the tenant’s existing ServiceNow credentials (Settings → ServiceNow). On the portal deployment:

Setting	Enables
`SN_AUTO_SECOPS`	Vulnerability Response item writes
`SN_AUTO_SIR`	Security Incident Response writes (critical findings)

Both default off; when either is off, that half is a silent no-op. State and close codes are instance-specific and overridable per instance.

Full operational reference: docs/ci/servicenow/SECOPS.md.

Why it matters for a compliance demo

This closes the loop between engineering’s scanners and the security team’s system of record. A vulnerability found by a GitLab dependency scan becomes a governed ServiceNow vulnerable item on the right service CI; if it’s critical, the SOC gets an incident that already names the SOC2 / PCI / DORA controls at risk — and when the pipeline fixes it, both close automatically. One finding, one traceable chain, in the tools each team already uses.