Trivy scan shows old version of jar

[AlanTT1]

Discussed in #1129

^{Originally posted by AlanTT1 July 19, 2021}
Hi! I am running Trivy on a Java war file.

Firstly, when I started the scan using this command:

trivy fs -s HIGH,CRITICAL -f template -t "@/media/sf_vmsharedfolder/html.tpl" -o fse-trivy-report.html mydir

there is an warning message:

`
2021-07-19T12:39:49.372+0800 INFO Detected OS: unknown

2021-07-19T12:39:49.377+0800 INFO Number of PL dependency files: 1

2021-07-19T12:39:49.377+0800 INFO Detecting jar vulnerabilities...

2021-07-19T12:39:49.463+0800 WARN maven constraint error ([10.5-alpha0,10.5.3.0_1]): failed to new comparer: 2 errors occurred:

* improper constraint: [10.5-alpha0,10.5.3.0_1]
* 
* improper requirements: []

`

After this, when I look at the output, it shows an old jar file com.fasterxml.jackson.core:jackson-databind and the installed version is 2.3.3. I have checked the war file by opening it up, there is no version 2.3.3 in jackson-core.

This was the old version of jackson-core and I have already upgraded it to version 2.12.3.

I have tried trivy with --reset and -c to clear cache but it still gives the same result.

Please help. Thanks.

[AlanTT1]

Please help. Thanks.

[AndreyLevchenko]

Hi
I don't think the warning related with jackson-core vulnerability detected. Can you add a bit more output for the vulnerability found?

Thanks

[AlanTT1]

Hi Andrey,

Thank you for your response.

What Trivy has found is Installed version is 2.3.3, fixed version is 2.9.4, 2.8.11

But I have opened up my war file. The jackson version are 2.12.3.jars

Is there something I am missing out?
Is there a way to list out which directory or which composite jar Trivy has found the installed version as 2.3.3?

Please help. Thanks in advance.

[ayush42]

@AlanTT1 @AndreyLevchenko
I am also facing a similar issue.

My java jar file has 4.1.65.Final version of netty-codec-http and netty-codec-http2 dependencies.
This jar file is copied in the Docker image at the time of building the docker image.
But the Trivy scan shows me medium level vulnerability of the above dependencies with a version of 4.1.52.Final.

Command -> trivy image --exit-code 0 --ignore-unfixed --severity LOW,MEDIUM <DOCKER_IMAGE__NAME_TAG>
Trivy Version -> 0.19.2

I can skip the jar file scan with --skip-dirs flag. But I don't want to do that.

Dependency-tree :

Trivy logs :

[sospirited]

I am also seeing a similar issue with this.

• We have a project that uses com.fasterxml.jackson.core:jackson-databind, this resolves to version 2.12.2 and is also what gradlew dependencies shows
• The project also has a transitive dependency on ehcache v2.10.6
• ehcache contains a pom.xml inside <ehcache-2.10.6.jar>\rest-management-private-classpath\META-INF\maven\com.fasterxml.jackson.core\jackson-databind\pom.xml which declares the version as 2.9.6

So my jar contents is like this and trivy scan will report I am using jackson-databind version 2.9.6

myJar.jar/
  BOOT-INF/
      - <otherDeps>
      - jackson-databind-2.11.2.jar
  META-INF/
      - maven/
          - com.fasterxml.jackson.core/
              - jackson-databind/
                  - pom.xml (contains 2.9.6) 

[AndreyLevchenko]

Hi guys
Yes dependencies which are included into jar are scanned. But I need to point out the difference between @sospirited and @ayush42 cases. In last case reactor-netty-http has no included dependencies. (I mean jar itself contains no third-party classes - everything required is downloaded by maven on project build) and it gives an option to configure exclusions in project pom. In case of ehcache everything is in jar file, so I would check updates for the lib.

[ayush42]

Hi @AndreyLevchenko
Any updates on this issue will be great to have. Thanks. :)

[vasicvuk]

I can confirm the same issue.

[strainovic]

Me too.

[vasicvuk]

@andriisoldatenko any updates?

[elifarley]

See #1285

[mih-kopylov]

I've faced a similar case.
The dependency tree of my project doesn't have net.minidev:json-smart dependency, but trivy confidently alerted about net.minidev:json-smart:2.3 which is affected with CVE-2021-27568

