According to the Anchore report, it can be fixed with an upgrade:
HIGH Vulnerability found in os package type (dpkg) - libssl1.1 (fixed in: 1.1.1d-0+deb10u8)(CVE-2022-0778 - CVE-2022-0778)
Thanks @trusty. You may want to also check with Anchore because I noted that NIST reports Undergoing Reanalysis currently on this potential vulnerability. I am following through on this end with our security team. In the future, if you have a potential security issue, please refer to liquibase/SECURITY.md at master · liquibase/liquibase · GitHub where you will find our Responsible Disclosure Policy.
@trusty That vulnerability seems to be more on libssl than within liquibase itself. Are you installing a deb package of liquibase? Or what liquibase artifact are you installing that your scanning is finding that vulnerability?
@nvoxland,
I upgraded the liquibase artifact to 4.9.1.
The vulnerabilities do indeed seem to originate from the kernel packages - I have had to modify the image quite a bit already to satisfy Anchore (see below). As @ktaggart suggested, I will take another look at Anchore to determine if I should more aggressively ignore their flagged vulns…
FROM liquibase/liquibase:4.9.1
…
CVE-2022-24407
RUN apt update
CVE-2018-25032
RUN apt-get install -y zlib1g
RUN apt-get install -y libsasl2-2
OK, thanks. We just extend our docker image from openjdk:11-jre-slim-buster which has it’s own update process. We don’t try to mange what comes on that base image.
The jcc and h2 drivers are added by us, but we ship h2 version 2.1.210 not the 1.4.200 version listed. I’m not sure why Anchorage would be finding that. Is it somehow getting an older liquibase image?
Hi Nathan,
Thanks for the response.
And apologies for the misleading code snippet.
My script is a bit out-of-date and should be updated to reference the latest jars - they were obviously added when using a prior version of liquibase.
I take your point about not managing the openjdk - I’ll take up my beef with them. Also, the more I think about this, the less inclined I am to see this as a truly high vulnerability, since this script is a short lived process running inside a container with no access to the outside world…