1. 31 Additional Organizations Added as CVE Numbering Authorities (CNAs)
2. CVE Community Members Publish Articles About the CVE Program
4. CVE Program Expands Partnership with Red Hat
5. New CVE Board Member from Red Hat
6. Introducing the CNA Mentoring Program
7. The Value of Assigning CVEs
31 Additional Organizations Added as CVE Numbering Authorities (CNAs)
Thirty-one additional organizations are now CNAs:
1) Baicells Technologies Co., Ltd. is now a CVE Numbering Authority (CNA) for all Baicells products (China)
2) Bugcrowd Inc. for vulnerabilities discovered by researchers in collaboration with Bugcrowd, with approval of Bugcrowd’s clients, and not in the scope of another CNA (USA)
3) Crestron Electronics, Inc. for Crestron products (USA)
4) CyberArk Labs for CyberArk products and vulnerabilities discovered by CyberArk Labs that are not within another CNA’s scope (Israel)
5) Dragos, Inc. for Dragos products and third-party products it researches related to operational technology (OT)/industrial control systems (ICS) not covered by another CNA (USA)
6) Dual Vipers LLC for Dual Vipers projects and products (both open and closed source), as well as vulnerabilities in third-party software discovered by Dual Vipers that are not in another CNA’s scope (USA)
7) FULL INTERNET for all FULL products, as well as vulnerabilities in third-party software discovered by FULL that are not in another CNA’s scope (Brazil)
8) GE Healthcare for GE Healthcare products (USA)
9) Green Rocket Security Inc. for Green Rocket Security products including EOL unless covered by another CNA’s scope (USA
10) Hallo Welt! GmbH for BlueSpice vulnerabilities only (Germany)
11) Hitachi Vantara for all Hitachi Vantara products and technologies (USA)
12) HashiCorp Inc. for all HashiCorp products and projects unless covered by another CNA’s scope (USA)
13) Honeywell International Inc. for all Honeywell products (USA)
14) Honor Device Co., Ltd. for vulnerabilities in Honor products and services unless covered by the scope of another CNA (China)
15) KrakenD, S.L. for KrakenD EE, KrakenD CE, and Lura issues only (Spain)
16) KNIME AG for all vulnerabilities on software products that our company provides, including KNIME Analytics Platform, KNIME Server, and KNIME Hub (Switzerland)
17) The Missing Link Australia (TML) for the TML vulnerability disclosure policy that applies to any third-party vendor products to whom TML will assign the CVEs for vulnerabilities, if the product is not a part of another CNA scope (Australia)
18) National Cyber Security Centre - Netherlands (NCSC-NL) for vulnerabilities in software discovered by NCSC-NL, and vulnerabilities reported to NCSC-NL for coordinated disclosure, which are not in another CNA’s scope (Netherlands)
19) National Cyber Security Centre SK-CERT for vulnerabilities in software discovered by National Cyber Security Centre SK-CERT, and vulnerabilities reported to National Cyber Security Centre SK-CERT for coordinated disclosure, which are not in another CNA’s scope (Slovak Republic)
20) NetRise for vulnerabilities in third-party Extended Internet of Things (XIoT) devices and firmware NetRise researches that are not covered by another CNA (USA)
21) OpenCloudOS Community for OpenCloud OS issues only, not including EOL products, unless covered by another CNA’s scope (China)
22) OpenHarmony for OpenHarmony issues only (China)
23) openGauss Community for openGauss issues only (China)
24) ONEKEY GmbH for all ONEKEY products and vulnerabilities in third-party software discovered by ONEKEY that are not in another CNA’s scope (Germany)
25) The OpenNMS Group for OpenNMS issues only (USA)
26) Rockwell Automation for all Rockwell Automation products (USA)
27) SailPoint Technologies for SailPoint issues only (USA)
28) Seagate Technology for any Seagate or LaCie software or hardware, open or closed source, supported and end of life, as well as any vulnerabilities in third-party software discovered by Seagate that are not in another CNA’s scope (USA)
29) senhasegura for vulnerabilities in senhasegura products, and other vulnerabilities discovered by senhasegura that are not in another CNA’s scope (Brazil)
30) Unisoc (Shanghai) Technologies Co., Ltd. for Unisoc issues only (China)
31) Zowe for vulnerabilities in Zowe.org open-source projects (USA)
CNAs are organizations from around the world that are authorized to assign CVE IDs to vulnerabilities affecting products within their distinct, agreed-upon scope, for inclusion in first-time public announcements of new vulnerabilities.
There are currently 254 partners from 35 countries participating in the CVE Program. View the entire list of CNA partners on the CVE website.
CVE Community Members Publish Articles About CVE
Members of the CVE community have recently published articles about the CVE Program:
“Ancient CVEs Can Cause You Problems” by CVE Board Member Kent Landfield
In this article on the Trellix Blog, Kent discusses the problems that can result from relying on vulnerability severity scores to determine prioritization for patching CVEs.
“5 Myths about CVEs” by CVE Automation Working Group (AWG) Member Madison Oliver
In this article on The New Stack, Madison discusses a “series of myths have emerged around CVEs that give them a bad reputation, which spawns hesitation to report and increases the odds that vulnerabilities will go undetected.”
“An Inside Look at What Makes the CVE Program Tick” by CVE Board Member and CNA Coordination Working Group Chair (CNACWG) Tod Beardsley
In this article on SCMagazine, Tod “offers an overview of the CVE Program and its importance to security organizations” from his unique position as CVE Program insider.
“Removing the stigma of a CVE” by CVE Automation Working Group (AWG) Member Madison Oliver
In this article on the GitHub Security Blog, Madison answers the question: “Do you worry that a CVE will hurt the reputation of your project? In reality, CVEs are a tracking number, and nothing more. Here's how we think of them at GitHub.”
here exists a myth that the CVE® Program does not assign CVE IDs and publish CVE Records for vulnerabilities affecting cloud services. This myth has propagated on social media, repeated over and over again by those who really believe it. In fact, the CVE Program has and does assign CVE IDs and publish CVE Records for vulnerabilities affecting cloud services.
The CVE Rules are publicly available. Rule 7.4.4 states:
7.4.4 CNAs MAY assign a CVE ID to a vulnerability if:
- The product or service is owned by the CVE Numbering Authority (CNA)
- The product or service is not customer controlled, and
- The vulnerability requires customer or peer action to resolve
The CVE Board is responsible for the strategic direction, governance, operational structure, policies, and rules of the CVE Program. Both the CVE Board’s and the CVE Program’s goal is to ensure that users can take action to protect themselves against vulnerabilities. When a vulnerability does not require customer action, issuing a CVE generates a high volume of unactionable noise for users instead of a high-fidelity signal that they can act upon. At the request of participating cloud service providers (CSPs), the Board changed the CVE Program rules over two years ago, to enable CVE ID assignment and record publication for vulnerabilities affecting cloud services.
For example, consider a SQL injection discovered in a content management system hosted as a cloud service. The CSP can completely remediate the SQL injection and determine, based on analysis, that the issue was never exploited and hence no customer action is required. Assigning a CVE ID to such an issue offers little or no value.
On the other hand, the CSP may decide to recommend all consumers change the API keys that could have leaked as a result of the vulnerability and issue an advisory. Assigning a CVE ID helps the CSP and the consumers with a unique identifier that can be used in all communication and to track the remediative action of changing API keys.
While the rules allow CVE Numbering Authorities of Last Resort (CNA-LRs) to assign CVE IDs and publish CVE Records for other kinds of vulnerabilities, they require that any CVE ID and associated record for vulnerabilities affecting cloud services be initiated only by CSPs that participate in the CVE Program. CNA-LRs are organizations authorized within the CVE Program to assign CVE IDs and to create and publish CVE Records for vulnerabilities not covered by the scope of another CNA. A CNA-LR may assume responsibility for assigning a CVE ID and publishing the associated CVE Record based on policies defined by the CVE Program.
The Board chose to define the rules for vulnerabilities affecting cloud services because cloud solutions are intrinsically different from on-prem solutions.
CVE IDs assigned to vulnerabilities in traditional or on-prem software can be scrutinized by the community based on the information about affected versions and public references available. Public references to the vulnerability are a prerequisite for CVE Record publication. This prevents mistaken or incorrect assignments from adding noise to the vulnerability management and remediation ecosystem.
Vulnerabilities in cloud services do not easily lend themselves to such public scrutiny unless the CSP is transparent about them. If a cloud vulnerability has not yet been fixed, there may often be no way for a third party to test for its existence without risking disruption of production services or violating terms of use of the service. Similarly, if a cloud vulnerability has been fully fixed, then there also may be no way for a third party to verify it existed.
Due to these reasons, the CVE Board decided to strike a balance to leave the assignment of CVE IDs to cloud vulnerabilities to the judgment of the CSP. CNA-LRs cannot assign CVE IDs to cloud vulnerabilities because they lack visibility into many aspects that are required to identify the vulnerability.
In addition, a CVE ID assigned to a cloud service must be tagged as being assigned to an “exclusively-hosted-service” to help users easily recognize CVE IDs assigned to vulnerabilities affecting cloud services.
The CVE Board is continually evaluating how to best address the issue of vulnerabilities affecting cloud services. The current approach is imperfect. Creating many additional thousands of inactionable CVE Records is also imperfect. Stay tuned for additional blogs and potential rule changes related to cloud and other issues.
Share this article or comment on Medium:
CVE Blog - https://www.cve.org/Media/News/item/blog/2022/09/13/Dispelling-the-Myth-CVE-ID
CVE on Medium - https://medium.com/@cve_program/dispelling-the-myth-cve-id-assignment-and-record-publication-for-vulnerabilities-affecting-cloud-6d1937a34f1c
CVE Program Expands Partnership with Red Hat
The CVE® Program is expanding its partnership with Red Hat, Inc. for managing the assignment of CVE Identifiers (CVE IDs) for the CVE Program for open source.
Red Hat is now designated as a Root for any open-source organizations that choose Red Hat as their Root. However, organizations are free to choose another Root if it suits them better.
As a Root, Red Hat is responsible for ensuring the effective assignment of CVE IDs, implementing the CVE Program rules and guidelines, and managing the CVE Numbering Authorities (CNAs) under its care. It is also responsible for recruitment and onboarding of new CNAs and resolving disputes within its scope.
A CNA is an organization responsible for the regular assignment of CVE IDs to vulnerabilities, and for creating and publishing information about the vulnerability in the associated CVE Record. Each CNA has a specific scope of responsibility for vulnerability identification and publishing. Currently, Google, JPCERT/CC, Red Hat, and Spanish National Cybersecurity Institute (INCIBE) are Roots under the MITRE Top-Level Root. There are currently 254 organizations from 35 countries actively participating in the CVE Program.
Red Hat’s Root designation expands the CVE Program options for open-source organizations and projects when selecting a Root.
Read the Red Hat press release.
Share this article or comment on Medium:
CVE Blog - https://www.cve.org/Media/News/item/blog/2022/09/07/CVE-Program-Expands-Partnership-with
CVE on Medium - https://medium.com/@cve_program/cve-program-expands-partnership-with-red-hat-c1e14a67001f
New CVE Board Member from Red Hat
Peter Allor of Red Hat, Inc. has joined the CVE Board.
The CVE Board is the organization responsible for the strategic direction, governance, operational structure, policies, and rules of the CVE Program. The Board includes members from numerous cybersecurity-related organizations including commercial security tool vendors, academia, research institutions, government departments and agencies, and other prominent security experts, as well as end-users of vulnerability information.
Introducing the CNA Mentoring Program
The CNA Coordination Working Group (CNACWG) has introduced a mentoring program for new CVE Numbering Authorities (CNAs). Participants signup using a simple Google form (no login required) and the CNACWG makes the match, at which point all communications are then solely between the mentor and mentee. The mentoring program is as little or as much work as those participating would like it to be and can focus on whatever questions or guidance a new CNA wants or needs.
If you’re interested in learning more:
- Read “The CNA Mentoring Program” by CNACWG chair Tod Beardsley on the CVE Blog
- Listen to Tod on the We Speak CVE podcast in “CNA Mentoring Program: Members Helping Members” as he chats about how CVE is a community, the many ways in which mentoring can help new CNAs be successful, and much more
In addition, CVE Numbering Authority (CNA) scopes, disclosure policies, turnaround times, and more are discussed in general, as are GitHub’s specific CNA processes and how it helps open-source projects hosted on GitHub with their CVEs and advisories.
Madison also writes about many of these topics in her blog article, Removing the Stigma of a CVE, on the GitHub Blog.
The “We Speak CVE” podcast focuses on cybersecurity, vulnerability management, and the CVE Program.
Keeping Up with CVE
Follow us for the latest from CVE:
@CVEnew - Twitter feed of the latest CVE Records
@CVEannounce - Twitter feed of news and announcements about CVE
CVE Program - LinkedIn page
CVE-CWE-CAPEC - LinkedIn showcase page
CVE Blog - CVE website
CVE Blog on Medium - Medium
We Speak CVE - Podcast
CVEProject - GitHub
CVE Services 2.1/CVE JSON 5.0 Transition Website - GitHub.io
CVE Program Channel - YouTube
CVE Announce Newsletter - Email
If this newsletter was shared with you, subscribe by sending an email message to LMS@mitre.org with the following text in the SUBJECT of the message: “subscribe cve-announce-list” (do not include the quote marks). You may also subscribe on the CVE website at https://cve.mitre.org/news/newsletter.html. To unsubscribe, send an email message to LMS@mitre.org with the following text in the SUBJECT of the message “signoff cve-announce-list” (do not include the quote marks).
