Vulnerability Prioritization

Analyze CVE reports against your deployed infrastructure and generate a prioritized patching plan.

Integrations: GitHub, Jira

When to Use

• The user has vulnerability scan results (e.g., Nessus, Trivy, Snyk) and needs to prioritize which CVEs to patch first
• A security or compliance audit requires evidence of risk-based patching decisions
• The user mentions "CVE prioritization", "vulnerability triage", "patching plan", or "too many CVEs to patch"
• Teams need Jira tickets or task tracking for remediation work

Steps

Step 1: Ingest Vulnerability Data

Collect and normalize vulnerability inputs:

Source	Format	Key Fields to Extract
Nessus / Qualys export	XML, CSV	CVE ID, severity, affected package/version, host/IP
Snyk / Dependabot	JSON, API	CVE ID, package, version, fix version, direct vs transitive
Trivy / Grype	JSON	CVE ID, severity, package, installed version
Manual CVE list	CSV, list	CVE ID, severity, description

Ask the user for: scan export or CVE list, scan date, and scope (which environments, which asset groups).

Use GitHub MCP to cross-reference CVE data with repository dependencies (package.json, requirements.txt, go.mod, etc.).

Step 2: Map to Deployed Infrastructure

Correlate vulnerabilities with actual running services:

Infrastructure Data	Source	Use
Service inventory	Confluence, docs, deployment manifests	Which services run which components
Dependency trees	package.json, Pipfile, go.mod	Which packages (and versions) are in use
Network exposure	Load balancers, ingress, firewall rules	Public vs internal vs no network
Data sensitivity	Data classification, compliance scope	PHI, PII, financial data handling
Deployment topology	K8s manifests, Terraform, CloudFormation	Which nodes/pods run which workloads

Use GitHub MCP to read deployment configs, Dockerfiles, and dependency files. Map each vulnerable component to specific deployed services and their exposure level.

Step 3: Assess Exploitability and Impact

Score each CVE for actual risk in the user's environment:

Factor	High Risk	Medium Risk	Low Risk
Network exposure	Public internet, DMZ	Internal only	No network, air-gapped
Data sensitivity	PHI, PII, payment data	Internal business data	Non-sensitive
Active exploits	Known exploit in wild	PoC available	No known exploit
Ease of exploitation	Remote, no auth	Local or auth required	Complex chain
Compensating controls	None	WAF, IDS	Full isolation, no access

Combine with CVSS/base severity to produce a final Effective Severity (Critical/High/Medium/Low) and SLA category.

Step 4: Generate Prioritized Patching Plan

Create a risk-ranked plan with SLA windows:

SLA Tier	Severity	Patch Window	Example
P0	Critical + exploitable	7 days	Public-facing auth service
P1	High + exposed	30 days	Internal services with sensitive data
P2	Medium or low exposure	60–90 days	Internal-only, non-sensitive
P3	Deferred	Next quarter	Not in dependency tree, or compensating controls

For each prioritized CVE, document:

1. CVE ID and affected package/version
2. Affected services (names, repos, deployment paths)
3. Remediation — Upgrade path, workaround, or accept risk with justification
4. SLA deadline based on tier

Step 5: Create Tracking Tickets

Use Jira MCP to create tickets:

Field	Value
Project	User's security/project key
Issue type	Task or Story
Summary	e.g., "Patch CVE-2026-1234 in payment-api (Critical)"
Description	CVE details, affected service, remediation steps, SLA
Labels	CVE, severity, service name
Priority	Map P0→Highest, P1→High, etc.
Due date	SLA deadline

Link tickets to parent epic or initiative if the user has one. Optionally add sub-tasks for each affected service.

Output

Deliver:

• Prioritized patching plan table with CVE, severity, affected services, exposure, and SLA
• List of deferred CVEs with rationale (not in use, not exploitable, compensating controls)
• Jira tickets for each prioritized CVE with remediation details and due dates
• Executive summary (total CVEs, exploitable count, critical/high SLA counts)
• Optional: Remediation playbook with upgrade commands or workaround steps per package