![CVE.org structure diagram copied with permission from https://www.cve.org/ProgramOrganization/Structure](/rhdc/managed-files/styles/wysiwyg_full_width/private/security-vulnerabilty-reporting-img1.png.webp?itok=lsqSz4s-)
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.
- Discover: Somebody discovers a new vulnerability.
- Report: Discoverer reports a vulnerability to a CVE Program participant / CNA.
- Request: CVE Program participant requests a CVE Identifier (CVE ID).
- 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.
- 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.
- 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.
Über den Autor
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.
Mehr davon
Nach Thema durchsuchen
Automatisierung
Das Neueste zum Thema IT-Automatisierung für Technologien, Teams und Umgebungen
Künstliche Intelligenz
Erfahren Sie das Neueste von den Plattformen, die es Kunden ermöglichen, KI-Workloads beliebig auszuführen
Open Hybrid Cloud
Erfahren Sie, wie wir eine flexiblere Zukunft mit Hybrid Clouds schaffen.
Sicherheit
Erfahren Sie, wie wir Risiken in verschiedenen Umgebungen und Technologien reduzieren
Edge Computing
Erfahren Sie das Neueste von den Plattformen, die die Operations am Edge vereinfachen
Infrastruktur
Erfahren Sie das Neueste von der weltweit führenden Linux-Plattform für Unternehmen
Anwendungen
Entdecken Sie unsere Lösungen für komplexe Herausforderungen bei Anwendungen
Original Shows
Interessantes von den Experten, die die Technologien in Unternehmen mitgestalten
Produkte
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud-Services
- Alle Produkte anzeigen
Tools
- Training & Zertifizierung
- Eigenes Konto
- Kundensupport
- Für Entwickler
- Partner finden
- Red Hat Ecosystem Catalog
- Mehrwert von Red Hat berechnen
- Dokumentation
Testen, kaufen und verkaufen
Kommunizieren
Über Red Hat
Als weltweit größter Anbieter von Open-Source-Software-Lösungen für Unternehmen stellen wir Linux-, Cloud-, Container- und Kubernetes-Technologien bereit. Wir bieten robuste Lösungen, die es Unternehmen erleichtern, plattform- und umgebungsübergreifend zu arbeiten – vom Rechenzentrum bis zum Netzwerkrand.
Wählen Sie eine Sprache
Red Hat legal and privacy links
- Über Red Hat
- Jobs bei Red Hat
- Veranstaltungen
- Standorte
- Red Hat kontaktieren
- Red Hat Blog
- Diversität, Gleichberechtigung und Inklusion
- Cool Stuff Store
- Red Hat Summit