Skip to content

glelarge/trivy-maven-issue

Repository files navigation

Trivy does not manage 2nd level Maven BOM (or BOM inside another BOM)

This repository is to demonstrate these issues on trivy #5748 and go-dep-parser #279.

Context

Context is pretty much common, multiple projects, written in Java, built with Maven, some common jar files used in business applications (web, CLI).

trivy (through its Docker image, currently v0.48) is used to detect vulnerabilities.

In the Maven terminology, a BOM (Bill Of Materials) is a specific kind of POM, read Maven documentation for more details.

Issue

Let's define:

  • a first-level BOM
    • it is a BOM that references direct dependencies
    • ==> well detected by trivy
  • a second-level BOM
    • it is a BOM referenced by another BOM
    • ==> not detected by trivy

Reproduction

Tests are using Camunda 7.17.0 :

This repository contains 3 Maven projects :

  • myproject-bom
    • custom BOM
    • set the Camunda BOM in the <dependencyManagement> section
    • requires mvn install to be installed in the local Maven repository
  • myproject-simple
    • build a simple Jar file
    • set the Camunda BOM in the <dependencyManagement> section
    • ==> the Camunda BOM is used as first-level BOM
    • import the camunda-engine in the <dependencies> section
  • myproject-level2
    • build a simple Jar file
    • set myproject-bom in the <dependencyManagement> section
    • ==> the Camunda BOM is used as second-level BOM
    • import the camunda-engine in the <dependencies> section

The script trivy.sh runs the following operations:

  • install locally the custom BOM : mvn install -f myproject-bom/pom.xml
  • build myproject-simple and myproject-level2 to download dependencies locally :
    • mvn package -f myproject-simple/pom.xml
    • mvn package -f myproject-level2/pom.xml
  • run the trivy tool through its Docker image on both projects myproject-simple and myproject-level2.

Results

In myproject-simple, vulnerabilities are found because Camunda is set as first-level BOM.

In myproject-level2, vulnerabilities are not found because Camunda BOM is set as second-level BOM.

Check the full results from the output of trivy.sh script.

Workaround

It is possible to get trivy working on myproject-level2 by flattening all dependencies, but requires multiple operations on CI, that's not ideal...

# Build the effective pom to flatten all dependencies
mvn help:effective-pom -Doutput=pom_flatten.xml -Dverbose=true

# Backup the original pom.xml
mv pom.xml pom_origin.xml

# Use the flatten pom.xml
mv pom_flatten.xml pom.xml

# Run the trivy scan
docker run -ti --rm \
     -v /var/run/docker.sock:/var/run/docker.sock \
     -v ~/.cache:/root/.cache \
     -v ${PWD}:/root/myproject \
     -v ~/.m2:/root/.m2 \
     --network=host aquasec/trivy fs --debug --timeout 30m /root/myproject

# Restore the original pom.xml
mv pom_origin.xml pom.xml

About

Maven projects to show issues on trivy scan

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published