Trivy’s compliance scanning isn’t just about finding vulnerabilities; it’s a way to systematically audit your cloud-native artifacts against industry-specific regulatory frameworks.
Let’s see Trivy in action, scanning a sample container image for PCI-DSS compliance.
trivy compliance --framework cis-kubernetes,pci-dss \
--output compliance.json \
ghcr.io/aquasecurity/trivy:0.48.3
This command tells Trivy to check the ghcr.io/aquasecurity/trivy:0.48.3 image against both CIS Kubernetes benchmarks and the PCI-DSS requirements. The results, detailing which controls pass or fail and why, will be saved in compliance.json.
Compliance scanning in Trivy works by mapping known vulnerabilities and misconfigurations to specific requirements within a given framework. For PCI-DSS, this means Trivy checks if your container image, Kubernetes cluster, or IaC configurations adhere to controls like:
- Requirement 1.2.1: Maintain an inventory of network connections.
- Requirement 3.4.1: Encrypt transmission of cardholder data across open, public networks.
- Requirement 6.4.1: Protect cardholder data from unauthorized access by using strong cryptography.
When you run a scan, Trivy consults its internal vulnerability database, which is constantly updated. This database includes not only CVEs but also specific checks derived from regulatory standards. For each control within a framework (like PCI-DSS), Trivy attempts to verify its implementation based on the artifacts it’s scanning. If it finds a vulnerability that violates a control, or a configuration setting that doesn’t meet a requirement, it flags it as a failure.
Consider the PCI-DSS requirement for protecting cardholder data. Trivy might flag an image if it contains sensitive data in plain text within its filesystem, or if it uses outdated, insecure cryptographic libraries. For Kubernetes, it might flag a deployment that doesn’t enforce network policies, or a pod that runs with excessive privileges.
The power of Trivy’s compliance scanning lies in its ability to translate complex regulatory language into actionable technical findings. Instead of manually poring over hundreds of pages of compliance documentation, you get a focused report pinpointing exactly where your systems fall short. This significantly accelerates the audit preparation process and helps maintain continuous compliance.
The compliance subcommand is versatile. You can scan container images, Kubernetes cluster configurations, Terraform, CloudFormation, and other Infrastructure as Code (IaC) files. This holistic approach allows you to assess compliance risks across your entire cloud-native stack, from the base image to the deployed infrastructure.
Trivy’s compliance engine uses a declarative approach to define checks. Each rule within a framework is essentially a query against the scanned artifact. For example, a PCI-DSS check might look for specific package versions known to be vulnerable to data interception, or it might verify that certain Kubernetes security contexts are correctly configured. The results are presented with a clear pass/fail status, severity, and a description of the control and the detected issue.
When you specify multiple frameworks like cis-kubernetes,pci-dss, Trivy performs all checks for both frameworks in a single pass. This is incredibly efficient, allowing you to get a broad security and compliance posture report simultaneously. The output can be directed to various formats, including JSON, which is ideal for programmatic processing and integration into CI/CD pipelines.
A common misconception is that compliance scanning is a one-time event. In reality, compliance is an ongoing process. Trivy enables continuous compliance by allowing you to integrate these scans into your development and deployment workflows. Regularly scanning your images and infrastructure ensures that new vulnerabilities or misconfigurations don’t creep in, keeping you audit-ready at all times.
The policy option with Trivy allows you to define custom compliance rules using Rego, the policy language of Open Policy Agent (OPA). This is crucial for organizations with unique compliance requirements or internal security standards that go beyond standard frameworks. You can write policies to enforce specific image build practices, restrict the use of certain base images, or ensure that all deployed services meet internal security baselines.
The next step after achieving compliance with one framework is often integrating custom policies to enforce internal security standards.