Friend
Professional
- Messages
- 2,675
- Reaction score
- 987
- Points
- 113
Why do scanners see what is not there and do not find what they need?
Google's AutoVM team found that dependency scanning tools often mistakenly report vulnerabilities in software. These vulnerabilities may either not pose a real security risk or may not require any action. In a new Google blog, the team shares the most common types of false positives and tips on how to recognize them.
The main problem is that third-party dependency scanners check the versions of installed packages on hosts and map them to public vulnerability databases. This allows you to determine if packages are at risk of known vulnerabilities. However, such reports often contain false or irrelevant findings for safety, which leads to incorrect results.
One of the most common sources of false positives is errors in the vulnerability databases themselves, such as NVDs or operating system-specific data sources. Sometimes, a vulnerability may be dismissed or retracted after a more detailed analysis. For example, the CVE-2023-4881 vulnerability was recognized as non-security, but scanners continued to record it. In some cases, the information in the NVD database may differ from the data provided for specific distributions of operating systems, which also leads to erroneous reports.
Another important factor is the too wide range of versions of vulnerable software presented in common databases. Often, these ranges do not take into account patches that operating system distributions release on their own. For example, the CVE-2020-14422 vulnerability, which affects Python version 3.6.10, was actually patched in Ubuntu, where a patch version was released, but many scanners continue to consider this version vulnerable.
There are also cases when the vulnerability is applicable only in certain system configurations, but scanners do not always take this into account. For example, the CVE-2023-52426 vulnerability affects packets only when they are compiled with certain flags. Ubuntu Focal does not use these flags, so the vulnerability is not relevant, but some scanners continue to detect it.
Often, the problem also lies in incomplete data in vulnerability databases, as was the case with CVE-2022-3857, where different databases provided conflicting information about the affected versions of the package. This leads to the fact that some scanners can erroneously report a vulnerability even on protected systems.
False positives can also occur due to incorrect information about the affected binary packages. For example, CVE-2024-6387 only affects OpenSSH servers, but the entire source "openssh" package is labeled vulnerable in the Debian database, resulting in an incorrect vulnerability flag even on client-only systems.
In addition, some scanners may report non-security-related supporting information. For example, scanners can indicate updates that do not address vulnerabilities, such as changes to time zone data or the addition of new GPG keys. These reports do not pose a security risk and do not require immediate intervention.
Concluding the post, Google emphasizes that dependency scanner reports should be approached with caution. False positives can occur for a variety of reasons, and it is important to check whether the specified vulnerability applies to a particular system.
Source
Google's AutoVM team found that dependency scanning tools often mistakenly report vulnerabilities in software. These vulnerabilities may either not pose a real security risk or may not require any action. In a new Google blog, the team shares the most common types of false positives and tips on how to recognize them.
The main problem is that third-party dependency scanners check the versions of installed packages on hosts and map them to public vulnerability databases. This allows you to determine if packages are at risk of known vulnerabilities. However, such reports often contain false or irrelevant findings for safety, which leads to incorrect results.
One of the most common sources of false positives is errors in the vulnerability databases themselves, such as NVDs or operating system-specific data sources. Sometimes, a vulnerability may be dismissed or retracted after a more detailed analysis. For example, the CVE-2023-4881 vulnerability was recognized as non-security, but scanners continued to record it. In some cases, the information in the NVD database may differ from the data provided for specific distributions of operating systems, which also leads to erroneous reports.
Another important factor is the too wide range of versions of vulnerable software presented in common databases. Often, these ranges do not take into account patches that operating system distributions release on their own. For example, the CVE-2020-14422 vulnerability, which affects Python version 3.6.10, was actually patched in Ubuntu, where a patch version was released, but many scanners continue to consider this version vulnerable.
There are also cases when the vulnerability is applicable only in certain system configurations, but scanners do not always take this into account. For example, the CVE-2023-52426 vulnerability affects packets only when they are compiled with certain flags. Ubuntu Focal does not use these flags, so the vulnerability is not relevant, but some scanners continue to detect it.
Often, the problem also lies in incomplete data in vulnerability databases, as was the case with CVE-2022-3857, where different databases provided conflicting information about the affected versions of the package. This leads to the fact that some scanners can erroneously report a vulnerability even on protected systems.
False positives can also occur due to incorrect information about the affected binary packages. For example, CVE-2024-6387 only affects OpenSSH servers, but the entire source "openssh" package is labeled vulnerable in the Debian database, resulting in an incorrect vulnerability flag even on client-only systems.
In addition, some scanners may report non-security-related supporting information. For example, scanners can indicate updates that do not address vulnerabilities, such as changes to time zone data or the addition of new GPG keys. These reports do not pose a security risk and do not require immediate intervention.
Concluding the post, Google emphasizes that dependency scanner reports should be approached with caution. False positives can occur for a variety of reasons, and it is important to check whether the specified vulnerability applies to a particular system.
Source
