Deal with vulnerabilities shown in Dockerhub

[carminevassallo]

Dear team,

we noticed the presence of several high-severity vulnerabilities raised on our official SonarQube image tags. We have internal processes and tools to assess and review possible vulnerabilities and we would like to know how to best align all these internal processes with what is shown in Dockerhub asap. Two initial questions:

• how can we deal with the vulnerabilities raised on Dockerhub and justify/mark them as harmless alerts?
• is it a possibility to disable the scan and link to our tooling if people are interested in knowing more about any true vulnerabilities for SonarQube?

I hope this is the right channel to discuss this :)

[grooverdan]

Good question. I asked for the same thing on the feedback link to the Google form on docker hub (right, top of vulnerabilities when you go into a vulnerability).

Also https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck would significantly reduce the amount of false positives there.

Interim: could update https://github.com/docker-library/docs/tree/master/sonarqube with a reference to the internal assessments done.

[cdupuis]

@carminevassallo, thanks for raising this issue. I think this is a good place to discuss this.

We are working on allowing publishers of images, including publishers of Docker Official Images, to attest that certain vulnerabilities are not exploitable within the context of their software/image. We are exploring various options to provide such information; one of the options is Vulnerability Exploitability Exchange spec.

In that context it would be great if we could get access to your assessment about which CVEs your team has reviewed and deemed to be not exploitable. Could you share a pointer to such a report?

While I can't commit on a timeline for this kind of feature to be available, I can assure you that we have heard this request frequently from our customers. Which is why we prioritised this on the roadmap for Docker Scout. Thanks again.

[cdupuis]

Good question. I asked for the same thing on the feedback link to the Google form on docker hub (right, top of vulnerabilities when you go into a vulnerability).

Also https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck would significantly reduce the amount of false positives there.

Interim: could update https://github.com/docker-library/docs/tree/master/sonarqube with a reference to the internal assessments done.

@grooverdan , Yes indeed. Support for govulncheck and other call tree/execution path analysis tools is something which we'll use to mark CVEs as not exploitable. This is part of the larger work on VEX.

Out of curiosity given SonarQube doesn't use Go, in the context of which image are you asking for govulncheck support?

[grooverdan]

@grooverdan , Yes indeed. Support for govulncheck and other call tree/execution path analysis tools is something which we'll use to mark CVEs as not exploitable. This is part of the larger work on VEX.

Out of curiosity given SonarQube doesn't use Go, in the context of which image are you asking for govulncheck support?

It was mariadb that I maintain, and the gosu program is the https://github.com/tianon/gosu/ by @tianon. Based on this one executable would bring quite a few official and non-official images. Its false detection accounts for 3C and 37H vulnerabilities.

I haven't read VEX in detail but it certainly has the right scope. Provided a decent interface for contributions exist I look forwards to seeing how it goes.

Hopefully this can be complimented by SBOM in the OCI standards to facilitate duplicate work, but still provide the option of override by a packager to say, included by not used (#MariaDB/mariadb-docker/issues/469).

[carminevassallo]

We are working on allowing publishers of images, including publishers of Docker Official Images, to attest that certain vulnerabilities are not exploitable within the context of their software/image.

Thanks for exploring ways to do that, @cdupuis :) In the meanwhile, what can we do from a vendor perspective? It is quite bad to be associated with vulnerabilities that don't affect our product. Is it a possibility that the vulnerability feature gets disabled before DockerHub allows publishers to assess them?

In that context it would be great if we could get access to your assessment about which CVEs your team has reviewed and deemed to be not exploitable.

Unfortunately, this is not publicly available yet. Making it public and referencing it on our DockerHub page (as @grooverdan suggests) could also just mitigate the problem if we can't disable the vulnerability scan performed by DockerHub. Users will likely focus on the vulnerability scan embedded in DockerHub rather than checking our external page.

[carminevassallo]

Hi @cdupuis, any updates on this topic? :)

[carminevassallo]

Hi @cdupuis, sorry for pinging you again on this. Did you get any updates? Furthermore, do you think that joining this program can help with moving the topic forward?

[whalelines]

The general availability of Docker Scout was recently announced. Support for VEX was not part of the initial feature set but is still on the roadmap. We are currently prioritizing various feature requests and will provide a more detailed timeline when it becomes available.

[trymeouteh]

Not sure if any of these issues are related to docker running with root.

Would like to see the docker images not require root which will allow them to work with other container engines like podman. https://github.com/docker-library/official-images/issues/16043

[grooverdan]

Not sure if any of these issues are related to docker running with root.

no.

Would like to see the docker images not require root which will allow them to work with other container engines like podman. #16043

Podman and docker both have extensive rootless support via kernel uid maps so even default USER=root official images work with podman (e.g. mariadb that I maintain).

[trymeouteh]

Podman and docker both have extensive rootless support via kernel uid maps so even default USER=root official images work with podman (e.g. mariadb that I maintain).

I am unable to get a simple web server setup in podman with these official docker images. These are my compose files for each basic web server. Works with docker and docker compose without any issues, but I get the following issue when I connect to localhost:8080 in my browser when using podman with podman compose.

httpd (apache)

version: '3'
services:
  apache:
    image: docker.io/httpd
    container_name: apache
    volumes:
      - ./website:/usr/local/apache2/htdocs/
    ports:
      - 8080:80

Forbidden You don't have permission to access this resource.

php:apache

version: '3'
services:
    php-apache:
        image: docker.io/php:8.3.0-apache
        container_name: php-apache
        volumes:
            - ./website:/var/www/html/
        ports:
            - "8080:80"

Forbidden You don't have permission to access this resource.Server unable to read htaccess file, denying access to be safe

Apache/2.4.57 (Debian) Server at localhost Port 8080

nginx

version: '3'
services:
    nginx:
        image: docker.io/nginx:1.17
        container_name: nginx
        volumes:
            - ./website:/var/www/html
            - ./nginx:/etc/nginx/conf.d/
        ports:
            - "8080:80"

403 Forbidden nginx/1.17.10

nginx + php:fpm

version: '3'
services:
    nginx:
        image: docker.io/nginx:1.17
        container_name: nginx
        volumes:
            - ./website:/var/www/html
            - ./nginx:/etc/nginx/conf.d/
        ports:
            - "8080:80"
        depends_on:
            - php
        links:
            - php
    php:
        image: docker.io/php:7.2-fpm
        container_name: php
        volumes:
            - ./website:/var/www/html
            - ./php:/usr/local/etc/php/php.ini

Cannot get nginx container to run, therefore cannot connect to localhost:8080

[tianon]

You would probably have very similar issues/errors if you were using rootless Docker because the permissions of the directory from the host that you're bind-mounting into the container likely do not allow the rootless-shifted users inside the containers to access them.