Security vulnerability reporting: Who can you trust?

Good cyber security practices depend on trustworthy information sources about security vulnerabilities. This article offers guidance around who to trust for this information.

In 1999, MITRE Corporation, a US Government-funded research and development company, realized the world needed a uniform standard for reporting and tracking software security bugs. MITRE worked with the IT industry to invent a concept called CVE, for Common Vulnerabilities and Exposures. The CVE concept caught on, and today, the industry acknowledges CVE as the universal standard for security vulnerability reporting.

Software bug reporting has come a long way since 1999, and today an organization named CVE.org acts as an information clearinghouse for software security bugs. The structure looks like the picture at the top of this blog post.

We need some definitions for this structure and the vulnerability reporting process to make sense. See https://www.cve.org/ProgramOrganization/Structure.

Definitions

• CPE - Common Platform Enumeration dictionary, a structured naming scheme for information technology systems, software, and packages. See https://nvd.nist.gov/products/cpe
• CVE - Common Vulnerabilities and Exposures.
• CVSS - Common Vulnerability Scoring System. See https://nvd.nist.gov/vuln-metrics
• CWE™- Common Weakness Enumeration, a community-developed list of common software and hardware weaknesses. A “weakness” is a condition in a software, firmware, hardware, or service component that, under certain circumstances, could contribute to the introduction of vulnerabilities.
• CNA - CVE Numbering Authority. Red Hat and many others are CNAs.
• CNA-LR - CVE Numbering Authority of Last Resort.
• Root - The CVE program authorizes Root organizations to assume responsibility, within a specific Scope, for recruitment, training and governance of CNA, CNA-LR, or other Root organizations.
• TL-Root - Top Level Root, responsible for governance and administration of its hierarchy, including Roots and CNAs within that hierarchy.
• ADP - Authorized Data Publisher. The ADP role enables a qualified and authorized organization to enrich the content of CVE Records published by a CVE Numbering Authority (CNA) with additional, related information (e.g., risk scores, references, vulnerability characteristics, translations, etc.).
  See https://www.cve.org/ProgramOrganization/ADPs.
• CISA - United States Cybersecurity and Infrastructure Security Agency. 
  See https://www.cisa.gov/.
• MITRE Corporation - a federally funded research and development center supporting various U.S. government agencies in the aviation, defense, healthcare, homeland security, and cyber security fields, among others.
  • In 1999 MITRE and top security organizations created CVE, the first public dictionary of computer vulnerabilities to boost cyber defense.
  • See https://www.mitre.org/who-we-are/our-story

Six organizations share a special role as CVE Root participants. These include US, Spanish, and Japanese government agencies, MITRE, and two private-sector companies—Google and Red Hat.

We need one more definition.

Z-stream - Red Hat numbers product versions as x.y.z, kind of like the old Dewey Decimal System, where x is a major version number, y is a minor version number, and z is a patch level. Red Hat supports multiple concurrent product version streams, and backports feasible security patches into older product streams.

Vulnerability reporting

Security vulnerability reporting follows six general steps.

1. Discover: Somebody discovers a new vulnerability.
2. Report: Discoverer reports a vulnerability to a CVE Program participant / CNA.
3. Request: CVE Program participant requests a CVE Identifier (CVE ID).
4. Reserve: The CNA reserves the ID, which is the initial state of a CVE Record. The Reserved state means that CVE stakeholder(s) are using the CVE ID for early-stage vulnerability coordination and management, but the CNA is not yet ready to publicly disclose the vulnerability.
5. Submit: CVE Program participant submits the details. Details include but are not limited to affected product(s); affected or fixed product versions; vulnerability type, root cause, or impact; and at least one public reference. CNAs normally include information with the CVE data elements that cover the CWE, the CWE ID, CPE, CVSS and a description.
6. Publish: Once the CVE record includes the minimum required data elements, and after any mandated embargo period passes, the responsible CNA publishes it to the CVE List.

The CVE Record is then available for public download and viewing. See https://www.cve.org/About/Process.

Bug hunting

Customers engage auditors to scan their IT infrastructures for security vulnerabilities. To perform their scans, auditors need an authoritative data source for vulnerability information.

As a CNA, Red Hat’s scope offers the most credible information source in the industry for vulnerabilities in the open source community related to Red Hat products. Red Hat triage teams continuously update a human-readable and machine-readable repository of security and CVE information, published at https://www.redhat.com/security. Auditors use the machine readable version to drive automated scans. People use the human-readable version to drive decisions about risk.

Security auditors often flag vulnerabilities as critical, while Red Hat uses an objective rating criteria to classify them as moderate, important, or critical. Scanners might also generate false positives by not acknowledging backported bug fixes into earlier product z-streams. Or they might flag components built from libraries with known vulnerabilities, even if the components themselves are not vulnerable.

Here is a typical false-positive example. A recent security scan against a Red Hat OpenShift cluster flagged a Python flaw, CVE-2023-24329, in a Red Hat Enterprise Linux (RHEL) 8.6 container image. The installed Python version was 3.6.8-47.el8_6. The scan claimed this version was broken, and the fixed version was 0:3.6.8-51.el8_8.1. But the scan should have used data about the RHEL 8.6 Extended Update Service (EUS) release stream instead of the general RHEL 8 release stream. The RHEL 8.6 EUS errata notice showed the fixed image was platform-python-3.6.8-47.el8_6.1.i686.rpm, the same version the scan claimed was broken. The scan incorrectly flagged it as broken, probably because 3.6.8-47 is less than 3.6.8-51.

Library vulnerabilities also generate false-positives. CVE-2023-49569 describes a critical vulnerability with certain functions in a version of the go library, go-git. A recent security scan flagged all 201 product components that depend on this library, including components that never use the vulnerable functions. Especially with library vulnerabilities, distinguish false-positives from truly vulnerable components by carefully reading the relevant Red Hat security repository CVE writeups.

When scanners and the Red Hat CVE repository disagree, use the Red Hat security repository as the authoritative source of truth, either directly or pull the Red Hat data from CVE.org which aggregates all CNA data. Red Hat knows its own products better than anyone else, just like other vendors for their own scopes. Red Hat also enjoys a well-earned reputation for taking its security responsibility seriously. If customers or auditors disagree with any Red Hat CVE evaluation, Red Hat and CVE.org offer an escalation process to reconcile differences through the CNA of Last Resort (CNA-LR).

Good cyber security practices depend on accurate information. Trust Red Hat as an authoritative source.

Learn more about Red Hat Security