Vulnerability Severity Policy

Beginner

Define organizational severity policies for Snyk findings — CRITICAL/HIGH block deployments, MEDIUM tracked in backlog, LOW logged for awareness with clear SLA timelines.

File Patterns

**/.snyk**/package.json**/requirements*.txt

This rule applies to files matching the patterns above.

Rule Content

rule-content.md

# Vulnerability Severity Policy

## Rule
All Snyk findings MUST be triaged according to severity policy. CRITICAL and HIGH vulnerabilities block production deployments until resolved or formally accepted.

## Severity SLA
| Severity | Action | Resolution SLA | CI Gate |
|----------|--------|---------------|---------|
| CRITICAL | Fix immediately, page on-call if in production | 24 hours | Block |
| HIGH | Fix in current sprint | 7 days | Block |
| MEDIUM | Add to backlog, fix within 30 days | 30 days | Warn |
| LOW | Log for awareness, fix opportunistically | 90 days | Pass |

## CI Configuration
```bash
# Block on CRITICAL and HIGH
snyk test --severity-threshold=high

# Monitor with all severities for tracking
snyk monitor
```

## Triage Factors (Beyond Severity)
1. **Snyk Priority Score** — considers exploit maturity and reachability
2. **Fix availability** — is an upgrade or patch available?
3. **Attack surface** — is the vulnerable code reachable from user input?
4. **Compensating controls** — WAF, network segmentation, input validation

## Examples

### Good Triage
```
CVE-2024-0001 (CRITICAL, score 950, exploit in wild)
→ Action: Fix immediately, upgrade dependency
→ Timeline: Same day

CVE-2024-0002 (HIGH, score 400, no known exploit)
→ Action: Schedule for current sprint
→ Timeline: Within 7 days

CVE-2024-0003 (MEDIUM, score 200, test dependency only)
→ Action: Add to backlog
→ Timeline: Within 30 days
```

## Anti-Patterns
- Treating all CRITICALs equally without checking priority score
- Permanently ignoring vulnerabilities without review dates
- Blocking CI on LOW severity (causes alert fatigue)
- Not tracking SLA compliance metrics

FAQ

Discussion

Loading comments...

# Vulnerability Severity Policy ## Rule All Snyk findings MUST be triaged according to severity policy. CRITICAL and HIGH vulnerabilities block production deployments until resolved or formally accepted. ## Severity SLA | Severity | Action | Resolution SLA | CI Gate | |----------|--------|---------------|---------| | CRITICAL | Fix immediately, page on-call if in production | 24 hours | Block | | HIGH | Fix in current sprint | 7 days | Block | | MEDIUM | Add to backlog, fix within 30 days | 30 days | Warn | | LOW | Log for awareness, fix opportunistically | 90 days | Pass | ## CI Configuration ```bash # Block on CRITICAL and HIGH snyk test --severity-threshold=high # Monitor with all severities for tracking snyk monitor ``` ## Triage Factors (Beyond Severity) 1. **Snyk Priority Score** — considers exploit maturity and reachability 2. **Fix availability** — is an upgrade or patch available? 3. **Attack surface** — is the vulnerable code reachable from user input? 4. **Compensating controls** — WAF, network segmentation, input validation ## Examples ### Good Triage ``` CVE-2024-0001 (CRITICAL, score 950, exploit in wild) → Action: Fix immediately, upgrade dependency → Timeline: Same day CVE-2024-0002 (HIGH, score 400, no known exploit) → Action: Schedule for current sprint → Timeline: Within 7 days CVE-2024-0003 (MEDIUM, score 200, test dependency only) → Action: Add to backlog → Timeline: Within 30 days ``` ## Anti-Patterns - Treating all CRITICALs equally without checking priority score - Permanently ignoring vulnerabilities without review dates - Blocking CI on LOW severity (causes alert fatigue) - Not tracking SLA compliance metrics