Vulnerability Ignore Policy

Intermediate

Define strict standards for .trivyignore entries — every ignored CVE must have documented justification, a review date, and approval from a security-responsible team member.

File Patterns

**/.trivyignore**/trivy*

This rule applies to files matching the patterns above.

Rule Content

rule-content.md

# Vulnerability Ignore Policy

## Rule
Every entry in .trivyignore MUST include: the CVE ID, a justification comment, a review date, and the name of the person who approved the exception.

## Format
```
# CVE-YYYY-NNNNN: <brief description>
# Justification: <why this is acceptable>
# Mitigations: <what compensating controls exist>
# Approved by: <name>
# Review date: YYYY-MM-DD
CVE-YYYY-NNNNN
```

## Examples

### Good
```
# CVE-2023-44487: HTTP/2 Rapid Reset DDoS vulnerability
# Justification: Mitigated at load balancer level with rate limiting
# Mitigations: Cloudflare WAF rule deployed, HTTP/2 disabled on internal services
# Approved by: Alice Chen (Security Lead)
# Review date: 2026-06-01
CVE-2023-44487

# CVE-2024-0001: OpenSSL buffer overflow in deprecated API
# Justification: Our code does not use the affected API (EVP_DecryptUpdate)
# Mitigations: Static analysis confirms no usage; monitored via grep in CI
# Approved by: Bob Smith (Platform Team)
# Review date: 2026-04-15
CVE-2024-0001
```

### Bad
```
# No explanation
CVE-2023-44487

# Lazy justification
# "not important"
CVE-2024-0001
```

## Review Process
1. When a .trivyignore entry reaches its review date, re-evaluate:
   - Is a fix now available? → Remove from ignore, update dependency
   - Is the risk still mitigated? → Extend review date by 90 days max
   - Has the threat landscape changed? → Reassess with security team
2. Run monthly audits of .trivyignore to catch expired entries

## Anti-Patterns
- Blank .trivyignore entries without any context
- Review dates more than 6 months in the future
- Copying .trivyignore from other projects without evaluation
- Ignoring entire severity levels instead of specific CVEs
- One person approving their own ignore entries

FAQ

Discussion

Loading comments...

# Vulnerability Ignore Policy ## Rule Every entry in .trivyignore MUST include: the CVE ID, a justification comment, a review date, and the name of the person who approved the exception. ## Format ``` # CVE-YYYY-NNNNN: <brief description> # Justification: <why this is acceptable> # Mitigations: <what compensating controls exist> # Approved by: <name> # Review date: YYYY-MM-DD CVE-YYYY-NNNNN ``` ## Examples ### Good ``` # CVE-2023-44487: HTTP/2 Rapid Reset DDoS vulnerability # Justification: Mitigated at load balancer level with rate limiting # Mitigations: Cloudflare WAF rule deployed, HTTP/2 disabled on internal services # Approved by: Alice Chen (Security Lead) # Review date: 2026-06-01 CVE-2023-44487 # CVE-2024-0001: OpenSSL buffer overflow in deprecated API # Justification: Our code does not use the affected API (EVP_DecryptUpdate) # Mitigations: Static analysis confirms no usage; monitored via grep in CI # Approved by: Bob Smith (Platform Team) # Review date: 2026-04-15 CVE-2024-0001 ``` ### Bad ``` # No explanation CVE-2023-44487 # Lazy justification # "not important" CVE-2024-0001 ``` ## Review Process 1. When a .trivyignore entry reaches its review date, re-evaluate: - Is a fix now available? → Remove from ignore, update dependency - Is the risk still mitigated? → Extend review date by 90 days max - Has the threat landscape changed? → Reassess with security team 2. Run monthly audits of .trivyignore to catch expired entries ## Anti-Patterns - Blank .trivyignore entries without any context - Review dates more than 6 months in the future - Copying .trivyignore from other projects without evaluation - Ignoring entire severity levels instead of specific CVEs - One person approving their own ignore entries