Resolve critical and high vulnerabilities in node:lts-bookworm base image
rn185124 opened this issue · comments
Description
We would like to use node:lts-bookworm as base image for our container and we noticed vulnerabilities there.
It would be great if you resolve them.
Reproduce
Expected behavior
No critical and high vulnerabilities are expected in node:lts-bookworm base image.
You could switch to using the bookworm-slim variant which don't have those. You could even use multistage build to use the non slim for building and copying the result into the slim variant.
FWIW; looks like those vulnerabilities are not yet patched by upstream debian, so there's not packages available there yet;
Hi @LaurentGoderre , We have tried multistage build and used bookworm-slim for final result. However, we have seen vulnerabilities in JFrog XRay platform.
I am attaching those vulnerabilities here and targeting to resolve critical and high vulnerabilities.
Could you please help on this to proceed further?
Docker_launchpad_version-1.21.0-3023-PR.769_rn185124@ncr.com_2024-06-07.zip
The official images use the upstream (debian in this case) packages; if there's vulnerabilities in those packages, those would have to be fixed by the debian maintainers and packagers; once updates are available in the debian package repositories, those will be included in the next build of the official images, but before that, there's not much that the maintainers of the official images can do.
I would recommend checking the status for those CVEs in debian's security tracker; here's the links to the "critical" ones from your report, but the pattern is the same for the other ones;
- https://security-tracker.debian.org/tracker/CVE-2023-5841
- https://security-tracker.debian.org/tracker/CVE-2023-45853
- https://security-tracker.debian.org/tracker/CVE-2023-6879
- https://security-tracker.debian.org/tracker/CVE-2023-0645
Note that some of those will have an issue linked in their issue tracker, which may contain more information about the current status (which may in some cases be that the debian maintainers decided to reject the CVE or decided not to patch).
See also the "Notes" field at the bottom of each of those links, which contains comments from the Debian Security Team (usually about why it's not fixed / not believed to be an issue worth fixing urgently).
[bookworm] - openexr <no-dsa> (Minor issue)
[bullseye] - openexr <not-affected> (Only affects 3.x)
[buster] - openexr <not-affected> (Only affects 3.x)
("no-dsa" is effectively "wontfix" but leaving the door open for another debian maintainer to fix it if they believe they can do so within the constraints of debian stable)
Again, please read https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-cves