Trivy and Aqua Enterprise vulnerability scan results critical and high

[shalberd]

What steps did you take and what happened:
Took e.g. a recent R Studio image build. Got the following vulnerabilities findings. I realize not all are valid in all contexts, i.e. Docker one regarding Docker with Auth .... but some could be fixed easily, e.g. upgrading setuptools along with pip and wheel ...

e.g. in an R Studio image based on quay.io/sclorg/python-39-c9s:c9s which itself seems to be based on https://github.com/sclorg/s2i-python-container/blob/master/3.9/Dockerfile.c9s#L3

What did you expect to happen:
No critical vulnerabilities and as little as possible high ones.

Anything else you would like to add:
how about e.g.

setuptools 75.6.0
wheel 0.45.1
pip 24.3.1

at level python

and Docker 25.0.6 at base image level

The docker vulnerability CVE-2024-41110 seems to be part of /opt/app-root/bin/oc

oc version
Client Version: 4.17.6

https://github.com/openshift/oc/blob/master/go.mod#L19

Environment:

• OpenDatahub Version: (please check the operator version)
• Workbench: (all, data-science, etc)
• Workbench Version: (2023.1, etc)
• Specific tool: (jupyterlab, rstudio server, code-server, elyra-pipelines,etc)
• Notebook-Controller Version: (please check the image version in notebook-controller deployment)

Logs/Screenshots

[jiridanek]

Duplicate of https://issues.redhat.com/browse/RHOAIENG-10350, kind of

• RHOAIENG-10350 feat(Dockerfiles): switch from s2i python images to plain ubi/c9s bases #641

[shalberd]

Regarding that oc-related docker golang vulnerability, posted a question directly at oc

openshift/oc#1950

[jiridanek]

I saw that discussed somewhere. Yeah, as they are telling you on your ticket, govulncheck scan that analyzes reachability would tell that the vulnerable code is not called, and so the vulnerability got downgraded from critical to something fairly down on the list. https://www.redhat.com/en/blog/red-hats-open-approach-vulnerability-management