vulnerability-triage

name	vulnerability-triage
description	Use when scoring, classifying, or prioritizing security vulnerabilities — provides CVSS v3 scoring guide, severity classification criteria, patch SLA framework, and exploitability assessment methodology. Supporting skill for the security-audit harness. Also triggers on: re-run, update, revise, supplement.
metadata	{"category":"skill","harness":"28-security-audit","agent_type":"general-purpose"}

Vulnerability Triage — CVSS Scoring & Severity Classification Guide

Reference guide for scoring and prioritizing security vulnerabilities using CVSS v3.1, with severity classification criteria, patch SLA definitions, and exploitability assessment methodology.

---

CVSS v3.1 Overview

The Common Vulnerability Scoring System (CVSS) v3.1 provides a standardized method for rating the severity of security vulnerabilities. The base score reflects the intrinsic characteristics of a vulnerability, independent of time or environment.

Base Score Formula

CVSS Base Score is derived from the following metrics:

CVSS:3.1/AV:[N|A|L|P]/AC:[L|H]/PR:[N|L|H]/UI:[N|R]/S:[U|C]/C:[N|L|H]/I:[N|L|H]/A:[N|L|H]

---

Base Metric Groups

Exploitability Metrics

Metric	Key	Values	Description
Attack Vector	AV	N/A/L/P	How the vulnerability is exploited (Network/Adjacent/Local/Physical)
Attack Complexity	AC	L/H	Conditions beyond attacker control (Low/High)
Privileges Required	PR	N/L/H	Privileges needed before exploit (None/Low/High)
User Interaction	UI	N/R	Whether a user must participate (None/Required)

Attack Vector Values:

• Network (N): Exploitable remotely over internet — highest severity multiplier
• Adjacent (A): Exploitable only from same network segment (LAN, Bluetooth)
• Local (L): Requires local system access (file read, shell access)
• Physical (P): Requires physical device access — lowest severity multiplier

Attack Complexity Values:

• Low (L): No special conditions; attacker can exploit at will
• High (H): Requires specific conditions (race condition, specific config state)

Scope Metric

Value	Description
Unchanged (U)	Impact limited to the vulnerable component
Changed (C)	Impact extends beyond the vulnerable component (e.g., sandbox escape)

Impact Metrics

Metric	Key	Values	Description
Confidentiality	C	N/L/H	Information disclosure impact
Integrity	I	N/L/H	Data/system modification impact
Availability	A	N/L/H	Service disruption impact

Impact Values:

• None (N): No impact on this property
• Low (L): Some impact but attacker has limited control; some information exposed
• High (H): Complete loss of this property; attacker has full control

---

Severity Classification

Severity	CVSS Score Range	Color Code	Patch SLA
Critical	9.0 – 10.0	🔴 Red	24 hours
High	7.0 – 8.9	🟠 Orange	7 days
Medium	4.0 – 6.9	🟡 Yellow	30 days
Low	0.1 – 3.9	🟢 Green	90 days
Informational	0.0	⚪ None	Next release cycle

---

Common CVSS Score Examples

Critical (9.0–10.0)

Scenario	Vector	Score
Unauthenticated RCE over network	AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H	10.0
SQL injection with full DB dump	AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H	9.8
Auth bypass gaining admin access	AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L	9.4

High (7.0–8.9)

Scenario	Vector	Score
Authenticated RCE	AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H	8.8
Unauthenticated data exfiltration	AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N	7.5
SSRF to internal metadata service	AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N	8.2
Stored XSS with session hijack	AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N	7.6

Medium (4.0–6.9)

Scenario	Vector	Score
Reflected XSS	AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N	6.1
CSRF on account settings	AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N	6.5
Sensitive data in error messages	AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N	4.3

Low (0.1–3.9)

Scenario	Vector	Score
Missing security header	AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N	4.3
Verbose server header disclosure	AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N	5.3
Username enumeration via timing	AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N	3.7

---

Exploitability Assessment

Exploitability Criteria

Rate each finding across these four dimensions (1–5 scale):

