SlipItIn/.github/skills/security-specialist/references/severity-policy.md

# Severity Policy

Practical decision criteria for assigning severity to security findings. Apply this policy consistently — do not assign severity based on gut feeling.

---

## Severity Levels

### Critical

The vulnerability allows an attacker to fully compromise the system, its data, or its users with minimal effort and no special access.

**Assign critical when:**
- Remote code execution (RCE) is achievable
- Authentication can be bypassed entirely, granting full access
- PII, credentials, or payment data is directly exposed or exfiltrable
- Supply chain compromise: malicious dependency, tampered build artifact, or poisoned CI pipeline
- Pre-authentication exploitation — no account or privileges required

**Examples:**
- Unauthenticated endpoint that returns all user records with passwords
- Deserialization vulnerability allowing arbitrary command execution
- Hardcoded production credentials (database, payment processor, admin tokens)
- Dependency with an actively exploited RCE CVE

---

### High

The vulnerability enables significant damage but requires slightly more effort or minimal access (low-privilege account).

**Assign high when:**
- SQL injection or XSS that enables session hijacking or credential theft
- Privilege escalation from normal user to admin
- SSRF that reaches internal services, metadata endpoints, or private networks
- Significant data exposure (not full breach, but sensitive records accessible)
- Authentication flaws that weaken but don't fully bypass access control
- File upload allowing server-side execution

**Examples:**
- Stored XSS in a comment field that steals admin session cookies
- IDOR allowing any authenticated user to read other users' private data
- SSRF reaching cloud metadata endpoint (`169.254.169.254`)
- JWT signature not verified, allowing role escalation

---

### Medium

The vulnerability has real security impact but is limited in scope, requires chaining, or affects non-critical paths.

**Assign medium when:**
- Stored XSS that cannot access session tokens (HttpOnly cookies in place)
- Information disclosure: stack traces, internal file paths, software versions
- Missing security headers (CSP, X-Frame-Options) on sensitive pages
- Weak cryptography in non-critical paths (e.g., MD5 for non-password hashing)
- CSRF on state-changing but non-critical actions
- Open redirect usable for phishing

**Examples:**
- Error page leaks full stack trace including internal IP addresses
- No CSP header on pages that render user-generated content
- Password reset token generated with insufficient entropy (but short-lived)
- CSRF on profile display name change (not on password/email change)

---

### Low

The issue has minimal direct security impact but represents a gap in defense-in-depth or hygiene.

**Assign low when:**
- Verbose error messages revealing framework version or minor internals
- Missing rate limiting on non-critical endpoints
- Minor misconfigurations with no direct exploit path
- Dependencies with CVEs that have no practical exploit in this context
- Cookie without `Secure` flag in a development-only path
- Directory listing enabled but exposing only public assets

**Examples:**
- Server responds with `X-Powered-By: Express` header
- No rate limit on the "forgot password" endpoint (but tokens are single-use and short-lived)
- Dependency has a CVE for a function the project never calls
- CORS allows `*` on a public read-only API with no auth

---

### Info

Not a vulnerability. An observation, best-practice recommendation, or note for future hardening.

**Assign info when:**
- Best practice not followed but no exploitable condition exists
- Code quality issue with security implications (e.g., error handling inconsistency)
- Suggestion for future improvement (e.g., "consider adding Subresource Integrity")
- Informational notes about architecture or trust boundaries

**Examples:**
- Recommend enabling HSTS preload (HSTS is already present, just not preloaded)
- Suggest adding `integrity` attributes to CDN script tags
- Note that logging does not capture failed authentication attempts

---

## Dynamic Baseline

Severity não é absoluta — é relativa ao que a aplicação é e ao que comparáveis aceitam.

### Como Calibrar

1. **Identifique o comparável** em Phase 1 (CMS → outros CMSes, API gateway → outros API gateways, novel app → sem comparável)
2. **Verifique se o pattern existe no comparável** — se sim e foi explorado, é finding MAIS FORTE. Se nunca explorado em anos de produção, entenda por quê.
3. **Ajuste severity pela distância do padrão aceito** — se TODO app nessa categoria tem o mesmo pattern e ninguém considera vulnerability, não reporte como HIGH.
4. **Não use baseline para DESCARTAR** — use para calibrar. Um pattern perigoso é perigoso mesmo se o comparável também o tem.

### Distinction: HIGH vs MEDIUM para Business Logic

- **HIGH**: O finding derrota um security boundary explícito. User performa ação que o sistema explicitamente gate atrás de higher role, e a ação tem consequências reais.
- **MEDIUM**: Bypass com consequências reais mas limitadas. Requer auth, impacto confinado a dados do atacante, ou conditions uncommon.

---

## Don't Overcall

Common mistakes that inflate severity beyond what the evidence supports:

| Mistake | Why it's wrong | Correct severity |
|---------|---------------|-----------------|
| Reflected XSS behind authentication marked as critical | Requires social engineering of an already-authenticated user; session cookies are HttpOnly | Medium (or High if cookies are accessible) |
| Missing HSTS marked as critical | HSTS absence alone doesn't enable exploitation; it's defense-in-depth | Low (or Medium if the site handles sensitive auth flows over HTTP) |
| Dependency CVE with no reachable code path marked as high | If the vulnerable function is never called, there's no exploit | Low or Info |
| Missing rate limiting on login marked as high | Only matters if there's no account lockout, no CAPTCHA, and passwords are weak | Low (escalate to Medium if no compensating controls exist) |
| Information disclosure of software version marked as high | Version numbers alone don't enable attack; they help an attacker enumerate but require a corresponding vulnerability | Low |
| Self-XSS (user can only attack themselves) marked as medium | No impact on other users; no realistic attack scenario | Info |
| CORS misconfiguration on a public API with no auth | If the API is intentionally public and has no user context, CORS is irrelevant | Info |
| **Multiple dependency CVEs listed at face value without project context** | If 9 CVEs are listed but only 1 is exploitable due to missing preconditions, reporting "9 CRITICAL CVEs" is misleading and erodes trust | Analyze each individually, assign per-CVE real severity |

**The rule:** Severity reflects *demonstrated impact*, not *theoretical worst case*. If you can't articulate the realistic attack scenario and its consequences in 2 sentences, you're probably overcalling.

### CVE Cross-Reference Protocol (Mandatory)

Before assigning severity to any dependency CVE:

1. **Read the advisory** — identify the exact precondition (which function, which feature, which config)
2. **Grep the codebase** — does the project use that function/feature? Cite the evidence (file:line or "0 results")
3. **Check the environment** — does prod have the infrastructure the CVE requires? (CDN, multi-user, Windows, etc.)
4. **DAST validate** — did the probe confirm exploitability in localhost? In production?
5. **Assign real severity** — based on what you proved, not what the advisory says generically

A bulk "upgrade all deps" recommendation is fine. But the *severity* must reflect this project, not all projects.

---

## Severity Decision Flowchart

1. **Can an unauthenticated attacker achieve RCE, full data breach, or complete auth bypass?** → Critical
2. **Can a low-privilege attacker steal sessions, escalate privileges, or access significant sensitive data?** → High
3. **Is there real but limited impact (scoped data leak, partial XSS, missing hardening on sensitive pages)?** → Medium
4. **Is it a hygiene gap with no direct exploit path in this context?** → Low
5. **Is it purely advisory with no current exploitability?** → Info

When in doubt between two levels, ask: "Can I demonstrate concrete harm to a user or the system?" If yes, go with the higher level. If not, go lower.