CNA Birds of a Feather: Open Forum with Certified Numbering Authorities

CNA Birds of a Feather: Open Forum with Certified Numbering Authorities

Speakers: David Welch, Moderator, Hero Devs; Jonathan Evans, GitHub; Lisa Olsson, Microsoft; Scott Moore, IBM

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=5w39y_ZyWJY

Overview

This VulnCon Birds of a Feather session, titled "CNA Birds of a Feather: Open Forum with Certified Numbering Authorities," brought together a panel of seasoned experts from leading technology companies and a relatively new CNA to discuss the history, evolution, and current state of the CVE Program. Moderated by David Welch of Hero Devs, the panel included Jonathan Evans from GitHub, Lisa Olsson from Microsoft, and Scott Moore from IBM. The session aimed to demystify the Certified Numbering Authority (CNA) program, share insights from years of experience, and provide an open forum for questions and community engagement.

The talk provides a crucial historical perspective on how the CVE Program, which began as a small, manual effort, transformed into a globally federated, community-driven initiative critical for cybersecurity. Understanding this evolution is vital for anyone involved in vulnerability management, product security, or open-source development. The discussion highlights the challenges of scaling a global vulnerability identification system, the importance of community involvement, and the ongoing efforts to improve the quality and efficiency of CVE assignments. For newcomers and veterans alike, the session offered a candid look into the operational realities and strategic direction of this foundational cybersecurity standard.

Background

▶ Watch: Panelist introductions and talk overview (0:00)

The genesis of the CVE Program is deeply rooted in the early days of computing and the nascent understanding of cybersecurity. Scott Moore, a veteran of the vulnerability space, recounted his personal journey, beginning with a childhood fascination ignited by the movie WarGames and early hacking experiences. His early efforts involved manually collecting exploits like "baseball cards" in a flat file database, predating widespread search engines. This personal endeavor eventually led to a professional role in 1997, managing a vulnerability database, just two years before the official launch of CVE in 1999.

Moore highlighted three pivotal historical events that underscored the urgent need for a standardized vulnerability identification system:

1. The Cuckoo's Egg (1986): A real-life account of an astronomer at Berkeley tracking a KGB spy who had infiltrated multiple networks, including MITRE's. This demonstrated the interconnectedness of systems and the potential for widespread compromise.
2. The Robert Morris Worm (1988): One of the first major computer worms, it exploited vulnerabilities in programs like finger and sendmail to propagate across the nascent internet. This event showcased the devastating impact of easily exploitable software flaws.
3. The RPC netstatd Buffer Overflow (1998): A significant vulnerability discovered shortly before CVE's inception, which further emphasized the growing threat landscape.

These incidents prompted MITRE to task David Mann and Steve Christie with creating a system to correlate and uniquely identify vulnerabilities, as there was no centralized way to discuss them. At the time, different vulnerability databases used their own disparate identifiers (e.g., ID, CERT number, Satan, Netstat), making consistent communication and tracking impossible. This led to their seminal paper, "Enumerating Common Vulnerabilities," which laid the groundwork for the Common Vulnerabilities and Exposures (CVE) list. The initiative was officially launched at Purdue University, marking the beginning of a standardized approach to cybersecurity vulnerability identification.

Key Findings

▶ Watch: Agenda: CVE program overview, structure, and history (3:00)

The talk meticulously outlined the evolution of the CVE Program through distinct eras, highlighting key findings and transformations:

The Early Years (1999-2005):

• Manual & Limited Scope: Initially, the CVE project was small. An editorial board of about eight to ten people was responsible for testing every potential CVE candidate (Cans) by installing software on hardware, a laborious and manual process.
• MITRE's Central Role: MITRE was the primary entity assigning CVEs, often proactively discovering vulnerabilities by scraping websites and monitoring public disclosures.
• Low Adoption: The program was not widely adopted, and the scale of vulnerability disclosures was relatively low.

The Dawn of CNAs (2005-2010):

