There's quite a lot of vulnerabilities in the NVD that aren't really vulnerabilities but may show up in vulnerability scanners depending on the behavior of the scanner. Here's some examples of open vulnerabilities (pulled from a debian container that's up-to-date at the time of writing) that just aren't vulnerabilities at all:
- We don't ship that vulnerable script in kerberos
- That's how tar works
- The default setting has blocked unknown username logging for more than a decade, you can change it for debugging.
- That's how glob works
- Not actually a vulnerability because URI isn't used
- Dual_EC_DRBG is unused/broken in OpenSSL
As raesene@ points out whether these show up in your container vulnerability scanner depends entirely on the scanner. Empirical testing shows that nessus filters out quite a lot of unactionable vulnerability scan results, whereas free scanners like Trivy, or even other paid scanners, don't. They take the approach of "show everything, but you can filter out the actionable vulns that have patches".
The second approach is the easiest and least controversial for the scanner implementor because they don't have to make any security decisions about what to show or not show. It effectively delegates the problem of filtering out the noise to the user. The first problem is that the default view is very noisy and it's not immediately obvious how to make it better, especially for practitioners coming from scanners that filter the noise up-front. It takes effort to get to a sensible view.
The second problem is that if you just filter vulns by which ones have patches, to eliminate the this-isn't-a-vuln entries from 2005, you may miss something important that isn't patched yet but that you should be mitigating with a workaround or settings change.
I don't think we're doing users any favors by continuing to put 18-year-old "vulnerabilities" that were never vulnerabilities in their scan results. It's harder to do, but I think a line should be drawn by the scanner as nessus does.
Other ancient unactionable vulnerabilities you'll see, in tools that don't filter up-front, are technically vulnerabilities but low enough severity that no-one has gotten around to fixing them for years. Some are incompatible with current software so there's no obvious fix without something like a new kernel syscall.
Should these be filtered out? From the user's, i.e. the scan consumer's, point of view they are basically useless. It's not like the average practitioner has the skills or time to go fix these, and even if they did the projects may just reject the fixes.
Showing them in tools, "i.e. many eyes", isn't exerting much pressure on getting them fixed because they are all multiple years old or completely abandoned. From a scanner implementor point of view the decision on whether to show them is more difficult, because unlike the first list these are real vulns, just not important ones that are going to be fixed inside of any kind of compliance SLO.
So should a scanner hide a "real" vuln? Or show the user an unpatchable vuln in their dashboard that may, depending on the user's specific compliance requirements, trigger a need to write monthly deviation requests forever? Tough choice.
No comments:
Post a Comment