Vulnerability Intelligence

Not all vulnerabilities are equal. This skill provides a prioritisation methodology that goes beyond CVSS scores.

Prioritisation Framework

1. CVSS (Common Vulnerability Scoring System)

Base score provides a starting point but should NEVER be the sole prioritisation factor.

Score	Severity	Notes
9.0-10.0	Critical	Immediate attention, but check exploitation status
7.0-8.9	High	High priority, especially if internet-facing
4.0-6.9	Medium	Standard patching cycle unless other factors elevate
0.1-3.9	Low	Lowest priority

2. EPSS (Exploit Prediction Scoring System)

Predicts the probability that a vulnerability will be exploited in the next 30 days (0-1 scale).

EPSS Score	Interpretation
>0.9	Very high probability of exploitation — treat as urgent
0.5-0.9	High probability — prioritise
0.1-0.5	Moderate probability — evaluate with other factors
<0.1	Low probability — standard cycle

3. CISA KEV (Known Exploited Vulnerabilities)

If a vulnerability is on the CISA KEV list, it IS being exploited in the wild. Patch immediately regardless of CVSS score.

4. Weaponisation Assessment

Stage	Description	Priority Impact
In the wild	Active exploitation confirmed	PATCH NOW
Weaponised exploit	Reliable exploit available (Metasploit, commercial)	Very high priority
PoC available	Proof-of-concept published (GitHub, blog)	High priority — weaponisation imminent
Technical details	Advisory with enough detail to develop exploit	Medium — monitor for PoC
Advisory only	CVE assigned, limited technical detail	Standard priority

5. Combined Prioritisation Matrix

Priority	Criteria	Action
P1 — Emergency	KEV listed OR in-the-wild exploitation + internet-facing	Patch within 24 hours
P2 — Urgent	Weaponised exploit available + internet-facing, OR KEV + internal	Patch within 72 hours
P3 — High	PoC available + internet-facing, OR high CVSS + high EPSS	Patch within 7 days
P4 — Standard	High CVSS but no exploitation evidence + compensating controls	Patch within 30 days
P5 — Low	Low CVSS + internal only + strong controls	Next patch cycle or accept risk

Vulnerability Assessment Template

## Vulnerability Assessment: CVE-YYYY-XXXXX

### Overview
- **CVE**: CVE-YYYY-XXXXX
- **Affected Product**: [Product and versions]
- **CVSS Base Score**: X.X ([vector string])
- **EPSS Score**: X.XX (as of YYYY-MM-DD)
- **KEV Listed**: Yes/No
- **Priority**: P1/P2/P3/P4/P5

### Exploitation Status
- **In the wild**: Yes/No [evidence]
- **Weaponised exploit**: Yes/No [Metasploit module, commercial exploit]
- **PoC available**: Yes/No [GitHub link, blog post]
- **Threat actors exploiting**: [Known actors, if any]

### Exposure Assessment
- **Internet-facing instances**: [Count if known]
- **Internal instances**: [Count if known]
- **Compensating controls**: [What mitigates even without patching?]
- **Detection capability**: [Do we have rules for exploitation of this?]

### Recommendation
[Patch/mitigate/accept risk with justification]

### Sources
[With Admiralty ratings]

Related skills

• Find vulnerable internet-exposed assets — /lookup-shodan search 'product:"<name>" version:<v>"' and /lookup-censys search '<CPE>' for population-level exposure counts; /lookup-shodan host <ip> for asset-level confirmation
• Track exploit availability and weaponisation — /lookup-virustotal + /lookup-otx for malware leveraging the CVE; /lookup-misp search-attributes --type vulnerability --value CVE-YYYY-NNNNN for prior internal events
• First-party exploitation evidence — /lookup-liberty91 library vulnerabilities --name CVE-YYYY-NNNNN for the canonical record (CVSS, EPSS, KEV status, CWE ids), then entity vulnerabilities <id> --section threat-events for occurrences naming it. An occurrence classed security-incident (rather than vulnerability) means a named victim was actually hit — that is exploitation in the wild, not a disclosure event, and it should move the CVE up the queue
• Ransomware operators' favourites — /lookup-ransomwarelive group-profile <name> exposes per-group documented exploited vulnerabilities; cross-reference against your inventory
• Detection authoring — once exploitation is observed, /sigma-writing and /yara-writing produce the rules
• Apply rigor — /score-source, /apply-tlp, /confidence-language