Introduction

Previously, deploying applications was as simple as hosting them on a server or a single workstation. We relied on solutions such as Apache and IIS, mostly resolving issues or patching vulnerabilities via updates and hotfixes 🧪. However, things have changed dramatically since 2010—14 years ago—when organizations started to move from traditional VPS installations to cloud-based solutions. This change obviously enhanced security and operational efficiency, but it has also introduced additional challenges and vulnerabilities.

Today, the deployment process is more structured and sophisticated. We're no longer merely delivering applications; we need to understand their precise requirements, the versions in use, and all of their dependencies. This move has made our work more formal and hard, as administering new apps necessitates an extensive knowledge of their architecture and context.

Table of Contents

• Introduction
• Why Container Security Matter?
• What is Trivy?
• Setting Up Trivy in GitHub Actions
• Best Practices
• Code
• Conclusion

Why Container Security Matter?

Just like an NPM package is created every second, I could argue that CVEs emerge just as quickly—maybe not in a second, but certainly fast. These vulnerabilities emerge to help us identify risks and resolve them before they escalate into serious problems.

A CVE (Common Vulnerabilities and Exposures) is a list of publicly known security vulnerabilities that exist in software or hardware. Each CVE has a unique ID and specifies a specific vulnerability, allowing businesses to discover and address security vulnerabilities before they are exploited.

This table contains a variety of significant software that has had notable CVEs:

As you can see, the various components of the programs you develop or use as services frequently have a large number of known vulnerabilities. This makes it essential to frequently check for updates and ensure that your services and applications are patched as soon as possible. Failure to do so could result in major problems, particularly when essential applications are in production and adding value to your business. Without regular maintenance, you risk an unexpected failure 💥 that could disrupt operations at any moment.

Fortunately, CVE fixes have significantly improved from 2024 to 2025. It’s clear that both organizations and individual developers are increasingly focused on resolving vulnerabilities, aiming to reduce risk and ensure smoother operations. This progress allows for more ☕ coffee time without worrying about critical security gaps. We can only hope that this positive trend continues as we move forward.

What is Trivy?

In terms of security, Trivy offers an effective solution for checking your container images on a regular basis for vulnerabilities. However, as self-hosted applications gain popularity, there is a growing trend of exposing ports for communication via HTTP, UDP, TCP, gRPC, and other protocols, providing interaction with both internal and external systems. This change adds new complexity to securing not only container images but also communication links between services. So exploits became common, turning this into an acknowledged vulnerability.

Trivy also monitors your IaC for missing setups, which might lead to vulnerabilities. For example, a Kubernetes deployment with unchecked container capabilities can be vulnerable to exploits.

Trivy, developed by Aqua Security, is a popular open-source vulnerability scanner designed for modern DevSecOps workflows. Its standout qualities — speed, simplicity, and comprehensive coverage — make it a preferred choice among developers and security professionals alike.

⚡ Fast scanning.

Trivy is designed for performance. It runs rapid scans by caching results locally and utilizing little system resources. This makes it appropriate not only for CI/CD pipelines, but also for local development environments where developers want rapid feedback.

• Low latency: Initial scans download vulnerability databases; subsequent scans are nearly instant.
• Optimized for CI/CD: Integrates easily with GitHub Actions, GitLab CI, Jenkins, and other tools.

🧩 Simple to use.

One of Trivy's most significant advantages is its ease of use, from installation to execution.
A single binary requires no complex setup. Simply install and start.
Straightforward CLI: A developer-friendly interface that does not require security knowledge.
Quick onboarding: Teams can begin scanning in minutes.

trivy image nginx:latest

# or with docker

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy image nginx:latest

🔐 Comprehensive Scanning Capabilities

Trivy isn't only for container images. It supports a wide range of targets, making it an adaptable tool for safeguarding infrastructure and applications from beginning to finish.

• Container Images (Docker, Podman)
• Operating System Packages (Debian, Alpine, etc.)
• Infrastructure as Code (IaC) (Terraform, Kubernetes manifests, Helm)
• Source Code Repositories
• SBOM (Software Bill of Materials) support
• Git repositories (local or remote)

With Trivy, you can detect:

• CVEs (Common Vulnerabilities and Exposures)
• Misconfigurations
• Secrets (API keys, tokens)
• License compliance issues

🔄 Shift Left Friendly

Trivy enables teams to take a "shift-left" security approach, detecting risks early in the development process before they reach production. This results in fewer surprises and less security debt.

📦 Example Use Cases

• Scan a Docker image for known vulnerabilities
• Audit a Kubernetes YAML file for insecure defaults
• Validate Terraform infrastructure for misconfigurations
• Check for exposed secrets in your Git repo

