This repository is to demonstrate these issues on trivy #5748 and go-dep-parser #279.
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.
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
Tests are using Camunda 7.17.0 :
- the BOM provided by Camunda
- the dependency to camunda-engine:7.17.0 that comes with vulnerabilities
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.
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.
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