Skip to content

Implement Automated Security Scanning with Trivy in CI/CD Pipeline #1630

@josecelano

Description

@josecelano

Summary

Add automated security scanning using Trivy to the CI/CD pipeline to continuously monitor Docker images for vulnerabilities and prevent security regressions.

Context

Following the resolution of security vulnerabilities in #1628 by upgrading to Debian 13, we need to ensure ongoing security monitoring to catch vulnerabilities early and prevent them from reaching production.

Proposed Solution

Implement a hybrid approach combining both workflow integration and periodic scanning:

Option 1: Non-blocking Scan in Container Workflow

Add Trivy scanning to .github/workflows/container.yaml that:

  • Runs on every push, PR, and release
  • Provides immediate feedback during development
  • Non-blocking: Generates warnings but doesn't fail the workflow
  • Creates security scan artifacts for review

Benefits:

  • Developers get immediate visibility into security issues
  • Fast feedback loop during development
  • Doesn't block urgent releases

Option 2: Periodic Security Audit Workflow

Create a new .github/workflows/security-audit.yaml that:

  • Runs weekly (e.g., every Monday)
  • Triggers on Containerfile changes
  • Can be manually triggered via workflow_dispatch
  • Blocking: Fails if HIGH or CRITICAL vulnerabilities detected

Benefits:

  • Regular security audits catch new CVEs
  • Containerfile changes immediately trigger security checks
  • Strict enforcement without blocking daily development

Recommended Implementation (Hybrid Approach)

Combine both options:

  1. In container.yaml: Add non-blocking Trivy scan

    • Scan on every build
    • Upload results as artifacts
    • Display warnings in PR comments
    • Continue workflow execution
  2. New security-audit.yaml: Strict periodic scanning

    • Weekly scheduled run
    • Triggered by Containerfile changes
    • Fail on HIGH/CRITICAL vulnerabilities

Implementation Details

Container Workflow Changes

Add Trivy scanning step to the existing test job that already builds both debug and release targets:

- name: Run Trivy Security Scan
  uses: aquasecurity/[email protected]
  with:
    scan-type: 'image'
    image-ref: 'torrust-tracker:local'
    format: 'sarif'
    output: 'trivy-results-${{ matrix.target }}.sarif'
    severity: 'HIGH,CRITICAL'
    exit-code: '0'  # Non-blocking

- name: Upload Trivy Results to GitHub Security
  uses: github/codeql-action/upload-sarif@v3
  if: always()
  with:
    sarif_file: 'trivy-results-${{ matrix.target }}.sarif'
    category: 'container-${{ matrix.target }}'

Note: The existing workflow already uses a matrix strategy to build both debug and release targets, so this will automatically scan both.

Security Audit Workflow

name: Security Audit

on:
  schedule:
    - cron: '0 9 * * 1'  # Every Monday at 9 AM UTC
  push:
    paths:
      - 'Containerfile'
      - '.github/workflows/security-audit.yaml'
  workflow_dispatch:

jobs:
  security-scan:
    name: Security Scan
    runs-on: ubuntu-latest
    
    strategy:
      matrix:
        target: [debug, release]
    
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - name: Setup Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Build Image
        uses: docker/build-push-action@v6
        with:
          file: ./Containerfile
          push: false
          load: true
          target: ${{ matrix.target }}
          tags: torrust-tracker:${{ matrix.target }}
          cache-from: type=gha
          cache-to: type=gha

      - name: Run Trivy Security Scan (Strict)
        uses: aquasecurity/[email protected]
        with:
          scan-type: 'image'
          image-ref: 'torrust-tracker:${{ matrix.target }}'
          format: 'table'
          severity: 'HIGH,CRITICAL'
          exit-code: '1'  # Fail on vulnerabilities

Benefits

  1. Continuous Security Monitoring: Catch new CVEs as they're published
  2. Early Detection: Identify issues during development, not in production
  3. Resource Efficient: Containerfile changes trigger checks, avoiding unnecessary scans
  4. Flexible Enforcement: Non-blocking for development velocity, strict for releases
  5. Compliance: Demonstrates proactive security posture

Success Criteria

  • Trivy scanning added to container.yaml (non-blocking)
  • New security-audit.yaml workflow created (blocking)
  • Weekly scheduled scans configured
  • Containerfile changes trigger security checks
  • Security scan results uploaded as artifacts
  • SARIF integration with GitHub Security tab
  • Add security-audit workflow badge to README.md
  • Documentation updated with security scanning process

Additional Considerations

  1. Matrix strategy: The container workflow already builds both debug and release targets, so Trivy scans will automatically cover both

  2. Cache Trivy database to speed up scans

  3. Consider adding MEDIUM severity to weekly audits for broader coverage

  4. Add security workflow badge to README.md:

    [![Security Audit](https://github.com/torrust/torrust-tracker/actions/workflows/security-audit.yaml/badge.svg)](https://github.com/torrust/torrust-tracker/actions/workflows/security-audit.yaml)

Related

References


cc @da2ce7

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions