Getty Images/iStockphoto
Why cloud bugs don't get CVEs, and why it's an issue
Lack of public disclosures for cloud bugs can allow vendors to sit on vulnerability reports and can prevent researchers from getting acknowledgement and payouts.
A key difference in the way cloud computing and on-premises security bugs are handled is creating a rift between researchers and cloud service providers.
First issued in 1999, Common Vulnerabilities and Exposures (CVE) entries are public notices that are issued when a security flaw is patched or made public. The entries contain details about a vulnerability and the possible consequences of exploit, as well as the name of the researcher who is credited with the discovery.
Intended to provide administrators with the necessary information for prioritizing and deploying patches, the CVE system was devised at a time when nearly all enterprise software was running on premises.
Enter cloud services in the 2010s. As the vendors themselves remotely host and manage the applications and data, there is no need for patches to be kicked out to end users.
"Our vulnerability research ecosystem comes from a time when virtually all versions of software were packaged and delivered to customers and executed independently on potentially millions of computers, and the goal has been to have all of those individual computers running uniform code with bug fixes," Cloud Security Alliance CEO Jim Reavis told SearchSecurity.
"With cloud you have millions of customers mashing up an infinite number of internal and SaaS applications and likely introducing a massive number of unreported vulnerabilities directly through compiled code and indirectly through the use of APIs."
Because of this, the CVE Numbering Authorities (CNAs) opt not to issue security vulnerabilities on cloud services with CVE designations, due to the fact that in many cases there simply is nothing for administrators or end users to do about the problem.
"One of the biggest differences for that community is who takes action," Dustin Childs, communications director of the Trend Micro Zero Day Initiative, said in an email.
"CVEs are designed to let recipients know that they may need to take action to fix or mitigate. In the case of cloud software vulnerabilities, the user generally has no actions and couldn't take any actions if they wanted to (other than in rare cases where they can mitigate by disabling some functionality, etc.)"
While this is not an issue for most administrators and end users on its surface, the practice has caused some problems for researchers and could have an impact on user data for a number of reasons.
Cloudy with a chance of conflict
Recently, several infosec experts have said the lack of cloud CVEs is a detriment to enterprise security teams, users and the security research community. Concerns about the discrepancy emerged this summer following the disclosure of the "ChaosDB" bug in Azure's Cosmos DB, which was discovery by cloud security vendor Wiz.
While Microsoft publicly disclosed the ChaosDB bug along with Wiz, other cloud providers with similar critical flaws might not. Experts such as independent security research Kevin Beaumont noted on Twitter that the "massive gap in cloud security" leaves external researchers as the only reliable source of information about cloud vulnerabilities.
For many security researchers, getting credited in a CVE vulnerability report is a major positive for their careers. Having a list of CVE credits acts as a sort of resume for bug hunters, allowing them to get public recognition and as a result boost their reputation within the community and improve their chances of finding more lucrative work.
That is not to say that every person who hunts for bugs is simply seeking to gain fame and fortune, experts note.
"While some are incentivized by the award of CVEs, security researchers have differing motivations for reporting vulnerabilities," Childs said.
"Public recognition and financial compensation also provide significant incentives for those disclosing bugs to vendors."
Why cloud CVEs matter
What should be more concerning to enterprises, however, is the possibility that the lack of designation can allow companies to sit on bugs. With the cloud providers being able to sit on bugs that are not being reported by a third party, patches can potentially be put off, placing researchers in a tough position.
"Sometimes a vulnerability requires a user's action, and there is no way to discuss it," said Nir Ohfeld, a senior security researcher with Wiz.
"If there is not a name to a vulnerability, you have no way to communicate it verbally, and you don't ever know if you are exposed."
The lack of public disclosure with vulnerabilities is not unique to cloud services. For years now, on-premises software vendors have also been frustrating researchers by using various methods to delay patches or get out of public acknowledgement.
The issue has gotten so bad that some bug hunters have considered simply selling their vulnerability finds to third parties who could end up using them for zero-day attacks.
"No vendor has an obligation to disclose bug details regardless of the product or service being on prem or in the cloud," says Childs.
"However, our experience is that transparency wherever possible is best for all involved. Vendors who do not publicly disclose flaws or publicly acknowledge researchers will likely find themselves worse off than those who do."
What is being done
While there remain a number of issues with the way cloud flaws are reported and disclosed, there are already efforts being made to remedy the issue, both in the form of updates to the CVE system and work on a new cloud-friendly vulnerability disclosure method called a Universal Vulnerability Identifier.
The UVI system looks to be a faster, more accessible system that would also cover the unique circumstances that open source and cloud computing services present when it comes to security flaws. During a Black Hat 2021 session, Wiz researchers also called for a new cloud CVE system.
The hope is that by reworking disclosures to better take into account the cloud compute model, vendors and researchers can both be appeased, resulting in more transparency and clarity for their admins and security professionals.
"We believe that in order to tackle this problem we need to have standards and systems that enable rapid issuance of trusted vulnerability identifiers on demand that can be expanded upon 'wiki-style' over time," Reavis explained.
"These discovered vulnerabilities will be enhanced with richer information as we learn more, cross-referenced with other vulnerabilities, even linked to actual CVEs or proprietary vulnerability databases."
SearchSecurity writer Alexander Culafi contributed to this story.
