Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vendors to deal with vulnerabilties on Docker Hub #750

Open
grooverdan opened this issue Nov 28, 2024 · 0 comments
Open

Vendors to deal with vulnerabilties on Docker Hub #750

grooverdan opened this issue Nov 28, 2024 · 0 comments
Assignees
Labels
community_new New idea raised by a community contributor

Comments

@grooverdan
Copy link

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

@grooverdan grooverdan added the community_new New idea raised by a community contributor label Nov 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
community_new New idea raised by a community contributor
Projects
None yet
Development

No branches or pull requests

2 participants