You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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:
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
The text was updated successfully, but these errors were encountered: