A .trivyignore file lets you tell Trivy to stop complaining about specific vulnerabilities or misconfigurations it finds, even when they’re genuinely present.
Let’s see Trivy in action, but with a twist. Imagine you’ve scanned an image and found a vulnerability, say CVE-2023-1234. You know this specific vulnerability is present, but your security team has deemed it acceptable for now due to mitigating factors or a planned remediation. You don’t want Trivy to flag it every single time you scan.
Here’s a sample trivy.yaml (or .trivyignore) file:
# Trivy configuration for ignoring specific findings
# Target: The artifact or component to which the ignore rule applies.
# Type: The type of finding (e.g., vulnerability, config, secret, IaC).
# Target and Type are mandatory.
# Ignore CVE-2023-1234 in the 'alpine' package manager for any package
- target: "alpine"
type: "vulnerability"
vulnerabilityIDs:
- "CVE-2023-1234"
# Ignore a specific misconfiguration rule in a Kubernetes manifest
- target: "kubernetes"
type: "config"
misconfiguration:
id: "KSA001" # Example ID for a Kubernetes misconfiguration rule
# Ignore a specific secret pattern across all targets
- target: "*"
type: "secret"
secret:
ruleIDs:
- "generic-api-key"
# Ignore a specific IaC issue in a Terraform file
- target: "terraform"
type: "iac"
iac:
type: "terraform"
resource: "aws_s3_bucket"
field: "acl"
value: "public-read"
And here’s how you’d run Trivy with this configuration:
trivy image --config .trivyignore my-vulnerable-app:latest
If my-vulnerable-app:latest contained CVE-2023-1234 in its Alpine packages, or the KSA001 misconfiguration, or a generic API key secret, Trivy would now scan them and not report those specific findings.
The core problem .trivyignore solves is managing the signal-to-noise ratio in vulnerability scanning. In real-world environments, not every detected issue is an immediate, actionable risk. You might have a dependency with a known vulnerability that’s not exposed, or a configuration that deviates from best practices but is intentionally allowed for a specific business reason. Without a way to suppress these, your security teams can get overwhelmed with alerts, leading to "alert fatigue" where critical issues are missed.
Internally, when Trivy scans, it compares its findings against the rules defined in the .trivyignore file. If a finding matches a rule’s target, type, and any specified IDs or patterns, it’s filtered out before being presented in the report. The target can be broad (like * for all targets, or specific package managers like alpine, debian, rpm) or more granular (like specific file paths or resource types). The type is crucial, distinguishing between vulnerability, config (misconfiguration), secret, and iac (Infrastructure as Code).
The power of .trivyignore lies in its specificity. You can ignore an entire CVE across all packages, or just that CVE within a specific package manager, or even just a specific misconfiguration rule by its ID. For secrets and IaC, you can target specific resource types, fields, or values. This fine-grained control is essential for creating a practical and sustainable security scanning workflow.
One aspect often overlooked is the interaction between different ignore rules and the order in which they might be processed (though Trivy’s matching is generally additive, meaning multiple rules can apply). For instance, you might have a broad ignore rule for a CVE, but then a more specific rule that re-enables reporting for that same CVE under certain conditions, though this is a less common pattern. More practically, you can use different ignore rules for different types of findings within the same .trivyignore file, allowing you to tailor your suppression strategy comprehensively.
After you’ve successfully suppressed known acceptable findings with .trivyignore, the next challenge will be understanding how to integrate these scans into your CI/CD pipeline to enforce policies and prevent vulnerable images from being deployed.