This moves the dependency scope of all JMH dependencies to test. This classifies them more accurately as test dependencies, which automatically excludes them from Trivy output.
$ ../trivy/main repo .
2024-03-05T14:03:21.104+0800 INFO Vulnerability scanning is enabled
2024-03-05T14:03:21.104+0800 INFO Secret scanning is enabled
2024-03-05T14:03:21.104+0800 INFO If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2024-03-05T14:03:21.104+0800 INFO Please see also https://aquasecurity.github.io/trivy/dev/docs/scanner/secret/#recommendation for faster secret detection
2024-03-05T14:05:38.862+0800 INFO Number of language-specific files: 66
2024-03-05T14:05:38.862+0800 INFO Detecting pom vulnerabilities...
maven-shade-plugin doesn't really like this setup, despite having a shadeTestJar flag, I was unable to get any configuration to work which included dependencies. The easier path was to declare a maven assembly for what is a generic test jar (including dependencies), and then use the assembly plugin instead of shade. This exact setup can be copy/pasta'd to any of our other projects.
At the end of the day, the same jar as before is created, so instructions are the same. The main con is that that jar is bigger as it also includes default test deps like assertj. However, I feel trying to be precise on this is a cure worse than the disease as few if any use this thing anyway.
This moves the dependency scope of all JMH dependencies to test. This classifies them more accurately as test dependencies, which automatically excludes them from Trivy output.
Following https://github.com/aquasecurity/trivy/pull/6213, we have a completely clean run, so no more complaints about old spring etc.
maven-shade-plugin doesn't really like this setup, despite having a
shadeTestJarflag, I was unable to get any configuration to work which included dependencies. The easier path was to declare a maven assembly for what is a generic test jar (including dependencies), and then use the assembly plugin instead of shade. This exact setup can be copy/pasta'd to any of our other projects.At the end of the day, the same jar as before is created, so instructions are the same. The main con is that that jar is bigger as it also includes default test deps like assertj. However, I feel trying to be precise on this is a cure worse than the disease as few if any use this thing anyway.