Vulnerability Response & SecOps
Who uses this. Security operations teams managing vulnerability remediation at scale. Typically a dedicated VM programme with structured SLAs, remediation owners, and executive reporting. ServiceNow is the system of record for remediation workflow.
The problem. ServiceNow Vulnerability Response ingests findings from scanners and creates remediation tasks, each carrying a CVSS score and an age. Without an external exploitation signal, every 9.3 CVSS finding looks the same, whether it was exploited by a nation-state actor last week or has never appeared in any threat intelligence feed. The queue does not know which items got more dangerous while they were waiting.
A scheduled Integration Hub flow or MID Server script runs daily after the ESIP snapshot publishes. It downloads the JSON snapshot from github.com/ZenzizenSec/esip-data, loads it into a staging import set, and runs a transform map against the sn_vul_entry table.
For each open vulnerability record, the transform map checks whether the CVE ID exists in the snapshot. If it does, it writes three fields to the record:
esip_kev_confirmed [true/false] kev_inclusion event present
esip_weaponized [true/false] Metasploit or ExploitDB exploit_reference present
esip_attack_technique [string] ATT&CK technique_idA business rule re-evaluates priority for any record where esip_kev_confirmed = true or esip_weaponized = true. Those records are surfaced in the remediation manager’s daily work queue under a new view: “ESIP-Active Exploitation.”
The remediation manager opens ServiceNow to a filtered view split into two groups: CVEs with confirmed exploitation evidence from ESIP, and everything else. The first group contains 14 items out of a queue of 3,200. Those 14 get worked today.
What it takes to build: A small build: one scheduled Integration Hub flow, one transform map, three custom fields, one business rule, one saved filter, for a ServiceNow developer with Integration Hub experience.
The daily batch job is replaced by two live integration points.
On record creation: a Business Rule fires when a new vulnerability record is created in sn_vul_entry. It calls the ESIP commercial API and writes directly to the record:
esip_lifecycle_stage Confirmed
esip_severity_score 75
esip_confidence Verified
esip_current_trend Escalating
esip_signal_velocity High
esip_compound_risk Strong
esip_what_changed "Metasploit module detected: cpanel_whm_auth_bypass_rce"
esip_threat_age_days 18
esip_weaponization_age 3The SLA clock, assigned group, and initial priority are all set from ESIP fields before the record reaches a human.
Daily change sweep: a scheduled flow calls the ESIP change feed each morning:
GET api.exposuresignal.io/v1/signals/changes?updated_since=yesterdayFor every CVE in the change feed with an open ServiceNow record:
New records arrive pre-enriched, the queue is always current, and tickets that escalated overnight are flagged before the remediation manager opens their laptop. The what_changed narrative in work notes says exactly why the ticket changed, with nothing to look up.
Executive reporting: the ESIP fields feed ServiceNow dashboards natively, so the monthly exposure-management metric is generated from a ServiceNow report rather than a manual script.
What it takes to build: A contained build: one Business Rule on insert, one scheduled Integration Hub flow, nine custom fields, updated SLA conditions, updated assignment rules, two executive reports, for a developer with REST integration experience. The commercial schema is versioned and stable: built once, maintained as ESIP adds sources.
The free tier gives you observable facts. The commercial platform turns those facts into an explainable exposure signal: what changed, why it matters, and what to do next.