• Delegation Begins: The first Certified Numbering Authorities (CNAs) were introduced around 2005 (though the board stopped voting on candidates in 2004), marking a shift from MITRE's sole responsibility to a delegated model. This was a crucial step to address the growing volume of vulnerabilities.
• Rudimentary Communication: The process remained largely informal. CNAs would often request CVE IDs via personal email addresses (e.g., Steve Christie's MITRE email) and MITRE would still monitor vendor websites (like Microsoft's "Patch Tuesday" announcements) to gather information and publish descriptions.
• Reserved vs. Published: By 2010, a significant milestone was reached: more CVE IDs were being reserved in advance of public disclosure than were being assigned after a vulnerability was already public. This indicated a move towards more coordinated vulnerability disclosure, though many reserved IDs were not updated with full details by researchers, leading to "floating CVE IDs."

Federation and Growth (2010-2016):

• Scaling Challenges: As the number of vulnerabilities and participating entities grew, MITRE faced increasing frustration from the community due to bottlenecks in processing. The program experienced a "lack of enthusiasm and involvement."
• Shift to Federation: In 2016, a pivotal decision was made to federate the CVE Program, giving more power and responsibility to CNAs. This was a direct response to the discontent and the need for greater scalability.
• Increased CNA Participation: The number of CNAs grew significantly, reaching 45 by 2016.
• New Roots: CISA (Cybersecurity and Infrastructure Security Agency) joined as the second top-level root, expanding the program's reach, particularly within government and critical infrastructure sectors.
• Self-Service Tools: Plans for self-service tools like Vulnerogram and the development of a REST API began, enabling CNAs to directly file and manage CVEs within their respective scopes, reducing MITRE's manual workload. MITRE also stopped proactively assigning CVEs around this time.

The Modern Era (2016-Present):

• Exponential Growth: The program experienced explosive growth post-2016. The number of assigned CVEs nearly doubled from 6,437 in 2016 to over 18,000 in 2017.
• Record-Breaking Assignments: 2024 is projected to be the largest year for CVE assignments, with over 40,000 CVEs published, averaging 108 CVEs per day. This surge is partly attributed to the removal of the four-digit limit on CVE IDs, which previously constrained assignments.
• CNA Dominance: For the first time, CNAs are now collectively out-publishing MITRE in terms of CVE assignments. MITRE, which once assigned 100% of CVEs, now assigns only about 17%.
• Global Reach: The program boasts 450+ partners (CNAs) across 40 countries, with 8 different roots.
• Community-Driven Governance: An active board, steering committees, and numerous working groups (e.g., Quality Working Group, Tactical Working Group, AI Working Group, CNA Open-Source Project Experience – COUPE) ensure the program remains community-led and responsive to evolving needs.
• Enduring Standard: The CVE specification has endured for over 25 years as a community-driven standard, demonstrating its adaptability and fundamental importance in cybersecurity.

Technical Deep Dive

▶ Watch: Scott Moore's journey: early hacking and collecting exploits (4:00)

The technical architecture and operational mechanisms of the CVE Program have undergone significant evolution, transitioning from a highly centralized, manual system to a distributed, federated model.

Program Structure:

The current CVE Program operates on a hierarchical structure:

• Top-Level Roots: These are the highest authorities, currently MITRE and CISA. They are responsible for overseeing the overall program, enforcing governance, and managing the roots beneath them.
• Roots: These entities manage a specific domain or community of CNAs. Examples include Red Hat, which serves as a root for many open-source projects not under other specific scopes, and other industry-specific roots. Roots are responsible for onboarding, training, and governing the CNAs under their purview.
• Certified Numbering Authorities (CNAs): These are organizations (vendors, open-source projects, security researchers) authorized to assign CVE IDs to vulnerabilities within their specific scope. Examples include Microsoft, GitHub, IBM, and Hero Devs.

CVE Workflow:

1. CVE ID Reservation: When a potential vulnerability is discovered, a CNA can reserve a CVE ID. This allows for coordinated vulnerability disclosure (CVD), ensuring that affected parties (manufacturers, developers) are informed and can develop patches before the vulnerability is publicly disclosed.
2. Vulnerability Details & Description: The CNA then gathers details about the vulnerability, including affected products, versions, impact, and a concise description.
3. Publication: Once the vulnerability is patched and coordinated disclosure is complete, the CNA publishes the CVE record, making it publicly available.

Evolution of Tools and Processes:

