Detection of unfixed vulnerabilities and missing CVEs #474
Comments
mattlorimor
added
the
triage/support
|
Or, to ask it super briefly, when Trivy can report on unfixed vulnerabilities, what is allowing it to do so? Vuln feed for OS A is "better" than vuln feed for OS B? Direct version comparisons against the NVD CPEs? Something else? |
|
Right.
The RHEL/CentOS feed publishes notices even before they don't provide the patch yet. For example, CVE-2020-11884 affects RHEL8, but they are still working on the patch as of May 3.
After providing the patch, the status is going to be "Fixed". On the other hand, ALAS pushes only updates with the patch. I don't know about Twistlock. They may use NVD, but you have to be careful of it because NVD provides generic information. The setting or compile options might be different between each distribution or major version. In that case, the vulnerability doesn't affect the package for the distribution. So, Trivy doesn't refer to NVD to detect vulnerabilities, but vulnerability feed from the vendor such as Red Hat and Amazon. Or, they may have their own vulnerability feed. By the way, I'm curious about which version of |
|
Thanks for the clarification and confirming my understanding around the tool.
The version of The link you provided seems to be a fix for: The vulnerabilities found in Ah... I see that CVE-2018-20969 claims to be taken care of by CVE-2019-13638:
CVE-2019-20633 seems to not be fixed, yet, (https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/patch/APKBUILD#L26). And, because Trivy doesn't report on non-fixed (and published) vulns for Alpine, it makes sense that CVE-2019-20633 would be found. I will close this since the root of my questions has been addressed. |
Right. I think Alpine maintainers just forgot to add CVE-2018-20969 to APKBUILD. So, it looks like CVE-2018-20969 is false positive.
Yes, CVE-2019-20633 looks unfixed and low severity, so Red Hat doesn't fix it as well as Alpine. Trivy is based on Alpine patches, so it can't be detected. |
I'm looking for some clarification around this section of the README: https://github.com/aquasecurity/trivy#os-packages. I'm copying the current version of the table I'm questioning for posterity.
That table combined with this text:
Would indicate to me that whether or not Trivy can detect an OS package vulnerability is dependent on when the vuln feed used for each OS reports them as issues. (mildly obvious)
Phrased another way (and using an example): Trivy would be able to detect a CVE in Amazon Linux 2 only when it has been published to the Amazon feed that is used to build Trivy's vuln database to check against. That is to say, it isn't checking raw OS package
--versionnumber declarations straight against the NVD database and its CPE listings. Nor could you even necessarily do so. The.amzn2package versions often differ from the actual package maintainer's version number.In contrast, for RHEL and CentOS, Trivy would report both fixed and unfixed CVEs on the system being scanned. I imagine this is due to the fact that the feed for RHEL/CentOS publishes notices before fixes are released where the ALAS feed for Amazon Linux only pushes updates to the feed when the fixes are ready to deploy.
Another example: I scanned an
alpine:3.11image withpatchinstalled. It yielded no results with Trivy. However, Twistlock (yes, I know this may not be an apples-to-apples comparison as Twistlock is a commercial product) was able to find two CVEs on the same image:Trivy not detecting seems to line up with everything I'm seeing about how the vuln lists are complied.
I'm curious whether Twistlock can detect the CVEs when Trivy can't because they are using a different vuln feed source, comparing package version output directly against the the NVD database, curating their own internal list, or any combination of the above.
Does all of this sound correct?
The text was updated successfully, but these errors were encountered: