Over the last couple of months I’ve been looking at container vulnerability scanning a bit (some more info here), and there was one behaviour I noticed that’s probably worth commenting on, as it can be a bit unexpected, and that’s the handling of unfixed vulnerbilities.
Some Linux distributions (e.g. Debian or Ubuntu) will release information about CVEs for which there is no released patched package, and so you get the question of “should a vulnerability scanner report those?”. On the one hand, it’s good for organizations to know about all their vulnerabilities. On the other hand, from a compliance standpoint, having a large number of unpatchable vulnerabilities can be awkward!
Whilst this behaviour isn’t unique to containers, I came across it when investigating the differences between the results of different container scanning engines when run against Docker Hub official images. Some tools, for example Nessus and Nexpose would report 0 issues, whilst others, such as Trivy or Clair would report relatively large numbers. As far as I can tell, what’s happening is that Nessus/Nexpose take the approach of not flagging unpatched vulnerabilities where Trivy and Clair default to flagging them.
I was wondering how to replicate this as Nessus’ container scanning service is not availble for free, however luckily you can use Trivy to scan a Virtual Machine image, so we can test it that way and use the free Nessus Essentials for comparison. For this test, I got an Ubuntu 18.04 server image, updated it fully and ran Nessus and Trivy against it.
A Nessus scan using credentials to allow patch checking, showed 0 unpatched vulnerabilities. Trivy by default showed 242 vulnerabilities as shown below.
trivy fs -o /
2020-11-21T21:16:57.492Z INFO Detecting Ubuntu vulnerabilities...
trivyubu (ubuntu 18.04)
=======================
Total: 242 (UNKNOWN: 0, LOW: 178, MEDIUM: 64, HIGH: 0, CRITICAL: 0)
Helpfully, Trivy provides an --ignore-unfixed option, which demonstrates that what we’re seeing is unpatched issues, as with that flag we get back 0.
rorym@trivyubu:~/trivy_output$ trivy fs --ignore-unfixed /
2020-11-21T21:17:16.931Z INFO Detecting Ubuntu vulnerabilities...
trivyubu (ubuntu 18.04)
=======================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)
Conclusion
So the question is, which one’s right? I’d say (like most things in security) that depends! For most organizations, you probably don’t want to manually patch and compile packages, so you may want to use a container scanner that supports functionality to ignore unfixed issues. This also gives you comparable scanning to the output you’re likely getting from your Virtual Machine vulnerability scanning efforts.
For higher risk deployments, you might want to review the package lists and ensure that you’re comfortable leaving those issues unpatched.
Of course, mitigations like minimizing the number of installed packages and looking at distroless or scratch containers, could also help reduce this kind of problem.
