Closed jbusche closed 1 year ago
Before the changes: twistlock-scan-results-instscale-latest.results.csv
After the changes: (Empty, no issues) twistlock-scan-results-20230216-194159-699816235-UTC-9f3a5ef7.results.csv
@jbusche quay has an image scan, curious to know how twistlock scan is different from image scans done by quay repo?
@asm582. I was given access to quay, and I see their security scan. It can't be a very thorough scan, it only found one item on some of the mcad-controller images I looked at (main-v1.29.50
and older.) And the Quay security scan is showing "unsupported" for the instascale-controller images, for some reason. (Meanwhile, with Twistlock it found 44 fixable vulnerabilities for the mcad-controller:main-v1.29.50, and six for instascale.)
We started using Twistlock to scan our containers a few years ago when I was in the Watson org - it was required to have no Critical or High vulnerabilities before we moved any containers to production. Twistlock got bought by PaloAlto Networks https://www.ibm.com/partners/showcase/solutions/solution/panw-prisma-cloud-compute. It's useful to scan an image/container to make sure there's no old libraries in there. It was very helpful during the ilog4J debacle in Dec 2021, and it immediately catches old openssl and java, go, etc, with links to the CVE website and a nice description of the problem it's found (if any.)
One problem with any code is it can go out of compliance from one day to another. But as we're coming out with new releases, we can hopefully address the new problems as they come up, and feel better that our latest images don't contain known vulnerabilities.
Fixed and merged in PR 34
I used twistlock to scan the instascale-controller:latest image, and it has a few known vulnerabilities:
I tried changing the Dockerfile to use the latest golang image:
And that fixed all the vulnerabilities but one: https://nvd.nist.gov/vuln/detail/CVE-2022-21698
Looking to see how that can potentially be solved tomorrow. Full description of the issue is below:
packagePath = /manager packageName = github.com/prometheus/client_golang packageVersion = v1.11.0 status = fixed in 1.11.1 description = client_golang is the instrumentation library for Go applications in Prometheus, and the promhttp package in client_golang provides tooling around HTTP servers and clients. In client_golang prior to version 1.11.1, HTTP server is susceptible to a Denial of Service through unbounded cardinality, and potential memory exhaustion, when handling requests with non-standard HTTP methods. In order to be affected, an instrumented software must use any of
promhttp.InstrumentHandler*
middleware exceptRequestsInFlight
; not filter any specific methods (e.g GET) before middleware; pass metric withmethod
label name to our middleware; and not have any firewall/LB/proxy that filters away requests with unknownmethod
. client_golang version 1.11.1 contains a patch for this issue. Several workarounds are available, including removing themethod
label name from counter/gauge used in the InstrumentHandler; turning off affected promhttp handlers; adding custom middleware before promhttp handler that will sanitize the request method given by Go http.Request; and using a reverse proxy or web application firewall, configured to only allow a limited set of methods.