Why OVAL Feeds Outperform NVD for Linux Vulnerability Management
Learn why OVAL feeds, curated by Linux distributions, offer more precise vulnerability data than the NVD, reducing container scanning false positives and wasted efforts.
Learn why OVAL feeds, curated by Linux distributions, offer more precise vulnerability data than the NVD, reducing container scanning false positives and wasted efforts.
Learn why OVAL feeds, curated by Linux distributions, offer more precise vulnerability data than the NVD, reducing container scanning false positives and wasted efforts.
Learn why OVAL feeds, curated by Linux distributions, offer more precise vulnerability data than the NVD, reducing container scanning false positives and wasted efforts.
Learn why OVAL feeds, curated by Linux distributions, offer more precise vulnerability data than the NVD, reducing container scanning false positives and wasted efforts.
If you have multiple container scanning solutions, or are testing multiple tools, you might notice discrepancies between findings for the same images. For example, Tool A might tell you that a container image is vulnerable while Tool B does not. It leaves you wondering which tool you can trust, and ultimately whether you’re detecting exploitable risks.
When managing vulnerabilities in Linux environments, the right data source makes all the difference.
- National Vulnerability Database (NVD) is a widely-used source for Common Vulnerabilities and Exposures (CVEs), it often lacks precision and context.
- Open Vulnerability and Assessment Language (OVAL) is a standardized, machine-readable format to capture information about vulnerable software components and insecure configuration settings. OVAL feeds, maintained by many major Linux distributions, deliver more accurate and context-specific vulnerability data, making them a superior choice for vulnerability management.
Endor Labs’ container scanning relies on OVAL feeds from distributions to provide accurate, vetted vulnerability data that excludes disputed or irrelevant entries. This ensures your scans use the best available information to surface findings that could be exploited in your environment.
NVD vs. OVAL: What's the difference?
The NVD complements CVE data with metadata like CVSS scores, and lists of affected software by means of CPE names (Common Platform Enumeration). It provides a generalized view that does not systematically consider distribution-specific mitigations, configurations, or patches. As a result, NVD entries may flag software as vulnerable when, in fact, the distribution has already addressed the issue through backports or custom patches.
OVAL documents, on the other hand, are curated by the maintainers of Linux distributions such as Debian or Red Hat. Their respective security experts analyze CVEs based on their software's specific context, providing tailored advisories that reflect the actual risk level for users. This can lead to significant differences between OVAL feeds and NVD data.
In the case of Ubuntu, the Security Team produces OVAL documents which “contain details of all known security vulnerabilities and fixes relevant to the Ubuntu release [emphasis added], and can be used to determine whether a particular patch is appropriate. OVAL files can also be used to audit a system to check whether the latest security fixes have been applied.”
Feeds with OVAL documents are provided by major Linux distributors, including: Red Hat, Ubuntu, Debian, Fedora, Alpine, Oracle and Amazon.
Relying solely on NVD data can lead to significant false positives and wasted remediation efforts. Security teams may be misled into applying unnecessary patches or making configuration changes that do not improve security.
In contrast, OVAL feeds provide validated, distribution-specific information that aligns with the actual state of your systems. Scanners relying solely on NVD data can incorrectly flag these versions as vulnerable if they do not account for custom backports with distribution-specific version identifiers, e.g. “10.34-7ubuntu0.1” in the example of CVE-2022-1587.
Case study: CVE-2022-1587
To understand the impact of inaccurate NVD data, we’ll look at CVE-2022-1587, which affects the PCRE2 library (Perl Compatible Regular Expressions) and was reported to allow denial-of-service attacks through specific malformed inputs. It is a notable case where a vulnerability is flagged as “Critical” in the National Vulnerability Database (NVD) but analyzed as a “Low” priority in Ubuntu.
Affected versions – The NVD marks all PCRE2 versions below 10.40 as affected.
Both Debian and Ubuntu, however, backported fixes to earlier versions, e.g., “10.36-2+deb11u1” for Debian Bullseye and “10.34-7ubuntu0.1” for Ubuntu Focal (20.04).
Let’s take the example of the fixed Ubuntu version “10.34-7ubuntu0.1”: In this case, “10.34” represents the upstream version – which is vulnerable per NVD, whereas “7ubuntu0.1” captures information about Debian and Ubuntu-specific revisions (7 and 0.1 respectively).
Vulnerability scanners that solely or primarily use NVD as data source and are unaware of the specific version formats and conventions used by Debian and Ubuntu respectively could wrongly flag the patched version “10.34-7ubuntu0.1” as vulnerable, just because the first element of the version identifier matches the CPE name and version listed as vulnerable by the CVE.
The motivation behind such backports is provided by the following entry in the Debian security FAQ.
Q: The version number for a package indicates that I am still running a vulnerable version!
A: Instead of upgrading to a new release we backport security fixes to the version that was shipped in the stable release. The reason we do this is to make sure that a release changes as little as possible so things will not change or break unexpectedly as a result of a security fix. You can check if you are running a secure version of a package by looking at the package changelog, or comparing its exact version number [emphasis added] with the version indicated in the Debian Security Advisory.
Risk Assessment – The NVD assigned a high CVSS score of 9.1, indicating a “Critical” vulnerability. The Ubuntu security team, on the other hand, only assigned a “Low” priority to CVE-2022-1587, because – according to their documentation of priority levels – it is “hard to exploit due to the environment, requires a user-assisted attack, has a small install base, or does very little damage”.
Advantages of distribution-specific analysis
CVE-2022-1587 is a clear example of how relying solely on NVD data can lead to false positives. OVAL feeds offer a more refined and context-specific approach to vulnerability management by providing tailored advisories that accurately reflect the distribution's risk assessment. Embracing OVAL feeds for vulnerability management allows organizations to avoid unnecessary remediation efforts and focus on actual security risks.
Linux distributions have the expertise to analyze each CVE's impact on their packages. They consider:
- Whether the vulnerable code is utilized or exposed
- If existing mitigations make exploitation unlikely
- Any custom patches or backports applied
This context-sensitive approach ensures that advisories are directly relevant to the distribution's environment.
OVAL reduces false positives
The NVD often lists general version ranges as vulnerable, leading to false positives for distributions with custom patches. In contrast, OVAL feeds minimize noise by filtering out irrelevant CVEs and accounting for distribution-specific fixes, which leads to more accurate vulnerability detection.
OVAL provides a more accurate risk assessment
OVAL advisories reflect the real-world impact of vulnerabilities, allowing for more accurate risk assessments. This is especially important for Linux environments, where configurations and patches differ widely across distributions. For example, a vulnerability marked "Critical" in the NVD might be classified as "Low" in an OVAL feed due to mitigations specific to that distribution.
How to use OVAL feeds for more accurate vulnerability management
- Trust Distribution-Specific Data Over NVD Listings: When a distribution disputes a CVE or marks it as negligible, rely on that information over NVD's general classification. Security teams who maintain OVAL feeds have more insight into the specific conditions affecting their software.
- Use NVD Data as a Supplement, Not a Primary Source: NVD data can help with general awareness, but it should not be the sole basis for vulnerability management decisions.
Prioritize Vulnerabilities Based on OVAL Analysis: Addressing vulnerabilities flagged in OVAL feeds will help ensure that remediation efforts are focused on real threats.
Container scanning with Endor Labs
Endor Labs' container scanning solution is a part of our consolidated AppSec platform for managing software supply chain security. It provides deep visibility into container dependencies, reduces alert noise, and accelerates remediation efforts.
Key features include:
- Container vulnerability scanning in pipelines. Scan your containers for vulnerabilities, identify base images, and set policies that can block pushing to registry and/or help your engineering teams ensure they’re publishing safe images
- Correlate container vulnerabilities with SCA vulnerabilities automatically. Reduce cost of tracking, as well as speed up research and repair of vulnerabilities.
- Routine container vulnerability scanning in registries. Schedule routine scans of container images in registries to help meet the requirement to monitor the container image registry.
- Sign containers and components to prevent unauthorized deployments. Create strong container signatures with no new infrastructure. Verify signatures before deployment to ensure that non-compliant (unsigned, invalid, or revoked) containers cannot be deployed.
Book a demo to learn more about Endor Labs’ container scanning solution, including how it reduces the cost of AppSec while also creating a better experience for your developers.