Trivy CI/CD: 5 Steps to Secure Containers in 2026

Securing your software supply chain is non-negotiable in 2026. With the proliferation of containers, ensuring the integrity and security of your container images is a foundational step, not an afterthought. Integrating tools like Trivy into your CI/CD pipeline for continuous container security scanning is how we build trust into our deployments. But how do you actually make that happen effectively?

I’ve been in the trenches for years, watching teams struggle with security bottlenecks. The old way of doing things, where security was a gate at the end of the development cycle, simply doesn’t cut it anymore. We need to shift left, and that means baking security into every stage, especially during automated builds. Trivy has been a standout tool for this, offering a straightforward, fast, and comprehensive scanning solution. I’ve personally overseen its implementation in several large-scale projects, and the results speak for themselves: fewer vulnerabilities reaching production, faster remediation cycles, and a significantly improved security posture.

1. Install Trivy and Understand its Core Commands

Before you can automate anything, you need to get familiar with the tool itself. Trivy is an open-source vulnerability scanner that’s easy to install and use. It supports scanning for OS packages (Alpine, RHEL, CentOS, etc.), application dependencies (Bundler, Composer, npm, yarn, etc.), and IaC (Infrastructure as Code) configurations. For most Linux distributions, you can add its repository and install it using your package manager. For example, on Debian/Ubuntu systems, you’d execute:

sudo apt-get install wget apt-transport-https gnupg lsb-release
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo "deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install trivy

Once installed, the basic command to scan a Docker image is surprisingly simple: trivy image [YOUR_IMAGE_NAME]:[TAG]. This command will pull the specified image, analyze its contents, and report any identified vulnerabilities. I always recommend running this locally first to get a feel for its output and speed. It’s usually blazing fast, which is a huge plus for CI/CD pipelines where every second counts.

Pro Tip: Trivy needs to download its vulnerability database the first time it runs. This can add a few seconds to the initial scan. In CI/CD, consider caching the database or pre-downloading it in your build environment to save time on subsequent runs. You can manually update the database with trivy, download-db-only.

2. Integrate Trivy into Your CI/CD Pipeline Configuration

The real magic happens when Trivy becomes an integral part of your automated build and deployment process. Let’s look at an example using GitHub Actions, a popular choice for CI/CD. The goal is to scan your container image immediately after it’s built and before it’s pushed to a registry or deployed.

Here’s a snippet for a GitHub Actions workflow file (.github/workflows/main.yml):

name: Build and Scan Docker Image on: push: branches:

main
 jobs: build-and-scan: runs-on: ubuntu-latest steps:

name: Checkout code
 uses: actions/checkout@v4 

name: Build Docker image
 run: docker build -t my-app:latest . 

name: Run Trivy vulnerability scan
 uses: aquasecurity/trivy-action@master with: image-ref: 'my-app:latest' format: 'table' exit-code: '1' severity: 'CRITICAL,HIGH' ignore-unfixed: true

In this workflow, after building the my-app:latest image, the aquasecurity/trivy-action@master GitHub Action takes over. Notice the exit-code: '1' setting; this is crucial. It tells Trivy to exit with a non-zero status if any vulnerabilities matching the specified severity are found, effectively failing the build. This is how we enforce security gates. The severity: 'CRITICAL,HIGH' ensures we only fail on the most pressing issues, preventing developers from being overwhelmed by low-priority alerts initially. We can always adjust this threshold later.

Common Mistakes: Many teams make the mistake of running Trivy in a “report only” mode without failing the build. This turns security scanning into a suggestion, not an enforcement. If you’re not failing the build on critical issues, you’re not truly integrating security; you’re just generating more data nobody acts on. Make those exit codes work for you!

3. Configure Trivy for Advanced Scanning and Policy Enforcement

Trivy isn’t just for basic vulnerability scanning. It can also check for misconfigurations in your Dockerfiles, Kubernetes manifests, and other Infrastructure as Code (IaC) files. This is a powerful feature for preventing common security pitfalls before they even become images. To scan your IaC, you’d use trivy config . in your repository.

