1. Eight Additional Organizations Added as CVE Numbering Authorities (CNAs)
2. CVE Program Report for Quarter 1 Calendar Year (Q1 CY) 2022
4. We Speak CVE Podcast – "Researchers and PSIRTs Working Well Together"
5. For CNAs – Submitting CVE Records after CVE Service 2.x/JSON 5.0 Roll-Out
Eight Additional Organizations Added as CVE Numbering Authorities (CNAs)
Eight additional organizations are now CNAs:
- General Electric (Gas Power) for GE (Gas Power) issues only (USA)
- Go Project for vulnerabilities in software published by the Go Project, including the Go standard library, Go toolchain, and the golang.org modules (USA)
- Hitachi for Hitachi products excluding Hitachi Energy and Hitachi Vantara products (Japan)
- HYPR Corp for all HYPR products only (USA)
- Netskope for all Netskope products and services (USA)
- OpenAnolis for OpenAnolis issues only (China)
- Philips for Philips issues only (Netherlands)
- ZUSO Advanced Research Team (ZUSO ART) for vulnerabilities in third-party products discovered by ZUSO ART (Taiwan)
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 222 partners from 34 countries participating in the CVE Program. View the entire list of CNA partners on the CVE website.
CVE Program Report for Quarter 1 Calendar Year (Q1 CY) 2022
Q1 CY 2022 Milestones
6 CVE Numbering Authorities (CNAs) Added
Six new CNAs were added by the two Top-Level Roots (TL-Roots), Cybersecurity and Infrastructure Security Agency (CISA) Industrial Control Systems (ICS) and The MITRE Corporation Top-Level Root.
CISA ICS TL-Root:
- Baxter Healthcare for Baxter’s commercially available products only (USA)
- Medtronic for all products of Medtronic or a Medtronic company including supported products and end-of-life/end-of-service products, as well as vulnerabilities in third-party software discovered in Medtronic products that are not in another CNA’s scope (USA)
MITRE TL-Root:
- Citrix for Citrix issues only (USA)
- Dutch Institute for Vulnerability Disclosure (DIVD) for vulnerabilities in software discovered by DIVD, and vulnerabilities reported to DIVD for coordinated disclosure, which are not in another CNA’s scope (Netherlands)
- JetBrains for JetBrains products only (Czech Republic)
- The OpenBMC Project for vulnerabilities related to the repositories maintained by the OpenBMC project (USA)
CVE Program Expands Partnership with Google
The CVE Program announced on January 25 that it was expanding its partnership with Google for managing the assignment of CVE IDs for the CVE Program. Google is now designated as a Root for all of the Alphabet organizations that have already partnered with the CVE Program— Android, Chrome, and Google LLC—as well as any future Alphabet organizations. As a Root for Alphabet’s organizations, Google is responsible for ensuring the effective assignment of CVE IDs, implementing the CVE Program rules and guidelines, and managing the CNAs under its care. It is also responsible for recruitment and onboarding of new CNAs and resolving disputes within its scope. Go Project was added as CNA under the Google Root on April 26.
Community Updated About Upcoming Changes to CVE Record Format JSON and CVE List Content Downloads
In early January, the CVE Program announced two major changes that will take place in 2022: The main format for submission and publishing of CVE Records, CVE JSON 4.0, is being upgraded to a new, richer format: JSON 5.0. Legacy CVE List download file options are being replaced with a single supported download format: JSON. The changes were announced early to ensure CNAs, CVE consumers such as tool vendors, and other stakeholders, could begin preparing for this important transition. Updates and follow-on announcements are available here.
The Latest on Transitioning to CVE Services 2.1 and CVE JSON 5.0
A new “We Speak CVE” podcast episode was released in March to update CNAs and the community about the transition that is currently underway for CNAs to CVE Services 2.1 and CVE JSON 5.0. The discussion included how the new services and data format will enable effective and secure automation, improve workflows, and reduce the transaction costs of program participation for CNAs, as well as provide enhanced information in CVE Records for use by downstream consumers.
New CVE Program Automation Resource Now Available for CNAs
A new CVE Program Automation Website was launched on March 22 to provide CNAs with a one-stop resource to stay informed about CVE Program automation efforts, especially the upcoming transition to CVE Services 2.1 and CVE JSON 5.0. The initial launch version of the website includes a CVE Services Overview, JSON 5.0 Overview, and links to resources for both efforts. Also included are a Latest Announcements page and a CVE Automation Transition Details page for CNAs that includes transition details and deployment timelines, both of which will be regularly updated.
Q1 CY 2022 Metrics
Metrics for Q1 CY 2022 Published CVE Records and Reserved CVE IDs are included below. Annual metrics are also included in the charts for year-to-year comparisons.
Terminology
- Published – When a CNA populates the data associated with a CVE ID as a CVE Record, the state of the CVE Record is Published. The associated data must contain an identification number (CVE ID), a prose description, and at least one public reference.
- Reserved – The initial state for a CVE Record; when the associated CVE ID is Reserved by a CNA.
Published CVE Records
As shown in the table below, CVE Program production was 6,015 CVE Records for CY Q1 2022. This is a 14% increase over the previous quarter of 5,200 records published in CY Q4 2021. This includes all CVE Records published by all CNAs and the two CNAs of Last Resort (CNA-LRs).
| Year | 2022 |
| Quarter | Q1 |
| CVE Records Published by All CNAs | 6,015 |
Reserved CVE IDs
The CVE Program tracks reserved CVE IDs. As shown in the table below, 8,030 CVE IDs were in the “Reserved” state in Q1 CY 2022, a 15% increase over the previous quarter of 6,802 IDs reserved in CY Q4 2021. This includes all CVE IDs reserved by all CNAs and the two CNA-LRs.
| Year | 2022 |
| Quarter | Q1 |
| CVE IDs Reserved by All CNAs | 8,030 |
CVE IDs Reserved/CVE Records Published – Quarterly Trend by CY
Quarterly trend of reserved CVE IDs and published CVE Records by all CNAs and CNA-LRs. View as tables on the CVE Program website Metrics page.
CNA Partners Grow the CVE List
All of the CVE IDs and CVE Records cited in the metrics above are assigned and published by CNAs and the two CNA-LRs, within their own specific scopes.
CNAs join the program from a variety of business sectors; there are minimal requirements, and there is no monetary fee or contract to sign. Currently, 222 organizations from 34 countries have partnered with the CVE Program.
Learn how to become a CNA or contact one of the following to start the partnering process today:
- CISA ICS for Industrial control systems and medical devices (Top-Level Root)
- MITRE for all vulnerabilities, and Open-Source software product vulnerabilities, not already covered by a CNA listed on this website (Top-Level Root)
- Google for Alphabet organizations (Root)
- INCIBE for Spain organizations (Root)
- JPCERT/CC for Japan organizations (Root)
Share this article or comment on Medium:
CVE Blog - https://www.cve.org/Media/News/item/blog/2022/05/26/CVE-Program-Report-for-Quarter
CVE on Medium - https://medium.com/@cve_program/cve-program-report-for-quarter-1-calendar-year-q1-cy-2022-422c1174d223
Guest author Marc Ruef is the founder of VulDB, which is a CVE Numbering Authority (CNA).
Our story as a CNA is a bit different than others. But let us start at the true beginning: VulDB launched in 1997. It was a different time back then. When people were talking about vulnerabilities or exploits, they were talking about products: “Did you hear about the new wu-ftpd exploit?” Identifying issues was somehow easier because there were not that many of them, especially not the ones that really drew interest by attackers. If there was potential confusion, people were referring to version numbers of affected products or mentioned technical details such as vulnerable files or exploited functions.
When CVE was introduced in 1999, I was personally very skeptical. It sounded like a good idea, but I was doubtful that the program would be able to reach the level of technical flexibility and professionalism that would be required to add a sustainable benefit to the industry. I must admit, I was wrong to a large degree.
Extended Coverage
Over the years, CVE made a lot of things easier for us. We are a vulnerability database with a scope that is different than vendor CNAs or vulnerability catalogs covering specific product types. We add everything that can be exploited in software or hardware. We are very close to hosting 200,000 entries in our database.
Even though we share a very similar philosophy to the CVE Program, our approach slightly differs. For example, we also accept submissions for vulnerabilities in malware. That is because we think that on top of the malicious code, additional attack surfaces are introduced, which increases the risk and people should know about this. You would be surprised how much malware comes with buffer overflows, directory traversal possibilities, and permission issues.
Duplicate Handling
Due to our extended coverage, our main challenge is handling and preventing duplicates. We are very proud to have had just a handful of such duplicates in the last 25 years. In these rare cases, we use merge and forward capabilities to redirect users to the right entries. All edits are documented in a commit history, rendering changes very transparent.
Dealing with potential duplicates requires a lot of effort to verify, synchronize, and align vulnerability details. Our data team monitors thousands of sources 24/7. As soon as a new vulnerability disclosure is suspected, it is analyzed for eligibility.
At the beginning, CVE used the now obsolete CNA tag (“candidate”) to deal with new entries. We do not use such a tagging, but we do add a confidence level to every commit to help users put data into quality context. Duplicate detection became harder, again, because there are a lot of new vulnerabilities published nowadays (approximately 76 per day in 2022, compared to 40 in 2016) and many more communication channels available. In earlier days, reading mailing lists and collecting vendor advisories was enough. Today, monitoring code repositories, social media, and darknet marketplaces are even more important, especially if you want to cover zero-day vulnerabilities.
Why We Joined the CVE Program
For many years, colleagues and customers were approaching us and asked why we are not supporting the CVE Program or even becoming a CNA ourselves. We are working with CVE data daily and are aware of the importance of the program for the cybersecurity industry, as well as the demanding requirements that come with such importance.
In 2021, we decided to contact the CVE Program to discuss possibilities of a collaboration. It was very important for us to remain independent while also being a CNA. As defined in the CNA Rules, every CNA requires a specific scope. For VulDB to become a CNA, our scope needed to be broader than the CNA Rules currently defines. We discussed this issue with the CVE Program and were able to agree upon a product-independent scope. Primarily, we will assign CVEs for products not covered by other CNAs, but we are also allowed to negotiate vulnerability processing with other CNAs. If a vendor does not want to handle a vulnerability, but it is a vulnerability as defined by the CNA Rules, we may cover it. Security researchers appreciate this possibility.
The Importance of Vulnerability Management
CNA Rule 7.2, “How Many Vulnerabilities?”, defines a clear requirement for splitting and merging entries. Our own philosophy differs slightly. Not much, but enough to add another level of complexity for our data team. If there is one CVE, we might have to split it into multiple entries in VulDB or there are several CVEs available for a single entry.
Occasionally, customers want to understand the reason why we split or merge entries. We enjoy these exchanges of the philosophical nature of vulnerabilities. There is a lot of room for ideas that can enrich and improve our industry. Some examples are product assignments, version handling, risk ratings, and vulnerability class definitions, to just name a few. Projects like CPE, CVSS, CWE, and ATT&CK took the role of CVE in their respective fields. They are often not perfect solutions, but do help to introduce a common language.
Unfortunately, it is often forgotten that vulnerability management is one of the main pillars of cyber security. Perhaps because for some, it might not spark the glamorous appeal of new topics like artificial intelligence and blockchain, but for us it does. Without vulnerability management, there will be no new secure technologies.
Conclusion
Our dedicated CNA team supports our data team in processing new submissions and coordinating CVE disclosures. This re-introduced the early challenges of duplicate detection before the CVE era. But we profit from a lot of experience and optimized processes compiled over decades. We are very confident and happy to be a part of something important like the CVE Program.
Share this article or comment on Medium:
CVE Blog - https://www.cve.org/Media/News/item/blog/2022/5/17/Our-CVE-Story-VulDB
CVE on Medium - https://medium.com/@cve_program/our-cve-story-vuldb-5100dbe00834
We Speak CVE Podcast – Researchers and PSIRTs Working Well Together
The “We Speak CVE” podcast focuses on cybersecurity, vulnerability management, and the CVE Program.
Listen on YouTube, Buzzsprout, and on major podcast directories such as Spotify, Stitcher, Apple Podcasts, Google Podcasts, among others.
Researchers and PSIRTs Working Well Together
For CNAs – Submitting CVE Records after CVE Service 2.x/JSON 5.0 Roll-Out
The message below was originally communicated to CNAs by the CVE Program on May 20, 2022.
As we prepare for CVE Services 2.x/JSON 5.0 roll-out in the coming weeks, there have been a number of questions about the various methods CNAs currently use to make CVE ID reservations and publish CVE Records and which methods will continue to be supported post deployment.
This bulletin clarifies the CVE Program specific methods that will be available to CNAs for reserving CVE IDs and submitting CVE Records after CVE Services/JSON 5.0 deployment. For non-CNAs, the existing method for requesting CVE IDs will not be affected.
Non-CNA Submission Methods
Non-CNAs will continue to contact the appropriate CNA to request CVE IDs, as described on the Report/Request page on the CVE Program website. The CNA that assigns the ID will publish the CVE Record.
In addition, the CVE Program Secretariat will continue to maintain the CVE Program Request web form for non-CNAs to submit vulnerability reports.
CNA Submission Methods
For CNAs, there will be five methods to reserve CVE IDs and submit CVE Records. Some methods will be retired over time while others will have constraints, but all five methods described below will be available for use immediately after CVE Services 2.x/JSON 5.0 is deployed.
CNAs that don’t yet have a CVE Services account may contact their Root to receive account credentials ahead of deployment.
Method 1: The current CVE Program Secretariat Web Forms
This method allows CNAs to submit CVE Records in multiple formats: JSON 4.0, CSV, and flat file. For a limited time, CNAs will continue to be able to request CVE ID Reservations and publish CVE Records as they do today using the CVE Program Secretariat CVE Program Request web forms. All currently supported input formats will continue to be supported, but this method will not process JSON 5.0 formatted input.
Method 2: CVE List GitHub Submission Pilot
This method allows CNAs to submit CVE Records in JSON 4.0 using GitHub pull requests. For a limited time, CNAs will continue to be able to use the CVE List GitHub Submission Pilot to submit CVE Records in JSON 4.0, which will then be upconverted to JSON 5.0 records.
Method 3: Vulnogram
To use this method, CNAs will need to present their CVE Services User ID and authentication token through Vulnogram to identify/authenticate to CVE Services. New users, please request CVE Services credentials from your Root.
Method 4: Adopt an available CVE Services Client
Three clients are currently available for use as part of CVE Services/JSON 5.0 deployment:
· Vulnogram web-based interface (described above as Method 3)
· Red Hat command line interface – cvelib
· CERT/CC simple HTML interface – cveClient
Method 5: CNAs can develop their own clients
Please visit the Transition Details page on the CVE Program Automation website regularly for updates. You may also contact us with any comments or concerns.
Zero-day bug exploited by attackers via macro-less Office documents (CVE-2022-30190), Help Net Security
Ubuntu Users Get a Massive Linux Kernel Update, 35 Security Vulnerabilities Patched, 9 to 5 Linux
GitLab Issues Security Patch for Critical Account Takeover Vulnerability, The Hacker News
Owl Labs Patches Severe Vulnerability in Video Conferencing Devices, Security Week
CISA Warns of Medical Device Security Vulnerabilities in BD Synapsys, Pyxis Devices, Health IT Security
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-CWE-CAPEC - LinkedIn showcase page
CVE Blog - CVE website
CVE Blog on Medium - Medium
We Speak CVE - Podcast
CVEProject - GitHub
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).
No comments:
Post a Comment