In short, Trivy offers a uniform toolkit for scanning across the software lifecycle, delivering useful information at a minimal overhead. Whether you're developing microservices or managing cloud-native infrastructure, Trivy keeps your stack secure without slowing you down.

Setting Up Trivy in GitHub Actions

Let's create a CI pipeline that uses GitHub Actions to run Trivy on each contribution. This allows us to detect and avoid important security issues before they reach production.

In a fast-paced development environment, it's tempting to become excited about releasing new features — but it's also crucial to remember that insecure code can harm the business, users, and your team. So, take responsibility for your code's security: avoid older or unmaintained packages, don't introduce untrusted dependencies, and always think before installing.

Security is not simple, but it is your responsibility, and I believe in you. Let's create safer software one commit at a time.

Here's a GitHub Actions workflow to execute Trivy on any pushed commit:

name: Trivy Scan

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  fs-scan:
    runs-on: ubuntu-latest
    name: Run Trivy Filesystem Scan
    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Run Trivy vulnerability scanner in fs mode
      uses: aquasecurity/trivy-action@master
      with:
        scan-type: 'fs'
        scan-ref: '.'
        trivy-config: trivy/trivy.yaml
        severity: 'HIGH,CRITICAL'
        exit-code: 2

  image-scan:
    runs-on: ubuntu-latest
    name: Run Trivy Image Scan
    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Build Docker image
      run: docker build -f Containerfile -t local-nginx .

    - name: Run Trivy vulnerability scanner in image mode
      uses: aquasecurity/trivy-action@master
      with:
        scan-type: 'image'
        image-ref: 'local-nginx'
        trivy-config: trivy/trivy.yaml
        severity: 'HIGH,CRITICAL'
        exit-code: 2

  config-scan:
    runs-on: ubuntu-latest
    name: Run Trivy Config Scan
    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Run Trivy vulnerability scanner in config mode
      uses: aquasecurity/trivy-action@master
      with:
        scan-type: 'config'
        scan-ref: '.'
        trivy-config: trivy/trivy.yaml
        severity: 'HIGH,CRITICAL'
        exit-code: 2

As you can see, I utilized three scanning methods: fs to scan the local file system directory and image to scan a custom container image that was created and made available locally and config to scan IaC.

The Trivy file settings (trivy.yaml):

severity:
  - HIGH
  - CRITICAL

ignore-unfixed: true

ignore:
  vulnerabilities:
    - CVE-2021-12345
    - CVE-2022-67890

output:
  format: table

scan:
  config:
    enabled: true
  secrets:
    enabled: true
  iac:
    enabled: true
    policies:
      - terraform
      - kubernetes

timeout: 5m

• severity: Defines the severity levels that your scan will treat as vulnerabilities.
• ignore: This section allows you to specify which CVEs to bypass during the scan, but use with caution as it’s at your own risk.
• scan: Here, you can choose the type of scans to run, such as scanning Docker images, file systems, or Infrastructure as Code (IaC).

🧪 Output (trimmed)

Here, we have the outputs from Trivy for three different types of scans: container image, file system, and Infrastructure as Code (IaC).

I created files with vulnerabilities to demonstrate Trivy in action. These include insecure IaC, secrets exposed in a file, and a vulnerable container image.

Report Summary

┌─────────────────────────────┬────────┬─────────────────┬─────────┐
│           Target            │  Type  │ Vulnerabilities │ Secrets │
├─────────────────────────────┼────────┼─────────────────┼─────────┤
│ nginx:latest (debian 12.10) │ debian │       154       │    -    │
└─────────────────────────────┴────────┴─────────────────┴─────────┘

Legend:
- '-': Not scanned
- '0': Clean (no security findings detected)


nginx:latest (debian 12.10)

Total: 154 (UNKNOWN: 2, LOW: 99, MEDIUM: 39, HIGH: 12, CRITICAL: 2)


┌────────────────────┬─────────────────────┬──────────┬──────────────┬─────────────────────────┬───────────────┬──────────────────────────────────────────────────────────────┐
│      Library       │    Vulnerability    │ Severity │    Status    │    Installed Version    │ Fixed Version │                            Title                             │
├────────────────────┼─────────────────────┼──────────┼──────────────┼─────────────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ apt                │ CVE-2011-3374       │ LOW      │ affected     │ 2.6.1                   │               │ It was found that apt-key in apt, all versions, do not       │
│                    │                     │          │              │                         │               │ correctly...                                                 │
│                    │                     │          │              │                         │               │ https://avd.aquasec.com/nvd/cve-2011-3374                    │

AVD-AWS-0132 (HIGH): Bucket does not encrypt data with a customer managed key.
═══════════════════════════════════════════════════════════════════
Encryption using AWS keys provides protection for your S3 buckets. To increase control of the encryption and manage factors like rotation use customer managed keys.


