Been asked to edit this with more details so here is a summary of the problem. The trivy scanner is failing in the github pipeline only and not locally. It says it is failing because of rexml 3.28 which is not present in my repositories gems. I do have rexml but it is 3.3+ only. I am concluding that it must be scanning different instances of the container but will need some guidance about how to find those old cached containers in github.
My repository has an ongoing issue where the trivy vulnerability action is failing in my pipeline. This is making it difficult to sort through future dependency updates. It is a ruby on rails project, below is the error:
┌─────────────────────────────┬────────────────┬──────────┬────────┬───────────────────┬───────────────┬────────────────────────────────────────────┐
│ Library │ Vulnerability │ Severity │ Status │ Installed Version │ Fixed Version │ Title │
├─────────────────────────────┼────────────────┼──────────┼────────┼───────────────────┼───────────────┼────────────────────────────────────────────┤
│ rexml (rexml-3.2.8.gemspec) │ CVE-2024-49761 │ HIGH │ fixed │ 3.2.8 │ >= 3.3.9 │ rexml: REXML ReDoS vulnerability │
│ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2024-49761 │
└─────────────────────────────┴────────────────┴──────────┴────────┴───────────────────┴───────────────┴────────────────────────────────────────────┘
My repository has been updated to use
gem 'rexml', '>= 3.4.0'
and as far as I can see there is no mention of 3.2.8 in my gemfile.lock. When I run the trivy vulnerability scanner locally on the same branch, no vulnerability is detected.
Rubocop 1.64.1 does include rexml (>= 3.2.5, < 4.0)
but I don't know if that should matter as it should just use one we have installed?
I ran gem list | grep rexml
which returned rexml (3.4.0, 3.3.9)
At this point I am wondering about using a VEX (new territory for me) to silence the error but I'd rather get to the bottom of it. What could cause the github actions to basically insist on this error? I am a bit of a beginner with this sort of thing, so i'm wondering if there could be a cached image it is scanning. My trivy workflow file is below if you're interested:
---
# ------------------------------------------------------------------------------
# https://github.com/aquasecurity/trivy
# https://github.com/aquasecurity/trivy-action#inputs
#
name: OS Security
on:
pull_request:
paths:
- Dockerfile
- Gemfile
- Gemfile.lock
- package.json
- yarn.lock
permissions:
packages: write
pull-requests: write
env:
DOCKER_IMAGE: ghcr.io/dfe-digital/early-years-foundation-recovery
jobs:
build:
name: Build and validate Docker image
runs-on: ubuntu-latest
steps:
# Checkout the repository to the GitHub Actions runner
- name: Checkout Code
uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}
# Create and boot Docker image builder
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
with:
version: v0.9.1
# Login to the container registry
- name: Login to Github Container Registry
uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.repository_owner }}
password: ${{ secrets.GITHUB_TOKEN }}
# Build and push image
- name: Build and push Docker image
uses: docker/build-push-action@v6
with:
target: app
context: .
push: true
build-args: |
BUILDKIT_INLINE_CACHE=1
SHA=${{ github.event.pull_request.head.sha }}
cache-from: |
${{ env.DOCKER_IMAGE }}:${{ github.event.pull_request.head.sha }}
tags: |
${{ env.DOCKER_IMAGE }}:${{ github.event.pull_request.head.sha }}
# Scan image
-
name: Run Trivy vulnerability scanner
uses: aquasecurity/trivy-action@0.28.0
with:
image-ref: ${{ env.DOCKER_IMAGE }}:${{ github.event.pull_request.head.sha }}
format: table
exit-code: 1
ignore-unfixed: true
scanners: vuln
vuln-type: os,library
severity: CRITICAL,HIGH
version: "v0.57.1"
I am unable to figure out why its finding rexml 3.28 or if its scanning the wrong image.
But I am confident that this is not a vulnerability that can really be exploited for us so I used a file called .trivyignore
which is stored at the root. You simply include the CVE number and it will ignore the error.