Vulnerability Enumeration Conundrum – an Open Source Perspective on CVE and CWE

By:

• Andrew van der Stock (OWASP Foundation)
• Brian Fox (Sonatype, OpenSSF, FINOS, Apache Software Foundation)
• Christopher “CRob” Robinson (OpenSSF/Linux Foundation)
• David A. Wheeler (OpenSSF/Linux Foundation)
• Kate Stewart (Linux Foundation)
• Olle E. Johansson (Edvina AB, OWASP CycloneDX)
• Rob van der Veer (SIG, OpenCRE, AI Exchange)
• Starr Brown (OWASP Foundation)
• Steve Fernandez (OpenSSF)
• Steve Springett (OWASP Foundation, Ecma TC54)

Executive Summary

• Critical Vulnerability metadata programs are at risk of having their funding removed, leaving the ecosystem vulnerable and without a cohesive means to deliver coherent vulnerability information to software consumers.
• Open Source Foundations and contributors are banding together to collaboratively develop effective solutions to documenting and communicating vulnerability information around upstream open source projects.

Introduction

In recent days, the vulnerability management ecosystem has experienced shocking news that the de facto standard used throughout industry and upstream, the CVE & CWE Programs, were unexpectedly being defunded and at risk of shuttering its doors. This caused 24 hours of panic up and downstream, but that decision was quickly reversed as CISA stepped forward and continued the program sponsorship to maintain operations for the balance of the year. Even today, nearly a week later, the facts of the matter and direction to move forward are missing. 

Not having CVE IDs for newly discovered vulnerabilities  would create a cascading effect from the source code down through enterprise operations.  Tools that are the foundation of vulnerability management programs inside of organizations would fail to recognize when software was vulnerable to new attacks.  Coordination between developers and researchers and downstream providers would be complicated without having that shared understanding of what the issue really even was.  Having an identifier program that may or may not exist within the next 11 months is equally problematic to developers and downstream consumers.  Having a reliable source of truth matters when it comes to finding, fixing, and disclosing vulnerabilities.

Understanding CVE and CWE

First, let’s define what this program is about and why it matters:

Formerly standing for Common Vulnerabilities and Exposures, CVE over the last 25 years has grown to be the common vulnerability identifier that every participant in the ecosystem has used to ensure we are all talking about the same thing. A break in this chain of understanding threatens to disrupt, distract, and confuse communication and collaboration. When the meanings of the terms we use differ from project A to B or vendor X and Y, we can not all join together in the pool of shared meaning and collaborate to arm ourselves and our stakeholders to effectively take action. The simple fact that participants have had this common language to transmit information has been critical in accelerating vulnerability remediation and coordinated activities. The system has never been flawless, but through engagement by devoted community experts, we’ve been able to improve the overall experience and make the processes more open source-friendly and better for ALL consumers worldwide.

Common Weakness Enumeration, or CWE, an equally valuable identifier, helps document the root problem of the issues the CVE relates to. CVE is the WHAT behind the problem and CWE is the WHY. While not used as frequently as CVE, the analysis provided through CWE helps organizations and researchers to analyze past vulnerabilities in code, prioritize those that are especially common, and identify steps to be taken in their processes to stop these errors from being put back into the software. CWE is equally as valuable a resource and was also funded through the same program as CVE, and would have had the same fate if funding was withdrawn.

Impact of Funding Instability

The whipsawing of funding, plus recent moves by governments to create national sources of vulnerability data for their citizens, has exacerbated the trend of fragmentation, inconsistency of data, and general consumer confusion about the actual facts surrounding the eternal question, “Am I vulnerable?”

This potential fragmentation and these moves toward isolated vulnerability data sources complicate the picture for all hardware and software users, stymying methodical and accurate security research by academics and hackers, and broadly slowing defenders’ reactions once a vulnerability has been publicly disclosed. This may also open the Pandora’s box of requiring Finders, Maintainers, and Manufacturers to pre-disclose vulnerability information that could potentially be used “in the name of national security.”

The Open Source Perspective

These moves are truly the antithesis of free and open source communities. Open source communities know that we’re stronger working together. While not directly obligated in most cases to participate, typically upstream open source projects, maintainers, communities, Foundations, and the newly defined category “Open Source Software Stewards” all see the value in the open and transparent transmission of data, including when vulnerabilities are found and fixed by our upstream brothers and sisters. Having a common language, a common vulnerability enumeration so to speak, is crucial to informing our communities and downstreams when and how to take action as bugs are found and fixed.

Today developers will assign a CVE identifier as part of their support and vulnerability management process.  Some may have taken steps to become a CVE Numbering Authority (CNA) to have control over their publicly disclosed vulnerabilities.  Others may rely upon an upstream CVE provider, like Github that is a default CNA for any code stored within the repository, a root-CNA or CNA-of-last-resort such as Red Hat, or they may not directly interact with the CVE program at all or use the public web form.  This typically will happen after code or binaries are released to their community, and oftentimes tends to be a time-consuming and manual process for projects without dedicated security contributors. These manual steps take the developer out of their coding environment, reducing their efficiency and ability to deliver features or address bugs.

