Patch prioritization board built on live exploitation data

Build me a patch prioritization board that our vulnerability management lead works out of during every patch cycle. The organizing idea is that ranking is driven by what attackers are actually exploiting and whether that activity is rising, not by CVSS severity score alone. A moderate-severity CVE under heavy live exploitation should sit above a critical-severity one with no observed attacks.

The board loads from two sources. One handler calls GreyNoise List CVEs filtered to exploitable-only, which gives the set of CVEs GreyNoise currently observes being exploited along with their exploitation metadata. A second handler calls Jira Search Issues (JQL) to pull our open security and vulnerability tickets. Make the JQL configurable in the app with a sensible default along the lines of restricting to the security and vulnerability projects and excluding done work, because every team scopes their security backlog differently. Match CVEs to tickets by checking whether the CVE ID appears in the ticket summary or description, case-insensitively, and handle the case where one ticket references several CVEs and where several tickets reference the same CVE.

Lay the result out in three columns. First, exploited in the wild with no ticket anywhere: this is the gap that matters most and it goes on the left with a visible count in the column header, so the board is worth opening even on a quiet week when the number is zero and that is itself the answer. Second, exploited with a ticket already open, showing the ticket key and status on the card. Third, ticketed but with no observed exploitation, meaning it can wait. Within each column, sort by observed exploitation activity and its trend, so CVEs with more attacking IPs and rising recent activity float to the top, and show the severity score on the card as secondary context rather than as the sort key.

Clicking any CVE opens a detail panel backed by GreyNoise Retrieve CVE Information. Show what the vulnerability is, the exploitation timeline including when activity was first and most recently observed and how it has moved over time, how many distinct IPs have been seen attacking it, and where those IPs come from. If the source country breakdown is not in that payload, fill it in with a GreyNoise GNQL Stats call for the IPs exploiting that CVE. Alongside the GreyNoise data, show the linked Jira ticket with its status and assignee when one exists, and when none exists say so plainly and offer the filing action.

From the gap column the lead files a tracked ticket straight into the right project using Jira Create Issue. Let them pick the project and issue type, defaulting to the last one used, and prefill the summary with the CVE ID and the description with the exploitation evidence already gathered: the number of attacking IPs, the countries they come from, when activity was first observed, the trend, and the severity score. Use Jira Search Projects to populate the project picker. After the ticket is created, move that CVE card into the middle column and drop the gap count by one without a full page reload.

Every CVE also has a "Write the remediation brief" button that starts a background agent. The agent pulls the CVE timeline with GreyNoise Retrieve CVE Information, runs a GreyNoise GNQL Query for the IPs currently exploiting that CVE to see who is behind the activity and how they are classified, and then writes a short brief covering what the vulnerability is, who is hitting it and from where, and how urgently we should patch given the exploitation trend. The brief lands back in the app on that CVE so the lead can read it in the detail panel, and when the CVE has a linked ticket the agent also posts it onto that ticket with Jira Add Comment. Show the button in a running state while the agent works and surface the finished brief when it arrives, with the ability to rerun it later once activity has changed.

State plainly in the app setup notes that the GreyNoise CVE endpoints require the CVE-search entitlement, which GreyNoise grants only to accounts registered with a business email address, so a key from a personal email account will connect but return nothing. If the CVE call comes back empty or entitlement-restricted, say that in the empty state rather than showing a silently blank board.