Describe the bug
Not a bug per-se but a package dependency update request. Our AWS vuln scanning (Wiz.io) is picking up signatures for this CVE from file system builds and package dependencies in our Go apps. Gnomock is using the Docker package to spin up containers I presume and is using a vulnerable version to do so.
gnomock is currently depending on github.com/docker/[email protected]:
|
github.com/docker/docker v26.1.3+incompatible |
Example from our scan tool (app names redacted)
The library github.com/docker/docker version 24.0.5+incompatible was detected in Golang go.mod located at /[Partition=370c33d0]/volumes/buildx_buildkit_builder-ce7c9c28-1446-41b0-9d2f-9e79efe2737e0_state/_data/runc-overlayfs/snapshots/snapshots/23/fs/go/pkg/mod/github.com/xxxxx/[email protected]/go.mod on line 56 and is vulnerable to CVE-2024-41110, which exists in versions >= 24.0.0, < 25.0.6.
This coming in via indirect dependencies. Several of our apps directly leverage the gnomock package or reference a util package of ours that uses it. I have seen both 0.30.0 and 0.31.0 being used in our environment.
The version that fixes the issue is 27.1.1: moby/moby#48223
To Reproduce
Run a vuln scan tool for this CVE on a container of codebase with a dependency on github.com/docker/[email protected] for example.
Expected behavior
Clean vuln scans
Additional context
Add any other context about the problem here.
If you read through the vulnerability and the attack vector - the real world risk is quite low. We have confirmed we not running the authz plugin anywhere and it's no on by default. But security programs being what they are, the scanning tools and security engineers won't rest until these scans go green :-)
Describe the bug
Not a bug per-se but a package dependency update request. Our AWS vuln scanning (Wiz.io) is picking up signatures for this CVE from file system builds and package dependencies in our Go apps. Gnomock is using the Docker package to spin up containers I presume and is using a vulnerable version to do so.
gnomockis currently depending ongithub.com/docker/[email protected]:gnomock/go.mod
Line 11 in b57afd8
Example from our scan tool (app names redacted)
This coming in via indirect dependencies. Several of our apps directly leverage the
gnomockpackage or reference a util package of ours that uses it. I have seen both0.30.0and0.31.0being used in our environment.The version that fixes the issue is 27.1.1: moby/moby#48223
To Reproduce
Run a vuln scan tool for this CVE on a container of codebase with a dependency on
github.com/docker/[email protected]for example.Expected behavior
Clean vuln scans
Additional context
Add any other context about the problem here.
If you read through the vulnerability and the attack vector - the real world risk is quite low. We have confirmed we not running the
authzplugin anywhere and it's no on by default. But security programs being what they are, the scanning tools and security engineers won't rest until these scans go green :-)