CWE is typically not something that upstream developers are aware of or work with, but is very important for longer-term research and understanding of common coding errors. Methodologies such as OpenCRE (Open Common Requirements Enumeration) help developers use electronically-documented requirements based on security standards and guidelines together at the level of requirements into one harmonized resource based upon CWE. This helps projects avoid common coding mistakes while the software is being written instead of being bolted on at the end of a release cycle through a scanner.  CVE and CWE fuels researchers and helps security scanners recognize these weaknesses and ideally if integrated with a project’s SDLC practices and CI/CD pipelines can catch these security problems before they become escapes.

Open Source is not a monolith. We all don’t act and think identically, we all serve different communities and needs, but we all hold certain core values near and dear to our hearts, generally defined here (there are many similar examples available, but foundationally all are variants on the “Four Freedoms”). We also all continually talk to and collaborate with each other within our communities, projects, and ecosystem efforts. To this end, we can unequivocally state:

• Essentially, all upstreams desire a simple, efficient, and developer-friendly means of documenting and sharing information about vulnerabilities found in our upstream code with our downstream and the broader ecosystem. We also hate rework and inefficiency, so any solution that comes about needs to be “done upstream once, reused downstream many”
• We are willing to collaborate on a solution, but bear in mind that upstream isn’t your employee (generally); our motivations are many and varied, and the creative talents of the engineers toiling away on upstream code are done and given away freely. We require that if downstream cares, they MUST be willing to work upstream to assist in implementing changes.
• Any solution MUST respect the diversity in tooling and process or upstream communities, and be easily integrated into developer workflows to be effectively adopted.
• Any vulnerability information published does not belong to a certain geography or jurisdiction. It has to be freely available worldwide.

Moving Forward Together

Groups like OWASP, the OpenSSF, and our communities of upstream open source security community members pledge to participate in a solution to help support and stabilize the ecosystem and provide ALL consumers of software with clear and accurate information, including some form of universal identifier to help track vulnerabilities as they are discovered, reported, and corrected. Efforts have been underway for quite some time thinking about this precise problem before the recent CVE Program episode. Leaders across upstream, including representatives from Apache Foundation, Eclipse Foundation, Linux Foundation/OpenSSF, OWASP Foundation, and many other foundations and community members, have been discussing, prototyping, and working on how we as a unified community can work to best serve our members, developers, and downstreams. 

We are joining together to collaborate on how these things can be done together in an open source way. The OpenSSF, OWASP and others have been discussing options that open source could take to maintain our own data in a free and open manner for the benefit of all.  We welcome the opportunity to participate with the ecosystem in an effective, neutral, global solution so that everyone, up and downstream, can have free and open access to the right information, at the right time, to be able to address the risks that come from software vulnerabilities. Working with our open source peers, we will be creating a forum where our communities can gather and collaboratively develop a path forward together.

About the Authors

Andrew van der Stock, Executive Director, OWASP Foundation: Andrew is a seasoned web application security specialist and enterprise security architect. He is the Executive Director at OWASP, taking the Foundation through organizational change and taking our mission to the next level. Andrew has worked in the IT industry for over 25 years. Andrew has researched and developed the web application security and architecture fields since 1998. He is a Lifetime member of OWASP, former Director, and co-leads the OWASP Application Security Verification Standard and OWASP Top 10 projects. He lives in Australia with his family.

Brian Fox, Board Member: OpenSSF & FINOS. Member: Apache Software Foundation,  Co Founder & CTO: Sonatype: Brian Fox, Co-founder and Chief Technology Officer at Sonatype, brings over 20 years of hands-on experience driving software development for organizations of all sizes, from startups to large enterprises.

A recognized figure in the Apache Maven ecosystem and a longstanding member of the Apache Software Foundation, Brian has played a crucial role in creating popular plugins like the maven-dependency-plugin and maven-enforcer-plugin. His leadership includes overseeing Maven Central, the world’s largest repository of open-source Java components, which recently surpassed a trillion downloads annually.

As a Governing Board member for the Open Source Security Foundation, Brian actively contributes to advancing cybersecurity. Working with other industry leaders, he helped create The Open Source Consumption Manifesto, urging organizations to elevate their awareness of the Open Source Software (OSS) components they use. Brian has also chaired efforts to provide official responses to requests for information from the Open Source National Cybersecurity Directorate (ONCD) and the Cybersecurity and Infrastructure Security Agency (CISA), emphasizing his practical role in shaping the future of Open Source Cyber Security efforts.

Christopher “CRob” Robinson, Chief Architect, OpenSSF/Linux Foundation: Christopher Robinson (aka CRob) is the Chief Security Architect for the Open Source Security Foundation. With over 25 years of Enterprise-class engineering, architectural, operational and leadership experience, CRob has worked at several Fortune 500 companies with experience in the Financial, Medical, Legal, and Manufacturing verticals, and spent 6 years helping lead the Red Hat Product Security team as their Program Architect.

He enjoys hats, herding cats, and moonlit walks on the beach.

