Skip to main content

​
Overview

Known Exploitable Vulnerabilities (KEVs) are vulnerabilities that are more than potential vectors for compromise - they’re vulnerabilities that are being actively exploited in the real world. For engineers, this means KEVs pose an immediate and measurable risk to production systems because attackers are already using them in the wild, often with automated tooling. Unlike normal CVEs, KEVs bypass the guesswork: they tell you exactly which issues attackers are weaponising today.

​
Objective

I automate the constant monitoring and issue triage to stay ahead of active threats by acting as your virtual security analyst. I identify any newly announced KEVs across your cloud estate, understand which workloads are impacted, and generate actionable Jira tickets with enriched cloud context so engineers can prioritise real risk without having to spend significant amounts of time in triage. I prepare the incident analysis and push it to your ticketing platform of choice, empowering engineers to assess the data and make a quick decision on whether action needs to be taken immediately or during the next scheduled patch management window.

​
Prompt

KEV discovery and analysis
Hey Pleri, every day I want you to act as a Security Analyst and create a Jira ticket for any KEV vulnerabilities in our cloud. There should be 1 ticket per asset affected by a KEV.

Run this task once initially so that I can have tickets for all KEVs in our environment.

Every time this daily task runs, send me a a summary in Slack so that I can keep updated with this daily check.

Structure

Heading: Pleri Security - {Exploitable or KEV Exploited} {CVE ID} found on {asset name} in {cloud} {resource type}

Summary Table: CVE details including KEV status, dates, CVSS, ransomware use, and exposure

Asset Information Table: Asset details with owner identification (from tags/metadata)

Contextual Risk Assessment: Risk rating with rationale

Remediation Recommendation: Provide remediation guidance as the preferred option.

Mitigation Options: If there is a recommended mitigation control(s) that can be implemented, in case immediate remediation isn't possible.

Verification Steps: Pre and post-remediation validation commands

Exploitability Intelligence: Public exploits and active exploitation status

IAM Blast Radius Analysis: Identity permissions and lateral movement risk

Sources: NVD/CISA links, cloud asset portal link, and Plerion platform reference

Format Requirements:

Use tables for structured data

Include verification commands in code blocks

Surface all key risk indicators in the summary

Reference Plerion data sources

Keep it actionable and engineer-friendly

​
Customization

Adjusting notification channels: Replace Jira creation with Slack or E-mail if you want me to communicate summaries instead of tickets Filtering by environment: I can limit to production workloads only, or exclude dev/sandbox to reduce noise. Ticket volume control: Instead of one ticket per asset, I can group related KEVs into a single ticket per service/team. Team assignment rules: I can auto-route tickets based on tags (Owner, Team), or route everything to SecOps first.

​
Required inputs

I need the following pre-requisites to execute this playbook:
  • Plerion CWPP integration with AWS, Azure or GCP
  • Jira integration (or integration with your preferred method for communication / issue management)
  • Slack integration

​
Workflow

Here’s what I do: