From a1162e717e901e374da29f1577276743e0b59671 Mon Sep 17 00:00:00 2001 From: Joseph Ferguson Date: Fri, 26 May 2023 14:31:09 -0700 Subject: [PATCH] Add a note related to govulncheck --- README.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index e83113a..8f2fafa 100644 --- a/README.md +++ b/README.md @@ -119,7 +119,7 @@ The "Simple Tags" enable `docker run mongo:4.0-xenial` to "do the right thing" a ### Why does my security scanner show that an image has CVEs? -Though not every CVE is removed from the images, we take CVEs seriously and try to ensure that images contain the most up-to-date packages available within a reasonable time frame. For many of the Official Images, a security scanner, like [Docker Security Scanning](https://docs.docker.com/docker-hub/official_images/#official-image-vulnerability-scanning) or [Clair](https://github.com/coreos/clair) might show CVEs, which can happen for a variety of reasons: +Though not every CVE is removed from the images, we take CVEs seriously and try to ensure that images contain the most up-to-date packages available within a reasonable time frame. For many of the Official Images, a security analyzer, like [Docker Scout](https://docs.docker.com/scout/) or [Clair](https://github.com/coreos/clair) might show CVEs, which can happen for a variety of reasons: - The CVE has not been addressed in that particular image @@ -137,6 +137,10 @@ Though not every CVE is removed from the images, we take CVEs seriously and try e.g., [CVE-2020-8169](https://nvd.nist.gov/vuln/detail/CVE-2020-8169) shows that `curl` is flawed in versions `7.62.0` though `7.70.0` and so is fixed in `7.71.0`. The version that has the fix applied in Debian Buster is `7.64.0-4+deb10u2` (see [security-tracker.debian.org](https://security-tracker.debian.org/tracker/CVE-2020-8169) and [DSA-4881-1](https://www.debian.org/security/2021/dsa-4881)). + - The binary or library is not vulnerable because the vulnerable code is never executed. Security solutions make the assumption that if a dependency has a vulnerability, then the binary or library using the dependency is also vulnerable. This correctly reports vulnerabilities, but this simple approach can also lead to many false positives. It can be improved by using other tools to detect if the vulnerable functions are used. [`govulncheck`](https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck) is one such tool made for Go based binaries. + + e.g., [CVE-2023-28642](https://nvd.nist.gov/vuln/detail/CVE-2023-28642) is a vulnerability in runc less than version `1.1.5` but shows up when scanning the [`gosu`](https://github.com/tianon/gosu) 1.16 binary since runc `1.1.0` is a dependency. Running `govulncheck` against `gosu` shows that it does not use any vulnerable runc functions. + The security scanners can't reliably check for CVEs, so it uses heuristics to determine whether an image is vulnerable. Those heuristics fail to take some factors into account: - Is the image affected by the CVE at all? It might not be possible to trigger the vulnerability at all with this image.