• Early Days (Pre-2011): CVE ID requests were largely manual, often sent via email to specific MITRE personnel (e.g., Steve Christie's personal MITRE email). MITRE also had to proactively scrape public sources, like vendor security advisories and "Patch Tuesday" announcements, to find vulnerabilities and create CVE records, as CNAs often didn't communicate directly with MITRE post-publication.
• Federation Era (2016 onwards): This period saw the development of more automated and self-service tools.
• REST API: A RESTful API was introduced, allowing CNAs to programmatically interact with the CVE system for reserving, updating, and publishing CVEs. This enabled CNAs to integrate CVE management directly into their vulnerability disclosure workflows.
• Vulnerogram: This is a user-friendly, GUI-based web tool designed to simplify the process of creating and managing CVE records. It serves as an introductory tool for new CNAs and a convenient option for those who prefer a visual interface over scripting.
• GitHub Integration: GitHub, as a CNA, provides a streamlined process for open-source projects hosted on its platform to request CVEs directly through its interface, managing the entire process on behalf of the project maintainers. GitLab is also a CNA offering similar services.
• Bespoke Tools: Many larger CNAs have developed their own internal, bespoke tools to manage CVE assignments, often leveraging the REST API to fit their specific operational needs.

Quality Control and Standards Enforcement:

• CVE Naming Rules: The CVE Program maintains a set of naming rules and guidelines for formatting CVE records and descriptions. These rules are periodically revised, with a major overhaul completed in August 2023, following a multi-year effort. These changes are generally not backported to old records.
• Working Groups: Several working groups contribute to the quality and direction of the program:
• Quality Working Group (QWG): Focuses on improving the consistency and completeness of CVE records, discussing the tightening of fields and introduction of new, more specific data points. They aim for major version changes to the record format no more than every six months.
• Tactical Working Group (TWWG): Handles operational and tactical aspects of the program.
• CNA Open-Source Project Experience (COUPE): A forum for CNAs to discuss common challenges and best practices.
• AI Working Group: Addresses emerging concerns related to AI and security vulnerabilities.
• Peer Pressure and Governance: The program relies significantly on peer pressure among CNAs to maintain quality. If a CNA is found to be assigning low-quality or "garbage" CVEs (as one attendee put it), other CNAs and the community will raise concerns.
• Escalation Path: A formal process exists for addressing non-compliant CNAs:

1. Contact the specific CNA via their public contact information on cve.org.
2. If unresolved, escalate to the CNA's root.
3. If the root fails to act, escalate to the top-level root (MITRE or CISA).
4. Ultimately, issues can be escalated to the CVE Board (contactable via cve@mitre.org). The board has the authority to remove CNAs from the program, though this is a last resort after extensive attempts at communication and remediation, reflecting the program's emphasis on collaboration.

Demo / Proof of Concept

▶ Watch: The core problem: No centralized vulnerability identifiers (7:30)

The session was structured as an open forum and historical overview, and as such, it did not include a live demonstration or proof of concept of any specific vulnerability or tool. However, the panel frequently referenced the tools and processes used by CNAs. Specifically, Vulnerogram was highlighted as a key GUI-based web tool for managing CVE records, particularly useful for new CNAs to get started. The discussion also touched upon the REST API that CNAs can utilize for automated interactions, and GitHub's integrated CVE request process for open-source projects, demonstrating practical applications of the CVE framework in real-world scenarios.

Defensive Implications

▶ Watch: Birth of CVE and Scott's significant contribution (8:05)

For defenders, understanding the CVE Program's structure, evolution, and operational nuances is paramount for effective vulnerability management and proactive security. The insights from this talk provide several key implications:

1. Leverage the Federated Model: Defenders should recognize that the CVE program is no longer solely managed by MITRE. With over 450 CNAs, it's crucial to understand which CNAs are responsible for the software and services they use. For instance, if using GitHub-hosted open-source projects, direct engagement with GitHub's CNA services can provide faster access to vulnerability information. Similarly, for Microsoft products, Microsoft's CNA operations, including "Patch Tuesday," are the authoritative source.

1. Actively Monitor and Integrate CVE Data: The sheer volume of CVEs (over 40,000 in 2024, 108 daily) necessitates automated monitoring and integration of CVE feeds into security tools. While tools like Vulnerogram assist CNAs in publishing, defenders need robust systems to consume and prioritize this influx of information. Understanding the CVE record format, which is constantly refined by the Quality Working Group, helps in building more effective parsing and analysis tools.

1. Participate in the Community to Influence Standards: The panel strongly encouraged participation in CVE working groups (e.g., QWG, TWWG, AI Working Group, COUPE). Defenders who feel current CVE records lack specific details (e.g., exploitability information) or find existing tools inadequate have a direct avenue to voice concerns and contribute to solutions. This community involvement ensures that the CVE standard evolves to meet the practical needs of those on the front lines of defense.

1. Understand CVE Quality and Reporting Mechanisms: While CNAs strive for quality, the panel acknowledged instances of "garbage" CVEs or inconsistent reporting. Defenders should be aware of the community's reliance on peer pressure for quality control. More importantly, they should know the proper channels for reporting concerns about CNA behavior or CVE quality, starting with the specific CNA, then their root, then the top-level root (MITRE or CISA), and finally the CVE Board. This structured feedback loop is vital for maintaining the integrity and utility of the CVE list.

1. Proactive Vulnerability Disclosure: For organizations that develop software, becoming a CNA or partnering with one (e.g., Red Hat for open source, GitHub for GitHub-hosted projects) facilitates responsible and coordinated vulnerability disclosure (CVD). This proactive approach helps protect customers and maintains trust by ensuring patches are available before public disclosure.

1. Stay Updated on Naming Rules and Best Practices: The CVE naming rules are periodically updated. Defenders, especially those involved in internal vulnerability tracking or reporting, should regularly review these rules (available on cve.org) to ensure their internal processes align with the latest standards, preventing misinterpretations or outdated practices.

Key Takeaways

• The CVE Program has evolved from a small, manual effort in 1999 to a globally federated, community-driven standard, significantly scaling its operations to address the exponential growth in vulnerabilities.
• The transition to a federated model, particularly since 2016, empowered Certified Numbering Authorities (CNAs) to take direct responsibility for assigning CVEs, leading to record-breaking numbers of disclosures (over 40,000 in 2024).
• The program's governance relies on a hierarchical structure of top-level roots (MITRE, CISA), roots (e.g., Red Hat), and hundreds of CNAs, supported by active working groups that drive improvements in quality, automation, and scope.
• Community involvement is highly encouraged through working groups, Slack channels, and GitHub repositories, offering direct influence on the program's direction and quality control, including mechanisms for addressing non-compliant CNAs.
• Tools like Vulnerogram and the REST API have modernized CVE management, making it easier for CNAs to reserve and publish IDs, while platforms like GitHub offer integrated CVE request services for open-source projects.
• Despite challenges in maintaining consistent quality across a diverse set of CNAs, the CVE Program has endured for over 25 years as a critical, adaptable, and community-led specification for identifying and cataloging cybersecurity vulnerabilities.

About the Speaker(s)

• David Welch (Hero Devs, Moderator): As a moderator, David represents Hero Devs, a newer CNA focused on supporting end-of-life open-source software. His experience highlights the challenges and unique considerations for CNAs operating in niche areas, particularly in figuring out how to fit into the program's scope when dealing with projects that may no longer have active maintainers or CNAs of record.

• Jonathan Evans (GitHub): Jonathan is part of the GitHub team responsible for their CNA operations. He detailed GitHub's streamlined process for open-source projects to request CVEs, managing the entire disclosure process on behalf of maintainers. His perspective underscores the significant role large platforms play in facilitating vulnerability management for vast ecosystems.

• Lisa Olsson (Microsoft): Lisa contributes to Microsoft's CNA efforts, a major player in vulnerability disclosure, particularly known for "Patch Tuesday." She provided valuable statistics on CVE assignments, including Microsoft's peak of over 1,200 CVEs in 2020, and insights into the historical evolution of CNA responsibilities.

• Scott Moore (IBM): Scott is a long-standing figure in the vulnerability space, having run a vulnerability database for 30 years before moving to product security at IBM. He offered a rich historical account of his early experiences, the genesis of CVE, and was personally responsible for assigning an impressive 2.5% of all CVEs ever issued. His extensive background provided critical context on the program's origins and challenges.