Vendors to deal with vulnerabilties on Docker Hub

[grooverdan]

Tell us about your request

Software Vendors need a way to acknowledge/negative acknowledge vulnerabilities in containers. The existence of a vulnerable software component in a container does not make it exploitable in every container it exists in. Many vulnerabilities require a specific code path or configuration to be exploitable. Its a tough question to answer without deep knowledge about the container and application to determine if a vulnerability is exploitable.

A end user getting a vulnerability notice from Docker Scout or Docker Hub isn't in a position to comprehend the impacts. The software vendor isn't in a position to answer the same question repetitively (if they are asked). The software vendor writing a security information page isn't strongly linked to the red to orange glowing security notices that exist there.

A VEX exchange or similar standard where software vendors can provide a meaningful analysed assessment of specific CVEs as it pertains to their product in a machine readable format such that users can get the right information rather than a generic there is this vulnerable software package in your container.

The data the vendor can offer is:

• Providing an exploit-ability score related to how the vulnerability is exposed in their container
• Providing a invalid/not applicable description and why
• Provide detailed description on what needs to occur (configuration, mode of operation) in the software product for a vulnerability to be expose in their container.
• Provide custom mitigation advice for the CVE

Layered containers can use and override security advice from vendors base image.

ref: docker-library/official-images#14889

Which service(s) is this request for?

Docker Scout, Docker Hub.

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?

As a software vendor, many vulnerabilities of components of a container (packages and other SBOM sources) have no exploit-ability in a container. Users are too scared of the look of security notices to even examine the impacts. A user reading the CVE will infrequently be able to tell how that applies to a container they are using.

Are you currently working around the issue?

Security page - https://github.com/MariaDB/mariadb-docker/blob/master/SECURITY.md, but its so far away technically from where security information is displayed without any hard linkages.

Additional context

ref: docker-library/official-images#14889

[SDwarfs]

TLDR

This summarizes the problem I have as a user of container images very well.

I'm unable to tell, which of the vulnerabilities are to be takes serious, especially if there are many of those in an image (especially found for containers for databases like MySQL, MariaDB, PostgreSQL) and there are no real alternatives.

I definitively want some kind of VEX for Docker Scout!

THIS would reduce lot's of wasted time for users (needing to check security before using them), maintainers (needing to repeatedly answer those questions). And it would prevent people from being too scared to use a software at all. Especially now that in Europe we have the Cyber-Resilience-Act, NIS-2 and the Product Liability Directive, this gets more and more important to become something that is handled time and money efficient!

Long version

A less informed user might ask: Why not just use libraries and version that does not contain known vulnerabilities?

But, having worked on multiple complex and older projects, I know that you cannot just upgrade to the newest version of a library in many cases, without having to rework a major part of your software. And as @grooverdan already said, many vulnerabilities might not be relevant, if the container/software uses the vulnerable libraries/software in a way that mitigates the attach vector (e.g. by (a) never using the vulnerable routines, (b) filtering input data, (c) special configuration that disables vulnerable features, ...). These are totally valid ways to cope with these issues.

As the user of the container, I'm responsible for the service to keep user / company data secure and safe. And in any case of a security breach, I might be asked: Well, why have you used a container with vulnerabilities after all?

When just looking at the numbers of two containers for the same software... for example:
(a) 3 CRITICAL and 55 HIGH severity issues
vs
(b) 2 CRITICAL and 32 HIGH severity issues

I should probably decide for (b) --- But, this might be the wrong decision, if in version (a) the maintainer has taken care of any such vulnerabilities to be effectively mitigated.... and in (b) the maintainer just tried to use software with less vulnerabilities, without taking care about which of them are exploitable.

Without additional information I'm lost.

Having a officially documented statement from the maintainer:

1. which vulnerabilities have been taken care of
2. under which circumstances a vulnerability / attack vector might be exploitable (or is not exploitable)

would allow for:

1. a much better decision making by the container users
2. more secure usage of containers (not enabling features with vulnerabilities when not needed)
3. argue as a developer to the chef/manager/external partner, why I can still safely use the given containers
4. know when I definitively need to upgrade a container or maybe temporarily need to take down a container until a fix is available if there is a critical vulnerability that had not been taken care of and might be discovered after the containers release.

I need this information from the maintainer, closely linked to the CVEs at the same place where they are displayed.

My question is:
NOT: How many vulnerabilities of a certain severity are there?
INSTEAD: How many vulnerabilities are there, that the container maintainer has not taken care of?
AND: Under which circumstances can I still safely use the container?

PS: This is nothing to be found in the container description, as it's always related to a certain Tag / Image.