David A. Wheeler, Director of Open Source Supply Chain Security, OpenSSF/Linux Foundation: Dr. David A. Wheeler is an expert on open source software (OSS) and on developing secure software. His works on developing secure software include the Open Source Security Foundation (OpenSSF) “Developing Secure Software” course and “Fully Countering Trusting Trust through Diverse Double-Compiling (DDC)”. He is the Director of Open Source Supply Chain Security at the Linux Foundation and teaches a graduate course in developing secure software at George Mason University (GMU). Dr. Wheeler has a PhD in Information Technology, a Master’s in Computer Science, a certificate in Information Security, a certificate in Software Engineering, and a B.S. in Electronics Engineering, all from George Mason University (GMU). He is a Certified Information Systems Security Professional (CISSP) and a Senior Member of the Institute of Electrical and Electronics Engineers (IEEE). He lives in Northern Virginia.

Kate Stewart, VP Dependable Embedded Systems/ The Linux Foundation, SPDX Technical Committee co-lead;  OpenSSF SBOM Everywhere co-lead: Kate works with the safety, security and license compliance communities to advance the adoption of best practices into embedded open source projects. Since joining the foundation ten years ago, she has launched the Zephyr and ELISA Projects, among others. 

Kate was one of the founders of SPDX in 2009, and is currently the technical team co-lead. 

She has been active in the multistakeholder efforts to define SBOM minimum elements hosted by NTIA and more recently updated by CISA in 2024.   She’s been active in the OpenSSF SBOM Everywhere SIG. 

Kate has been working with the Zephyr security community since it’s inception to adopt Open Source Security best practices, including the gold best practices badge, automatic SBOM generation, formation and operation of PSIRT team, and being a CVE Numbering Authority.

Olle E. Johansson, Edvina AB, Sweden – OWASP CycloneDX contributor: Olle E. Johansson (oej) is a consultant in the area of real-time communication and in embedded system security. He has been active in Open Source for many years as a developer, evangelist, trainer, and speaker in many conferences worldwide. Olle is a member of the OWASP SBOM Forum and the OWASP CycloneDX industry working group. He is currently working on the CycloneDX Transparency Exchange API standard (Koala).  In the past, Olle was an active core developer in the Asterisk.org project, co-founder of the Astricon conference and creator of the Asterisk certifications and trainings. He has been a contributor to the Kamailio.org open source SIP proxy for many years and still runs many in-house trainings and workshops in SIP and Kamailio.  Olle is also a project leader for the Swedish DNS TAPIR project that is building OpenSource software for analysing DNS resolver logs and finding bad actors. Olle is the founder and CEO of Edvina AB, founded in 1987.

Rob van der Veer,SIG, the Netherlands, OpenCRE co-founder, AI Exchange founder: Rob van der Veer has been in security and AI for 33 years. He founded the OWASP AI Exchange flagship project and co-founded Opencre.org. Rob is a key contributor to ISO 5338, 27090, and co-editor of the AI Act security standard. At the Software Improvement Group, he is Chief AI Officer.

Starr Brown, Director of Open Source Programs & Projects, OWASP Foundation: Starr Brown has a 25+ year track record in our industry, being the Executive Director of XR Village, a Principal Consultant of a penetration testing firm who ran cyber CTFs and education programs, an ex-CIO and ex-COO with deep project management, contracts, grants, IT innovation, and risk management experience. She lives in Atlanta, GA with her dogs and is a serial volunteer with local hacker groups, mentees, and other underdogs.

Steve Fernandez, General Manager OpenSSF: Before joining OpenSSF, Steve was at NCR as the Chief Transformation Officer with responsibility to split the entity into two new companies. He led the effort and upon successful completion became the CIO for NCR Voyix leading all technical aspects of the company.  Steve is currently a director for Juniper Networks and serves on the governance committee.

Steve has also served as AIG’s Global Chief Technology Officer, responsible for leading technology vision and operations of the enterprise. He was the Global Chief Technology Officer at L’Oréal in Paris, France, where he led the global digital transformation from legacy footprints to cloud, created a modern digital workplace for employees, and successfully developed a technical culture focused on agility, speed and professional results. Prior to L’Oréal, he was Chief Information Officer at Conisus, LLC and Chief Technology Officer for The Coca-Cola Company, Bottling Investments Group. Steve has held several technology leadership positions at General Electric and Ford Motor Company as well.

Steve Springett, Chair OWASP CycloneDX and Ecma TC54, Vice Chair OWASP Global Board of Directors: Steve Springett is dedicated to helping organisations identify and reduce risks associated with the software supply chain. He is a strong advocate for open-source solutions and serves in several leadership roles, including as Project Leader for OWASP Dependency-Track, Co-Leader of the OWASP Software Component Verification Standard (SCVS), Chair of the OWASP CycloneDX Core Working Group, and Chair of Ecma International Technical Committee 54 (TC54).

He also serves as Vice Chair of the OWASP Foundation Board of Directors, where he contributes to the strategic growth of the Foundation and the advancement of its mission—to make secure software a reality through open collaboration, education, and innovation.