Dimension	1 (Lowest)	3 (Medium)	5 (Highest)
Technical Skill Required	Requires specialized knowledge	Some security experience	Script kiddie / automated tool
Tools Available	Must build from scratch	Available in research	Public PoC / Metasploit module
Access Prerequisites	Physical + privileged	Authenticated user	Unauthenticated / public
Attack Complexity	Complex multi-step	Some conditions	One-click / trivial

Exploitability Score = (Skill + Tools + Access + Complexity) / 4

• 4.0–5.0: Trivially exploitable — critical urgency
• 3.0–3.9: Likely to be exploited — high urgency
• 2.0–2.9: Exploitable with effort — medium urgency
• 1.0–1.9: Difficult to exploit — standard schedule

---

Remediation Priority Matrix

Priority = max(CVSS Severity, Exploitability Severity) adjusted for business impact:

CVSS Severity	Asset Criticality	Exploitability	Final Priority	SLA
Critical	Any	Any	P0	24 hours
High	Critical	High	P0	24 hours
High	Standard	High	P1	7 days
High	Standard	Low	P2	14 days
Medium	Critical	High	P1	7 days
Medium	Standard	Any	P2	30 days
Low	Any	Any	P3	90 days

Asset Criticality Tiers:

• Critical: Payment processing, authentication, PII storage, admin systems
• Standard: Core application features, API endpoints
• Low: Internal tools, admin UIs, dev/test environments

---

Deduplication Rules

When the same underlying vulnerability is reported by multiple analysis domains:

1. Code + Dependency: If a vulnerable library usage is flagged in code AND dependency scan → merge into one finding; use the higher CVSS score; note both sources
2. Config + Code: If insecure config is referenced in code AND in config review → merge; note both exploitation paths
3. Threat Model + Code: Threat model predicted a risk that code analysis confirmed → merge; note it as "threat confirmed by code evidence"
4. Multiple instances: Same vulnerability pattern in multiple files → one finding with N occurrences in [files]; don't list each line

Deduplication Process

1. Group findings by root cause (not symptom)
2. Keep the highest CVSS score from any source
3. Merge remediation advice from all sources
4. Add cross-reference: "Also reported by: [other agent]"

---

CVE Database Reference

Key databases to consult when evaluating dependency vulnerabilities:

Database	URL	Best For
NVD (NIST)	https://nvd.nist.gov/vuln/search	Authoritative CVSS scores
OSV	https://osv.dev	Open source packages across ecosystems
GitHub Advisory	https://github.com/advisories	npm, PyPI, RubyGems, Go, Rust
Snyk Advisor	https://snyk.io/advisor	Package health + CVE data
CVE Details	https://www.cvedetails.com	Historical CVE trends per vendor

CVE Severity Mapping

CVE severity often uses CVSS v2; always upgrade to CVSS v3.1 for accurate scoring. CVSS v2 scores are typically 1-2 points lower than equivalent v3.1 scores.

---

Patch SLA Framework

SLA Definitions

Priority	CVSS Range	Discovery to Patch	Patch to Deploy	Total Remediation
P0 Critical	9.0–10.0	Same day	24 hours	≤ 24 hours
P1 High	7.0–8.9	48 hours	5 days	≤ 7 days
P2 Medium	4.0–6.9	7 days	23 days	≤ 30 days
P3 Low	0.1–3.9	30 days	60 days	≤ 90 days

SLA Exception Process

If an SLA cannot be met:

1. Document reason in vulnerability tracker
2. Implement compensating control (WAF rule, feature flag, network restriction)
3. Obtain risk acceptance sign-off from security lead
4. Set new SLA with compensating control in place
5. Track for closure; no finding may exceed 2× original SLA without re-approval

---

Reporting Format Guidelines

Per-Finding Report Block

## Finding: [Short Title]

**ID**: VULN-[YYYYMMDD]-[NNN]
**Severity**: [Critical | High | Medium | Low]
**CVSS v3.1 Score**: [X.X] ([vector string])
**Source**: [Agent / Tool]
**Location**: [file:line or component:version]

### Description
[1-3 sentences explaining the vulnerability]

### Attack Scenario
[Step-by-step exploitation path]

### Business Impact
[What happens to the business if exploited]

### Remediation
[Specific, actionable fix with code/config example if applicable]

### References
- [CVE ID if applicable]
- [OWASP A0X if applicable]
- [CWE-XXX if applicable]