Subscribe to the feed structure diagram copied with permission from

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 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


  • CPE - Common Platform Enumeration dictionary, a structured naming scheme for information technology systems, software, and packages. See
  • CVE - Common Vulnerabilities and Exposures.
  • CVSS - Common Vulnerability Scoring System. See
  • 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.).
  • CISA - United States Cybersecurity and Infrastructure Security Agency. 
  • 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.

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

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 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 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 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

About the author

D. Greg Scott is a published author, with two novels so far and more coming. On weekdays, he helps the world’s largest open source software company support the world's largest telecom companies. Nights and weekends, he helps Jerry Barkley and other characters save the world. Enjoy the fiction. Use the education. Real superheroes are ordinary people who step up when called.

Scott lives in Minnesota with his wife, daughter, two grandsons, three cats, one dog and other creatures that come and go. Prior to joining Red Hat in 2015, he spent more than twenty years in various roles as an independent consultant and reseller partner.

Read full bio

Browse by channel

automation icon


The latest on IT automation for tech, teams, and environments

AI icon

Artificial intelligence

Updates on the platforms that free customers to run AI workloads anywhere

open hybrid cloud icon

Open hybrid cloud

Explore how we build a more flexible future with hybrid cloud

security icon


The latest on how we reduce risks across environments and technologies

edge icon

Edge computing

Updates on the platforms that simplify operations at the edge

Infrastructure icon


The latest on the world’s leading enterprise Linux platform

application development icon


Inside our solutions to the toughest application challenges

Original series icon

Original shows

Entertaining stories from the makers and leaders in enterprise tech