Before
Security analysts likely had to run or review public-asset scans, inspect vulnerabilities one by one, and manually verify which findings met the criticality threshold. They then searched vulnerability references and public proof-of-concept sources, checked Jira for an existing issue, updated or created a ticket, assigned it, and notified the responsible person.
How it works
- Run a scheduled public-asset search and iterate through each discovered asset and vulnerability.
- Keep only vulnerabilities with a CVSS score of 9.1 or higher, enrich them with vulnerability details, and look for relevant public proof-of-concept content.
- Check Jira for an existing issue, add a scan comment or create and assign a detailed incident ticket, then notify the assigned team member with the result.
Workflow details
- Scheduled asset discovery: The workflow runs on a predefined schedule and submits a configured search to identify public-facing assets and their exposed services. Each returned match is processed individually, including its hostnames, organization, IP address, port, product, and version details.
- Vulnerability triage: Vulnerabilities associated with each asset are evaluated one by one. Only findings with a CVSS score of 9.1 or higher continue through the enrichment and response process, while lower-scored findings are excluded from the final output.
- CVE enrichment: Each qualifying vulnerability is looked up in a vulnerability database to collect additional details. The workflow also searches for a publicly available proof of concept related to the CVE, evaluates whether a relevant GitHub result exists, and retrieves repository content when a matching result is found.
- Finding preparation: The workflow cleans and combines the asset information, CVE data, vulnerability database results, and available proof-of-concept content into a structured finding for downstream action.
- Ticketing and notification: For every enriched finding, the workflow checks whether a related Jira ticket already exists. Existing tickets receive a comment noting that the vulnerability was identified again during the current scan; otherwise, a detailed incident ticket is created, assigned to the vulnerability operations team and an individual team member, prioritized, and followed by a Slack notification containing the ticket URL and a summary.
What changed
The process now moves automatically from scheduled discovery through criticality filtering, enrichment, duplicate-ticket checking, Jira action, assignment, and notification. Existing vulnerabilities receive a scan update instead of another duplicate ticket, while new vulnerabilities are delivered as detailed assigned incidents with the relevant findings and ticket URL.
Work removed
Running and reviewing recurring public-asset searches, checking CVSS thresholds, looking up CVE details, searching for public proof-of-concept material, retrieving supporting repository content, checking Jira for duplicate tickets, copying findings into tickets, assigning issues, and manually notifying assignees.
Expected outcome
Conservatively, each qualifying finding removes roughly five or more recurring analyst lookups, updates, and handoffs while ensuring that critical scan results are routed to Jira and the assigned team member.
