Failed Sysdig Scan

Support
#1

I recently had my application scanned and some issues were found with these files. Devops wont deploy my application until this is resolved.
How can I get these things updated?
Many Thanks !!

Package Path Package Version Vulnerability
pkgdb 1.3.5-7.el8 CVE-2022-3515
batik-anim-1.12.jar 1.12 VULNDB-231859
batik-anim-1.12.jar 1.12 VULNDB-304117
batik-anim-1.12.jar 1.12 VULNDB-304118
batik-awt-util-1.12.jar 1.12 VULNDB-231859
batik-awt-util-1.12.jar 1.12 VULNDB-304117
batik-awt-util-1.12.jar 1.12 VULNDB-304118
batik-bridge-1.12.jar 1.12 VULNDB-231859
batik-bridge-1.12.jar 1.12 VULNDB-304117
batik-bridge-1.12.jar 1.12 VULNDB-304118
batik-constants-1.12.jar 1.12 VULNDB-231859
batik-constants-1.12.jar 1.12 VULNDB-304117
batik-constants-1.12.jar 1.12 VULNDB-304118
batik-css-1.12.jar 1.12 VULNDB-231859
batik-css-1.12.jar 1.12 VULNDB-304117
batik-css-1.12.jar 1.12 VULNDB-304118
batik-dom-1.12.jar 1.12 VULNDB-231859
batik-dom-1.12.jar 1.12 VULNDB-304117
batik-dom-1.12.jar 1.12 VULNDB-304118
batik-ext-1.12.jar 1.12 VULNDB-231859
batik-ext-1.12.jar 1.12 VULNDB-304117
batik-ext-1.12.jar 1.12 VULNDB-304118
batik-extension-1.12.jar 1.12 VULNDB-231859
batik-extension-1.12.jar 1.12 VULNDB-304117
batik-extension-1.12.jar 1.12 VULNDB-304118
batik-gvt-1.12.jar 1.12 VULNDB-231859
batik-gvt-1.12.jar 1.12 VULNDB-304117
batik-gvt-1.12.jar 1.12 VULNDB-304118
batik-i18n-1.12.jar 1.12 VULNDB-231859
batik-i18n-1.12.jar 1.12 VULNDB-304117
batik-i18n-1.12.jar 1.12 VULNDB-304118
batik-parser-1.12.jar 1.12 VULNDB-231859
batik-parser-1.12.jar 1.12 VULNDB-304117
batik-parser-1.12.jar 1.12 VULNDB-304118
batik-script-1.12.jar 1.12 VULNDB-231859
batik-script-1.12.jar 1.12 VULNDB-304117
batik-script-1.12.jar 1.12 VULNDB-304118
batik-svg-dom-1.12.jar 1.12 VULNDB-231859
batik-svg-dom-1.12.jar 1.12 VULNDB-304117
batik-svg-dom-1.12.jar 1.12 VULNDB-304118
batik-svggen-1.12.jar 1.12 VULNDB-231859
batik-svggen-1.12.jar 1.12 VULNDB-304117
batik-svggen-1.12.jar 1.12 VULNDB-304118
batik-transcoder-1.12.jar 1.12 VULNDB-231859
batik-transcoder-1.12.jar 1.12 VULNDB-304117
batik-transcoder-1.12.jar 1.12 VULNDB-304118
batik-util-1.12.jar 1.12 VULNDB-231859
batik-util-1.12.jar 1.12 VULNDB-304117
batik-util-1.12.jar 1.12 VULNDB-304118
batik-xml-1.12.jar 1.12 VULNDB-231859
batik-xml-1.12.jar 1.12 VULNDB-304117
batik-xml-1.12.jar 1.12 VULNDB-304118
commons-text-1.9.jar 1.9 VULNDB-303405
pdfbox-2.0.16.jar 2.0.16 VULNDB-259179
pdfbox-2.0.16.jar 2.0.16 VULNDB-259180
snakeyaml-1.31.jar 1.31 VULNDB-299958
tomcat-embed-core-9.0.65.jar 9.0.65 VULNDB-303299
tomcat-embed-core-9.0.65.jar 9.0.65 VULNDB-303298
tomcat-embed-core-9.0.65.jar 9.0.65 VULNDB-303300
tomcat-embed-el-9.0.65.jar 9.0.65 VULNDB-303299
tomcat-embed-el-9.0.65.jar 9.0.65 VULNDB-303298
tomcat-embed-el-9.0.65.jar 9.0.65 VULNDB-303300
tomcat-embed-websocket-9.0.65.jar 9.0.65 VULNDB-303299
tomcat-embed-websocket-9.0.65.jar 9.0.65 VULNDB-303298
tomcat-embed-websocket-9.0.65.jar 9.0.65 VULNDB-303300
xmlgraphics-commons-2.4.jar 2.4 VULNDB-250372
/root/.sdkman/candidates/gradle/7.5/lib/plugins/jackson-databind-2.13.3.jar 2.13.3 VULNDB-302422
#3

