# Re-rank your Jira security backlog by real-world exploitation

> Every weekday morning, check the CVEs in your open security tickets against live exploitation data and raise the ones attackers are actually hitting right now.

- Workflow type: agent
- Services: GreyNoise, Jira, Slack, Slack Bot
- Categories: Engineering, Operations
- Published: 2026-08-14

## What it does

- Reads the open vulnerability and patching tickets in your security project each weekday morning and pulls out the CVE each one refers to, even when it is buried in the ticket description.
- Checks those CVEs against live internet exploitation data, so you can tell the difference between a flaw that is theoretically risky and one that attackers are using today.
- Raises the priority on tickets that are being actively exploited but are still sitting at low or medium, and leaves a plain-language comment explaining what changed and when the activity was first observed.
- Posts one short summary to your security channel listing only what got escalated that morning, and stays completely silent on days when nothing changed.

## What you'll need

- A Jira account with a security or vulnerability project, plus permission to edit tickets and add comments.
- A GreyNoise plan that includes CVE data. GreyNoise only opens its CVE lookups to business accounts, so a personal free signup will not be enough.
- A Slack workspace and the channel where your security team wants the morning summary.
- Tickets that mention their CVE somewhere in the title or description. That reference is what links a ticket to real-world exploitation data.

## Prompt

Every weekday at 8am, sweep my open security backlog in Jira and re-rank it against what attackers are actually exploiting right now, using GreyNoise for the exploitation evidence and Slack for the summary.

Start with Jira's Search Issues (JQL) to pull the open vulnerability and patching tickets from my security project. Treat anything that is not in a done, closed, or resolved state as open, and let me set the project key and the exact status list at the top of the workflow so I can point this at whichever project holds my patching work.

Read each ticket's summary and description and extract the CVE identifiers it references. CVEs are often written into free text rather than a dedicated field, so look through the whole body and pick up anything matching the CVE-YEAR-NUMBER pattern. A ticket can reference more than one CVE. If a ticket references no CVE at all, skip it and leave it untouched, since there is nothing to check it against.

Collect the unique CVE identifiers across every ticket and check them against GreyNoise in a single Bulk CVE Lookup rather than one call per ticket. Where the bulk result suggests exploitation activity, or where it is ambiguous or missing the detail I need to justify a change, fall back to Retrieve CVE Information for that specific CVE to get the full timeline and the observed exploitation detail.

A ticket qualifies for escalation when its CVE is now showing active in-the-wild exploitation and the ticket is still sitting at a low or medium priority. Being theoretically severe or having a high severity score is not enough on its own. What matters is that GreyNoise is observing the vulnerability being exploited in the wild right now. Use your judgement reading the GreyNoise evidence, and when it is genuinely unclear whether activity counts as active exploitation, leave the ticket alone rather than escalating on a weak signal.

Before escalating any ticket, check its existing comments with Get Comments to see whether this workflow already escalated it. Every comment I post should carry a consistent marker line so it is easy to find later, something like "GreyNoise exploitation escalation" as the opening line. If such a comment exists and is dated within the last seven days, skip that ticket entirely and do not include it in the summary, so the same CVE does not get re-flagged every single morning.

For each ticket that does qualify, use Jira's Edit Issue to raise the priority. Move it to High, or to the highest priority level when GreyNoise shows widespread or rapidly escalating activity. Then use Add Comment to record the evidence in plain language, written so somebody skimming the ticket next week understands it without going back to the source: what changed, when GreyNoise first saw the activity, what that activity looks like, and why this jumped the queue ahead of the rest of the backlog. Reference the specific CVE and state the old and new priority.

Never quietly downgrade a ticket. Only ever raise priority, never lower it. Exploitation going quiet is not a reason to deprioritize a patch, because the underlying vulnerability is still unpatched and activity can resume at any time. If a previously escalated CVE has gone quiet, leave the ticket exactly where it is.

Finish with one Slack message via Send a Message to my security channel, summarizing only the tickets that were escalated this morning. Give each one a single line with the ticket key, a short description of what it patches, the CVE, the old and new priority, and a direct link to the ticket. Keep it scannable rather than writing paragraphs, since the detailed reasoning already lives in the ticket comment. Post exactly one message, not one per ticket.

On days when nothing was escalated, post nothing at all. No all-clear message and no empty summary, so that any message appearing in the channel always means something genuinely changed. The one exception is failure: if the GreyNoise lookups error out or the plan does not permit CVE access, post a short note saying the sweep could not complete, so that silence always means "nothing to escalate" and never means the workflow broke without anyone noticing.

## How to customize

- Change the schedule or the days it runs. Every weekday at 8am suits most patching routines, but a Monday-only sweep works if your team reviews the backlog weekly.
- Set which project it sweeps, which statuses count as open, and which priorities are eligible to be raised. By default only low and medium tickets can move.
- Adjust the quiet period so a recently escalated ticket is not re-flagged. Seven days is the default, so the same CVE does not resurface every morning.
- Point the summary at a different channel, or have it post under a bot identity instead of your own account.

## FAQ

### Will this ever lower a ticket's priority?

No. It only ever raises priority, never reduces it. A CVE going quiet does not mean the underlying flaw is patched, so exploitation dropping off is never treated as a reason to deprioritize the work.

### What happens on a day when nothing is being exploited?

Nothing is posted at all. There is no daily all-clear message, so any message in the channel means something genuinely changed and deserves attention. Silence is the normal state.

### Will the same CVE get flagged again every morning?

No. Before escalating, it checks whether this workflow already escalated that ticket in the last seven days and skips it if so. You get told once, not every day until the patch ships.

### Do I need a paid GreyNoise account?

You need a plan that includes CVE data. GreyNoise restricts its CVE lookups to accounts registered with a business email address, so a free personal signup will not be able to pull the exploitation detail this workflow depends on.

### What if a ticket does not mention a CVE?

It is skipped and left exactly as it is. The workflow only re-ranks tickets it can tie to a specific CVE, so general hardening or config tickets in the same project are untouched.

### Does it create new tickets?

No. It only re-ranks the backlog you already own. Nothing new gets added to the queue, so it makes your existing work more accurately ordered rather than giving you more of it.

Use this prompt in General Input: https://www.generalinput.com/prompts/re-rank-your-jira-security-backlog-by-real-world-exploitation