libxml library vulnerabilities in nginx alpine image

[ehteshamkhaja]

Hi Team.

We are seeing libx library vulnerabilties while scanning the nginx:alpine images , could you please help us with fixing the vulnerabilties.

For the time being, we are adding a upgrade command in the docker file to update the libx related packages.

Please find the attachments for reference.

[oxpa]

Dear @ehteshamkhaja,

As with several other similar issues (see here: https://github.com/nginxinc/docker-nginx/issues?q=is%3Aissue%20vulnerability) we don't really build images. Images are built by docker-library.

The issue will get automatically fixed as images are rebuilt.

[jdreesen]

When will the images be rebuilt?

[yosifkit]

Background:

Tags in the [official-images] library file[s] are only built through an update to that library file [—i.e., their build context like Dockerfile changed—] or as a result of its base image being updated (ie, an image FROM debian:bookworm would be rebuilt when debian:bookworm is built).

-https://github.com/docker-library/official-images/tree/2f086314307c04e1de77f0a515f20671e60d40bb#library-definition-files

Official Images FAQ:

Though not every CVE is removed from the images, we take CVEs seriously and try to ensure that images contain the most up-to-date packages available within a reasonable time frame

- https://github.com/docker-library/faq/tree/0ad5fd60288109c875a54a37f6581b2deaa836db#why-does-my-security-scanner-show-that-an-image-has-cves

To ensure that we don't push contentless image changes, we rely on periodic base image updates.

We strive to publish updated images at least monthly for Debian. We also rebuild earlier if there is a critical security need. Many Official Images are maintained by the community or their respective upstream projects, like Ubuntu, Alpine, and Oracle Linux, and are subject to their own maintenance schedule.

- from the same FAQ link

So, there is no specific timeline of when they'll be rebuilt since they are only built/rebuilt when either their build context changes, or their base image is updated. In this case, either the nginx Dockerfiles or build context would need a meaningful change (not just injected noise like a date or the specific version of this fix) early enough in the Dockerfile to bust (docker/buildkit) build cache or Alpine would need to do a release (they don't really create new images without a release) and give the updated build contexts to Docker Official Images.

Related comment: docker-library/official-images#16225 (comment)