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:
-
In container.yaml: Add non-blocking Trivy scan
- Scan on every build
- Upload results as artifacts
- Display warnings in PR comments
- Continue workflow execution
-
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/trivy-action@0.33.1
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/trivy-action@0.33.1
with:
scan-type: 'image'
image-ref: 'torrust-tracker:${{ matrix.target }}'
format: 'table'
severity: 'HIGH,CRITICAL'
exit-code: '1' # Fail on vulnerabilities
Benefits
- Continuous Security Monitoring: Catch new CVEs as they're published
- Early Detection: Identify issues during development, not in production
- Resource Efficient: Containerfile changes trigger checks, avoiding unnecessary scans
- Flexible Enforcement: Non-blocking for development velocity, strict for releases
- Compliance: Demonstrates proactive security posture
Success Criteria
Additional Considerations
-
Matrix strategy: The container workflow already builds both debug and release targets, so Trivy scans will automatically cover both
-
Cache Trivy database to speed up scans
-
Consider adding MEDIUM severity to weekly audits for broader coverage
-
Add security workflow badge to README.md:
[](https://github.com/torrust/torrust-tracker/actions/workflows/security-audit.yaml)
Related
References
cc @da2ce7
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.yamlthat:Benefits:
Option 2: Periodic Security Audit Workflow
Create a new
.github/workflows/security-audit.yamlthat:Containerfilechangesworkflow_dispatchBenefits:
Recommended Implementation (Hybrid Approach)
Combine both options:
In
container.yaml: Add non-blocking Trivy scanNew
security-audit.yaml: Strict periodic scanningImplementation Details
Container Workflow Changes
Add Trivy scanning step to the existing test job that already builds both debug and release targets:
Note: The existing workflow already uses a matrix strategy to build both
debugandreleasetargets, so this will automatically scan both.Security Audit Workflow
Benefits
Success Criteria
Additional Considerations
Matrix strategy: The container workflow already builds both debug and release targets, so Trivy scans will automatically cover both
Cache Trivy database to speed up scans
Consider adding MEDIUM severity to weekly audits for broader coverage
Add security workflow badge to README.md:
Related
References
cc @da2ce7