Engineering & AppSec teams
Who uses this. Engineering and product teams managing vulnerability remediation as part of a development sprint. Typically a security engineer or AppSec team working alongside developers who live in Jira. Remediation is tracked as Jira issues, not in a dedicated VM platform.
The problem. A security engineer opens a Jira board of 200 open vulnerability issues, each carrying the CVSS score from the day it was created, some six months old. Nothing tells them which became more dangerous while they waited. The developer assigned to fix CVE-2025-17832 does not know a Metasploit module appeared for it two weeks ago. The priority column has not changed since the issue was created.
ServiceNow VR is built for a dedicated VM programme with SLAs and management reporting. Jira is where developers work, so the integration fits a developer’s context: brief, actionable comments rather than structured field enrichment. The goal is not to turn Jira into a VM platform, it is to surface the one thing a developer needs: “this one got worse, fix it this sprint.”
A daily Python script or GitHub Action runs after the snapshot publishes. It queries Jira for open issues with a cve_id custom field (or the CVE in the title), downloads the snapshot, and for each open issue checks whether the CVE gained new exploitation evidence since ESIP last commented. If it did, it posts a comment:
ESIP Update: CVE-2026-41940
New exploitation evidence appeared since this issue was opened:
- Metasploit Framework Modules (2026-05-18)
- CISA Known Exploited Vulnerabilities (2026-04-30)
- ATT&CK Technique: T1078 Valid Accounts
Recommend prioritising this sprint.It then adds the label esip-evidence-updated, and optionally bumps priority if a kev_inclusion is present.
The developer opens their issue and sees a comment in plain language. They do not need to know what ESIP is: the comment tells them this CVE now has a Metasploit module and CISA has confirmed exploitation, so prioritise it.
The esip-evidence-updated label lets the security engineer filter the board to every open issue where ESIP posted an update this week. That filtered view is today’s security priority list.
What it takes to build: A lightweight build: one Python script or GitHub Action, one Jira custom field (cve_id), one label convention, one saved filter, for a security engineer with Python and the Jira API. No Jira admin required for the basic implementation.
On issue creation: a Jira webhook fires when a vulnerability issue is created. A lightweight service calls the ESIP commercial API and writes structured data back via the Jira API:
{
"esip_lifecycle": "Confirmed",
"esip_confidence": "Verified",
"esip_trend": "Escalating",
"esip_velocity": "High",
"esip_compound": "Strong",
"esip_what_changed": "Metasploit module detected: cpanel_whm_auth_bypass_rce"
}These populate custom fields on the issue, and priority is set automatically from esip_lifecycle and esip_confidence. The issue arrives in the developer’s queue pre-enriched: they know immediately whether this is a theoretical vulnerability or an active exploitation event.
Daily change sweep: a scheduled job calls the ESIP change feed each morning. For open Jira issues whose CVE appears in the feed:
The developer’s board reflects current threat reality: issues that got more dangerous this week carry a comment explaining why and a priority change, issues where the threat is cooling carry a note, and sprint planning includes an ESIP-flagged filter, “CVEs that escalated this sprint.”
What it takes to build: A small build: one webhook handler, one scheduled job, six custom fields, three Jira automation rules, one board filter, for a security engineer comfortable with REST APIs and Jira automation. No Jira admin required beyond custom field creation.
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.