Java (jar)
==========
Total: 1 (CRITICAL: 1)
+------------------------+------------------+----------+-------------------+---------------+
|        LIBRARY         | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |
+------------------------+------------------+----------+-------------------+---------------+
| net.minidev:json-smart | CVE-2021-27568   | CRITICAL |               2.3 | 2.4.1, 1.3.2  |
+------------------------+------------------+----------+-------------------+---------------+

The jar is a java service based on Spring Boot.

I've unpacked the jar and found a bunch of dependencies in BOOT-INF\lib directory.
There was no json-smart.

I've extracted all the dependencies and found that one of them - com.github.tomakehurst:wiremock-jre8-standalone:2.27.1 - that is a uber jar that contains, surprisingly - net.minidev:json-smart:2.3 which is found by trivy.

[mih-kopylov]

@afdesk yeah, similar, but in my case it was a valid report :)

[Freydal]

Hey I'm coming here after having a similar experience as some of the ones mentioned above after a vulnerability crack down. Thanks Log4j. My first project's culprit was ehcache similar to above. Fighting with that was enough to drive me to open up the hood of trivy. The next repo I used to find a solution by modifying trivy(ultimately go-dep-parser) had a test jar i didn't notice that wasn't scoped as test that had several vulnerabilities.

The feature needed is path information for embedded libraries found through recursion.

go-dep-parser#41 linked here so I thought it may have the most value to trivy users to post this info here.

If you are looking to have a quick-ish work around while waiting on a formal fix I have something fairly simple that can help assuming a little go experience, a development environment and go bin set up.

1. Pull Trivy, then pull go-dep-parser within the trivy directory.
2. Add a replace for go-dep-parser in go.mod for local dependencies.

replace (
	github.com/aquasecurity/go-dep-parser => ./go-dep-parser
)

3. Update go-dep-parser/pkg/java/jar/parse.go#241 (at the time of writing) to leak some info into console. Fix calls of this function within parseArtifact providing the fileName parameter.

func (p properties) library(filename string) types.Library {
   println(fmt.Sprintf("Adding: %s:%s from %s", p.groupID, p.artifactID, filename))
   ...
}

4. make install trivy and make sure you are using the correct binary in go path.

[AndreyLevchenko]

Hi
Latest versions of Trivy return path to affected jars in json format. Here is example:

trivy -q rootfs -f json <directory> | jq ' .Results[].Vulnerabilities[] | {id: .VulnerabilityID, PkgName: .PkgName, Path: .PkgPath}'

note that jq command is used as part of pipeline.

[seanleblancicdtech]

Is this resolved? I'm also getting a false positive for jackson inside of ehcache, based on it finding the pom.xml file deep inside the ehcache jar, but Trivy is (falsely) saying we have vulnerable version of jackson library.

Alternatively, is there a way to turn off reporting of things found in a pom.xml file? (I'm doing image scanning by the way)

[unix-fan]

most probably I'm missing something here,
but what does the maven warning mean and
how do i get rid of it?

WARN maven constraint error ([10.5-alpha0,10.5.3.0_1]): failed to new comparer: 2 errors occurred:
* improper constraint: [10.5-alpha0,10.5.3.0_1]
* improper requirements: []

[mhou1981]

I think I found something interesting. Inside the Trivy documentation, it mentions that it also look into the local cached Maven repository file location under ~/.m2/repository. If I do a full maven build under the project, it picks up the old JAR which is not used in the project nor in the target folder file system. Although we have specifically in maven project to use a newer version, maven will still download the depended version it required and stored in the local cache directory. That is why the older version is showing up in the scan report even if we specifically set a newer version in POM.XML file.

This is what you can try it out.

1. Do a maven clean on the project and also truncate the ~/.m2/repository folder in that order
2. Do a Trivy offline fs scan and show your initial result.
3. Do a full maven clean install
4. Run another Trivy offline fs scan again without truncating the ~/.m2/repository folder.
5. Truncate the ~/.m2/repository folder again
6. Run another Trivy offline fs scan again to see a completely different result.

[mhou1981]

Suggested change from using fs scan to use rootfs scan on maven repository after compilation. trivy rootfs scan will not scan the ~/.m2/repository.

[zangcc]

Hello, I use rootfs to replace the fs parameter to scan, and found that fs has data, but the result of rootfs is empty, my project is maven. Do you know why this is?

Moreover, I can’t even find the partial dependencies scanned by the fs parameter in my code project, and some of them even don’t match the version.

[mhou1981]

Compile the Java project first then run the rootfs scan.

[zangcc]

Hello, I would like to ask where is the java db database file of trivy stored locally on the computer? I plan to skip the update of java-db every time I scan with rootfs