vulnerability-sla-process

name	vulnerability-sla-process
description	Vulnerability management SLAs by severity, exception/risk-acceptance process, scanner-noise handling, and ticket lifecycle for org-owned findings. Use when vulnerability SLA, fix-by severity clocks, exception request, risk acceptance, vuln ticket workflow, scanner noise backlog, CVE remediation deadline, or AppSec queue SLAs — not for writing exploits.

Vulnerability SLA Process

Run an owned vulnerability management loop: severity → SLA clock → ticket → fix or exception → verify → close. Process for scanner, pentest, bounty, and internal findings — not exploit writing. Org risk matrices and compliance clocks outrank example timelines; one severity scale, map tool scores into it.

When To Use

• Defining or enforcing fix SLAs (Critical/High/Medium/Low) for vulns/CVEs
• Designing exception / risk-acceptance (who signs, max duration, review)
• Turning scanner dumps into triaged, owned tickets without drowning teams
• Standardizing ticket fields, states, retest gates; measuring SLA health
• Chinese/English teams: 漏洞 SLA, 修复时限, 风险接受, 扫描噪声, 漏洞工单

Do not use as primary for: SAST/DAST ops → sast-dast-tooling-usage; SSDLC gates → secure-sdlc-checklist; class deep-dive → matching skill; bounty program → bug-bounty-methodology; incident SEV → incident-runbook-writing; code fix quality → code-quality-standards.

Severity And Default SLAs

Map tool severity / CVSS → org severity once; document overrides (e.g. Critical CVE on unreachable code may triage lower after reachability).

Org severity	Typical meaning (adapt)	Default fix SLA	Gate posture
Critical	Likely exploit path, RCE/auth bypass on exposed systems, credential leak, KEV-class	24–72h	Block affected release/deploy when policy requires
High	Significant impact if reachable; priv-gain / sensitive data paths	7–14 days	Block release unless exception
Medium	Limited blast radius or harder conditions	30–60 days	Track; may not block every PR
Low / Info	Hardening, low exploitability, noise candidates	90 days / backlog	Never share Critical panic channel

Clock start: when marked true positive (or “needs fix”) with owner — record both first seen and SLA start. Optional asset multipliers (internet-facing shorter; lab longer) must be a published table, not per-ticket haggling.

Workflow

1. Intake

1. Normalize source: SAST/DAST/SCA, image, pentest, bounty, internal report.
2. Deduplicate by fingerprint (rule + location/package + root cause), not CVE alone.
3. One primary ticket per root cause; link instances as children.
4. Capture: service/asset, env, data class, exposure, tool id, redacted evidence.

2. Triage (scanner noise)

Status	Meaning	SLA impact
True positive	Confirmed; needs fix or exception	Start clock; assign owner
False positive	Tool wrong / N/A	Close with reason; tune rules (sast-dast-tooling-usage)
Duplicate	Same root cause as open ticket	Link/close; do not blindly restart clock
Acceptable risk	Signed exception	Clock becomes review-by, not “ignore forever”
Info / OOS	Hygiene or wrong asset	Backlog or close; keep out of Critical channel

Collapse URL floods; require reachability before escalating SCA Critical; never bulk-close High+ without sampling.

3. Severity, owner, ticket

1. Set org severity after exposure/auth/data context.
2. Owner = team that ships the fix; AppSec owns process and disputes.
3. Set due date from SLA table; review breaches weekly.
4. States: New → Triaging → Open → Retest → Closed; plus time-boxed Exception requested → Exception approved → reopen on expiry.
5. Required fields: org + tool severity, SLA due/breach, asset + exposure, root cause + plan, owner, evidence/retest, exception id + expiry.

4. Remediate and retest

1. Fix under code-quality-standards; prefer dependency upgrade over silent pins.
2. Compensating controls (WAF, network block, flag off) buy time or lower severity — not automatic closes.
3. Retest same fingerprint; close only with clean evidence (version/digest).

5. Exception / risk acceptance

When SLA fix is not feasible and residual risk is understood: named requestor (no chat-only OK); package finding id, residual risk, users/data, compensations, max duration, review date, exit criteria; High+ often security + service lead (+ CAB/legal if required); no infinite renewals; expiry reopens as Open; link ship-blocking exceptions to release records (secure-sdlc-checklist).

6. Metrics

Track % Critical/High past SLA, median triage→owner, FP rate by rule, open exception age, reopen-after-fixed. Quarterly: purge stale Low, review suppressions.

Routing

Situation	Primary	Helper
Vuln SLAs, exceptions, ticket workflow, 漏洞修复时限	This skill	—
Scanner ops / FP rule tuning	sast-dast-tooling-usage	this skill for clocks/tickets
SSDLC gates / release exception placement	secure-sdlc-checklist	this skill for severity clocks
Implementing the code/config fix	code-quality-standards	this skill for due dates
Dependency CVE / SBOM inventory	sbom-and-supply-chain	this skill for remediation SLAs
Bounty report intake	bug-bounty-methodology	this skill once ticketed
Active incident from exploited vuln	incident-runbook-writing	this skill after contain for residual SLA

Output Checklist

• Org severity scale + tool-score mapping (with override rules) published
• SLA table (Critical→Low) and clock-start definition documented
• Intake + fingerprint/dedup rules for all sources
• Triage statuses used; every High+ has owner and due date
• Ticket template: severity, due, asset, exposure, evidence, retest, exception
• One primary ticket per root cause; instances linked
• Exception form: approver, residual risk, compensations, expiry, exit criteria
• Expired exceptions reopen visibly; no permanent silent suppressions
• Retest required before Closed; evidence tied to version/digest when relevant
• Metrics (breach, open age, FP rate, exceptions) reviewed on cadence
• Tickets/reports redacted; no exploit kits or unauthorized testing
• Noise → sast-dast-tooling-usage; lifecycle gates → secure-sdlc-checklist; fixes → code-quality-standards

Rules

• Triage before SLA panic — raw scanner severity is a hypothesis.
• Every open High+ has an owner and due date; silence is not acceptance.
• Exceptions expire; compensations are temporary unless re-approved.
• One root cause → one primary ticket; do not game SLAs by splitting.
• Org/compliance deadlines always win over example day counts here.