See https://avd.aquasec.com/misconfig/avd-aws-0132
───────────────────────────────────────────────────────────────────
 trivy/example.tf:24-31
───────────────────────────────────────────────────────────────────
  24 ┌ resource "aws_s3_bucket" "insecure_bucket" {
  25 │   bucket = "insecure-bucket-example"
  26 │   acl    = "public-read"
  27 │
  28 │   versioning {
  29 │     enabled = false
  30 │   }
  31 └ }

AVD-KSV-0014 (HIGH): Container 'vulnerable-container' of Deployment 'vulnerable-deployment' should set 'securityContext.readOnlyRootFilesystem' to true
═══════════════════════════════════════════════════════════════════
An immutable root file system prevents applications from writing to their local disk. This can limit intrusions, as attackers will not be able to tamper with the file system or write foreign executables to disk.

See https://avd.aquasec.com/misconfig/ksv014
───────────────────────────────────────────────────────────────────
 trivy/deployment.yml:18-34
───────────────────────────────────────────────────────────────────
  18 ┌       - name: vulnerable-container
  19 │         image: nginx:1.16
  20 │         ports:
  21 │         - containerPort: 80
  22 │         env:
  23 │         - name: SECRET_KEY
  24 │           value: "hardcoded-secret"
  25 │         securityContext:
  26 └           privileged: true

HIGH: AsymmetricPrivateKey (private-key)
════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Asymmetric Private Key
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 trivy/secrets.txt:10
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   8     "project_id": "fake-project-id",
   9     "private_key_id": "fakeprivatekeyid12345",
  10 [   "private_key": "-----BEGIN PRIVATE KEY-----******************-----END PRIVATE KEY-----\n",
  11     "client_email": "[email protected]",
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Trust me 🤝, you can check the results directly in the GitHub CI:

Best Practices

Frequent scans

Running vulnerability scans on each commit is secure, but it may be costly 💸🤑💰, particularly in businesses with hundreds of developers and several projects. Your CI pipeline may struggle under the pressure, affecting performance and developer productivity.

Instead, consider examining your CI phases and selecting the appropriate time to execute security tests. As your procedures evolve, you can use common, "pre-scanned" base images across projects to reduce scanning time while retaining a high level of security.

Prioritize high and critical vulnerabilities

Make sure your workflow fails when critical or high-severity vulnerabilities are discovered. Detecting vulnerabilities early is critical, but not every vulnerability should halt development. According to your risk tolerance and business environment, low or medium-level vulnerabilities may be acceptable, but don't wait until they reach high levels to pay attention 🧐.

It is critical to determine which severity levels are undesirable in production and which are manageable. This decision should be part of an ongoing, open discussion between 👨‍💻development and 👮security teams to find the correct balance between safety and productivity.

Regular updates

Keeping your base images and dependencies up to date is one of the best strategies to reduce vulnerabilities. Scanning helps you detect worries early on, but it's also critical to understand why those vulnerabilities exist in your stack.

For example, if your application depends on too many libraries, you run the danger of importing deprecated or unmaintained packages. In ecosystems like NPM, a single dependent might pull in dozens of transitive dependencies, sometimes for functionality you rarely use. In such circumstances, consider creating lightweight alternatives or including only what you require.

Be cautious of using trendy frameworks or libraries simply because they're popular. If they stop receiving updates or support from the community, you could be left with a security risk 🧠.

Don't make decisions based solely on emotions ❤️; remember the wisdom of this Bible verse:

Jeremiah 17:9 (NIV):
"The heart is deceitful above all things and beyond cure. Who can understand it?"

While solutions like Trivy promote a culture of regular updates, it is your obligation to ensure that your team avoids unmaintained or obsolete dependencies - prevention begins with smart choices.

Outputs on CI

Depending on your CI volume and team size, reviewing scan results immediately within the CI pipeline might be confusing and hard to read, making it 🥴 challenging for developers to identify and resolve vulnerabilities effectively.

To optimize this process, Trivy reports can be integrated with other tools, such as SonarQube, to improve the user experience, consolidate security issues, and provide more explicit solutions. This integration helps you organize vulnerability data, streamline issue tracking, and enable developers to focus on fixing significant problems rather than becoming lost in a sea of scan results.

Code

💡 Feel free to clone this repository, which contains related files:

GitHub - williampsena/ci-repices: This repository contains useful Github Actions CI recipes

This repository contains useful Github Actions CI recipes - williampsena/ci-repices

GitHubwilliampsena

Conclusion

That’s all for today, folks! I hope you enjoyed this quick dive into Trivy.
My goal was to raise awareness about security and share practical tools and best practices that you can apply in your daily development workflow.

Stay safe, write secure code, never stop learning and keep your kernel 🧠 up to date!

References

• CVE Details
• CVSS base score
• Trivy