Hi,

You need to analyze the source of these dependecnies.

Execute the gradlew dependencies task in your project and you’ll get the dependencies tree.

In order to add a dependency with a higher version to you project that will override the transitive dependency that came from somewhere else you may try to add the dependency explicitly, e.g.

implementation 'org.apache.xmlgraphics:fop:2.8'

Just keep in mind that replacing dependency version can cause backward compatibility problem, so you’ll need to test affected parts of your project carefully.

We’ll take a look, some of these dependencies come from the framework and we may update them on our side, but anyway you may always try raising the dependency version in the project.

#4

Thank you so much for your response !!!
I will update these dependencies but what about the embedded tomcat?

#5

It comes from Spring Boot dependencies. Try updating to the latest Jmix version. It depends on a newer Spring Boot that in turn has Tomcat 9.0.69 instead of 9.0.65. Maybe the 9.0.69 will work for you.

#6

I was able to remove most of the vulnerabilities but the docker image is being flagged by this file
/opt/gradle/gradle-7.6/lib/plugins/jackson-databind-2.13.3.jar
is there anything I can do in the application build.gradle to update this? it seems like replacing this file directly makes gradle to crash. what can I do to resolve this issue?
thank you

Vulnerability Severity Package Package Version Package Type Package Path URL Fix
VULNDB-302422 High jackson-databind 2.13.3 java /opt/gradle/gradle-7.6/lib/plugins/jackson-databind-2.13.3.jar Sysdig Secure 2.13.4

I Did a gradle dependencies and it shows that the Report module uses it
image

even though I have updated it… it still shows up on the gradle plugin installation folder in /opt
Been trying for a few days to get this sysdig scan to pass… please help

#7

This output means that actually v.2.14.1 is used in the application:

image

Are you sure this jackson-databind library is causing the test to fail?

#8

Yes but devops is rejecting my application because if this file
/opt/gradle/gradle-7.6/lib/plugins/jackson-databind-2.13.3.jar
I think its not even on my project. Is this some temp file that gets stored on that directory?
any ideas how to update that file? Is there anything on my jmix app build.gradle i can do?

#9

What is this directory /opt/gradle/gradle-7.6/lib/plugins and how does it relate to your Jmix project? Do you use this gradle inside the docker container somehow?

#10

I believe so… I have very little knowledge on docker. Seems like this is the gradle installation in the container. What plugin is using it. I think changing the file breaks gradle.

#11
  1. Check again how many times does the jackson-databind dependency appear in the output of the ./gradlew dependencies command and what is the effective version for each appearance. It may be that this dependency is resolved with different versions for different configurations, e.g. for compileClasspath and for testCompileClasspath.
  2. Next you’ll need to figure out why do you need Gradle inside the container and what exactly happens inside your container. Just in case, we use gradle 7.5.1 for building projects based on Jmix 1.4.x, not Gradle 7.6 that appears in your classpath.
#12

would uninstalling gradle in that container fix it?
this jenkins thing pulls my sourcecode from github and runs
gradle -build -“repo credentials”
then sysdig scans for vulnerabilites
how would i run the gradle command on a ubutu server just from the sourcecode?

#13

Confirmed that gradle had that file and the scan was rejecting it. I manually updated the file. it had nothing to do with my jmix application.

Thank you for all the help !! very appreciated.