Furthermore, you can customize Trivy’s behavior with a configuration file (e.g., .trivyignore or command-line flags). For instance, you might want to ignore specific vulnerabilities that you’ve deemed acceptable risks (after a thorough review, of course) or that are known false positives in your environment. You can use the , ignore-vulnerabilities flag or a .trivyignore file to list CVE IDs to be excluded. I recommend being very selective here; ignoring vulnerabilities indiscriminately is a recipe for disaster.

Let’s say you have a custom policy: you want to ensure no image uses a base image older than 6 months or contains certain sensitive environment variables. While Trivy’s native capabilities cover a lot, for truly custom policy enforcement, you might combine it with Open Policy Agent (OPA) and Rego policies. Trivy can output scan results in JSON format (trivy image -f json -o results.json my-app:latest), which can then be fed into an OPA engine for evaluation against your bespoke rules. This is a more advanced setup, but it offers unparalleled flexibility for large organizations with complex compliance requirements.

Pro Tip: Focus on scanning your base images frequently. Many vulnerabilities originate from outdated base images. By ensuring your foundational layers are secure, you reduce the attack surface for your application code. I’ve seen countless times where updating a base image resolved 80% of reported vulnerabilities in an application image.

4. Review and Act on Trivy Scan Results

Getting scan results is only half the battle; acting on them is where the real work begins. Trivy’s output can be verbose, especially for images with many dependencies. You’ll want to prioritize addressing CRITICAL and HIGH severity vulnerabilities first. Look for vulnerabilities that are FIXED, meaning an update is available. These are typically the easiest to resolve by simply updating a package or rebuilding your image with a newer base.

When you encounter a vulnerability, your first step should be to understand its context. Is it in a component that your application actually uses? Is it exploitable in your specific environment? Sometimes, a reported vulnerability might be in a library that’s included but never invoked, or its exploit path might be blocked by other security controls. However, don’t use this as an excuse to ignore everything. Every vulnerability is a potential risk.

Case Study: Last year, I worked with a mid-sized e-commerce company that was struggling with their security posture. Their CI/CD pipelines were fast, but they had no integrated container scanning. After implementing Trivy with a strict policy to fail builds on critical and high vulnerabilities, their initial builds were a mess. We found over 20 critical vulnerabilities in their main application image, mostly due to an outdated Node.js base image and unpatched dependencies. Within two weeks, by systematically updating their base images and addressing reported package vulnerabilities, they reduced their critical and high vulnerability count to zero. This proactive approach saved them an estimated $50,000 in potential incident response costs and significantly boosted their compliance standing, according to an internal audit.

5. Maintain and Evolve Your Container Security Strategy

Container security isn’t a “set it and forget it” task. New vulnerabilities are discovered daily. Your Trivy database needs to be updated regularly, and your policies should evolve with your threat landscape. Regularly review your Trivy configurations and the severity thresholds you’ve set. What might have been acceptable as a “medium” severity issue six months ago could now be considered “high” due to new exploit techniques or increased prevalence.

Consider integrating Trivy’s capabilities beyond just CI/CD. You can use it to scan images already in your registry (e.g., via a nightly cron job) to catch vulnerabilities that emerge after deployment. Tools like Trivy Operator for Kubernetes can even scan images running in your clusters, providing continuous runtime visibility. This multi-layered approach provides the most comprehensive security coverage.

My advice? Treat your security configurations like code. Version control them, review them, and iterate on them. The security landscape is constantly changing, and your defenses must adapt. Don’t fall into the trap of thinking one scan is enough; it’s a continuous process, a marathon, not a sprint. We’re always learning, always adapting, and always striving to build more secure software.

Implementing Trivy in your CI/CD is a powerful step towards a more secure software supply chain, enabling you to detect and remediate vulnerabilities early, reducing risk and fostering a culture of security throughout your development lifecycle.