No Action Required: CVE for Software as a Service

No Action Required: CVE for Software as a Service

Speakers: Don Bailey (AWS), Mike Cotay (Google), Lisa Olsen (Microsoft), Art Coviello (Moderator)

Conference: VulnCon

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

Overview

This talk, "No Action Required: CVE for Software as a Service," delves into the evolving landscape of vulnerability management and disclosure in the age of cloud computing. Moderated by Art Coviello, the panel features industry experts Don Bailey from AWS, Mike Cotay from Google, and Lisa Olsen from Microsoft, who bring firsthand experience from major cloud service providers (CSPs). The core discussion revolves around the assignment of Common Vulnerabilities and Exposures (CVE) identifiers for vulnerabilities found in Software as a Service (SaaS) environments, particularly those where the cloud provider autonomously remediates the issue, ostensibly requiring "no action" from the customer.

The talk addresses critical questions about the relevance and utility of CVEs in a SaaS context, especially following significant changes to the CVE Numbering Authority (CNA) rules in August 2024. These rule updates, transitioning from CVE 3.0 to 4.0, aim to provide clearer guidance on when and how CSPs should assign CVEs for cloud-specific vulnerabilities. The panelists explore the practical implications of these rules, the challenges of defining "no action required," the role of customer agency, and the broader benefits of transparency and information sharing within the security ecosystem. This discussion is vital for understanding how vulnerability information is managed and communicated in an environment where traditional patching models no longer apply, and how both providers and customers can navigate this complex domain to enhance overall security postures.

Background

▶ Watch: Introduction: CVEs for cloud services requiring no user action (0:00)

The proliferation of Software as a Service (SaaS) has fundamentally altered the paradigm of vulnerability management. Unlike on-premises software, where users are responsible for patching and updates, SaaS vulnerabilities are typically fixed by the provider, often with little to no direct action required from the end-user. This rapid, widespread patching capability is a significant advantage of cloud services, offering instantaneous protection across a vast user base. However, this model introduces complexities for the traditional CVE program, which was originally designed for discrete software products requiring user-initiated updates.

Recognizing this shift, the CVE CNA rules underwent significant changes, with the transition from CVE 3.0 rules to CVE 4.0 rules technically implemented in August 2024. Under the older 3.0 rules, only the cloud service provider acting as a CNA was authorized to assign a CVE ID and publish for their own service. This created a narrow scope for official vulnerability tracking in the cloud. The updated 4.0 rules broadened this significantly, stating that a CNA should publish and disclose a CVE if the vulnerability "can cause significant harm" or "requires action or risk assessment or action by parties other than the CNA in question." Crucially, the 4.0 rules also stipulate that CNAs must not refuse to assign a CVE based solely on the type of technology (e.g., declaring a blanket "never assign for cloud" policy). A new tag, exclusively hosted service, was also introduced for CVE records, though its definition is narrow, applicable only when everything in the record pertains solely to a hosted service. Currently, between 51 and 61 records in the CVE database utilize this tag.

The panelists bring direct experience to this evolving landscape. Don Bailey, a foundational member of the AWS security team and an intern who helped launch CVE in 1999, has been deeply involved in AWS's security bulletin processes and CVE discussions. Lisa Olsen, from Microsoft's MSRC (Microsoft Security Response Center) and a CVE board member since 2018, played a pivotal role in shaping both the 3.0 and 4.0 CVE rules, particularly concerning cloud situations. Mike Cotay, leading Google's bug bounty program, recently spearheaded Google's initiative to start publishing CVEs for all critical vulnerabilities in Google Cloud, highlighting a major shift in their internal policy. The panel's collective experience underscores the challenges in defining clear, consistent criteria for CVE assignment in a dynamic cloud environment, especially when dealing with deeply embedded internal components that may lack recognizable product names or clear customer action requirements.

Key Findings

▶ Watch: Explaining CVE CNA rule changes (3.0 to 4.0) for cloud (1:20)

The discussion revealed several key findings regarding CVE assignment for SaaS vulnerabilities:

• "No Action Required" is Nuanced: While CSPs often state "no action required" for customers, implying automatic remediation, panelists clarified that this means customers do not need to patch or upgrade. However, it does not necessarily preclude the need for customers to perform risk assessments, review logs (e.g., CloudTrail, CloudWatch), or undertake incident response actions based on the vulnerability. AWS, for example, issues CVEs if a customer might need to perform a risk assessment, even if no direct technical action is needed. This concept is termed "customer agency."
• SaaS Patching is Not Instantaneous: Contrary to the perception of immediate fixes, Lisa Olsen emphasized that rolling out fixes for cloud vulnerabilities involves significant deployment efforts across multiple cloud regions, making the process far from instantaneous from the provider's perspective.
• The "Software Naming Problem" Hinders CVEs: A significant challenge arises when vulnerabilities are found in deeply embedded, internal cloud components that lack a recognizable product name. Microsoft's MSRC, for instance, struggles to assign CVEs in such cases, as a CVE requires a clear product reference for customers to understand its relevance.
• Customer Protection is Paramount: All three CSPs reiterated that their primary focus is protecting their customers, whether through direct communication, automated remediation, or specific guidance. CVE assignment is considered an additional layer, primarily serving broader ecosystem transparency, rather than the immediate mechanism for customer protection.
• CVEs Benefit the Ecosystem, Not Always Direct Customers: While direct customer engagement (e.g., health dashboards, emails, APIs) is the most effective way to inform customers, CVEs play a crucial role for the wider security community. They enable researchers to learn from common problems across providers, enhance industry transparency, and feed into vulnerability management tools and services used by other organizations. Google cited an example where a critical vulnerability they fixed could inform competitors using similar technology.
• Regulatory Compliance vs. CVE Mandates: While CSPs adhere to numerous compliance regimes (e.g., FedRAMP) that may mandate reporting specific events to customers, these regimes typically do not directly mandate CVE assignment. CVEs are separate from, though sometimes intersect with, these reporting requirements.
• CNA Agency and Consistency: AWS decided to become its own CNA to "own the conversation" about its vulnerabilities. This allows them to ensure consistency in how CVEs are assigned and communicated, rather than relying on third parties to define the scope and impact of AWS-specific issues.
• Bug Bounty Programs and Disclosure: The panelists discussed the dynamics of coordinated vulnerability disclosure (CVD). AWS maintains a private bug bounty program with NDAs for participants, arguing this is appropriate for contracted research activities involving pre-release information, while asserting that customer protection occurs regardless. Google, conversely, allows researchers to decide disclosure timing after a 90-day grace period, viewing public disclosures as beneficial for the community once fixes are in place.

Technical Deep Dive

▶ Watch: Introduction of the 'Exclusively Hosted Service' CVE tag (2:50)

The core of the technical discussion revolved around the CVE Program rules and their application to cloud services. The shift from CVE 3.0 to CVE 4.0 rules, effective August 2024, was a pivotal point. Previously, under 3.0, only the cloud service provider acting as a CNA could assign a CVE ID for its service. This often left a gap for vulnerabilities discovered by external researchers or in components without a clear "product" owner.

The 4.0 rules significantly expanded this. A CNA is now encouraged to publish a CVE if the vulnerability:

1. Can cause significant harm.
2. Requires action or risk assessment by parties other than the CNA.
3. The decision to assign must not be based solely on the type of technology (e.g., "we never assign for cloud" is no longer acceptable).

This shift acknowledges the diverse nature of cloud vulnerabilities, which can range from Infrastructure as a Service (IaaS) to Platform as a Service (PaaS), Software as a Service (SaaS), and even devices or outposts (cloud infrastructure running on-premises). Amazon, for example, operates a CNA that covers the entirety of Amazon's offerings, including devices, to ensure comprehensive coverage.

Panelists described their internal processes for CVE assignment. Google’s approach is to publish CVEs for all critical vulnerabilities in Google Cloud, often in response to researcher reports that meet a minimum "medium" bar for impact. Microsoft's MSRC grapples with the complexity of assigning CVEs for an "incredible volume" of cases, emphasizing two key criteria:

1. Ensuring every customer is protected before disclosure.
2. The vulnerability must be associated with a recognizable product name that customers can identify. Deeply embedded, unnamed internal components pose a significant challenge here.

AWS's process involves an intentional function to determine CVE qualification based on an analysis of the issue, CVSS scoring, and understanding "customer agency." If a customer might need to perform a risk assessment from their logs (e.g., CloudTrail, CloudWatch), AWS leans towards issuing a CVE, even if no direct action is required. This ensures a reference point for customers' incident response processes.

The panel also touched upon the use of CWEs (Common Weakness Enumerations) to enhance CVE records, providing more detailed information about the nature of the vulnerability. This enrichment aids in research and education, contributing to a safer industry. The introduction of the exclusively hosted service tag in CVE 4.0 was discussed as a narrow classification, used only when the entire record pertains to a hosted service, with current usage numbers around 51-61 records in the database.

Regarding Coordinated Vulnerability Disclosure (CVD), panelists outlined their rubrics for consistency. AWS publishes its scope, outlining criteria for CVE assignment and providing a dispute process. They prioritize providing recognition for researchers, even if a CVE isn't assigned, but acknowledge that many researchers tie self-worth to CVE numbers. The discussion also highlighted how cloud vulnerabilities fit into broader supply chain security concerns, including the relevance of SBOM (Software Bill of Materials) and VEX (Vulnerability Exploitability eXchange), especially given the complex interdependencies within cloud architectures, such as external identity providers.

Demo / Proof of Concept

▶ Watch: Meet the panel: AWS, Google, and Microsoft experts (3:30)

The talk did not include a live demonstration or proof of concept. The format was a panel discussion focused on policy, process, and the implications of CVE rule changes for cloud service providers and their customers.

Defensive Implications

▶ Watch: AWS's current process for assigning CVEs to cloud vulnerabilities (6:30)

For organizations consuming cloud services, the insights from this panel offer several critical defensive implications:

• Beyond "No Action Required": Even when a CSP declares a vulnerability as "no action required," customers should still consider their customer agency. This means proactively assessing potential risks within their own environments, reviewing logs (e.g., CloudTrail, CloudWatch logs for AWS; similar services for Google Cloud and Azure), and evaluating if the vulnerability could have impacted their specific configurations or data, potentially triggering incident response procedures. The presence of a CVE, even for a provider-fixed issue, can serve as a valuable timestamp and reference for such investigations.
• Leverage Direct Communication Channels: CSPs prioritize direct communication with their customers regarding security issues. Defenders should ensure they are actively monitoring personal health dashboards, security announcement emails, and API-accessible security notifications provided by their cloud providers. These channels are often more timely and actionable for specific customer environments than general CVE database entries.
• Understand the Value of CVEs for the Ecosystem: While direct customer action on SaaS CVEs may be minimal, defenders should recognize that CVEs contribute to broader industry transparency and research. Security teams can use CVE data to understand common vulnerability patterns across cloud providers, inform their threat intelligence, and improve their overall security posture by learning from others' experiences. This knowledge can also feed into their internal vulnerability management tools and risk assessment frameworks.
• Verify SaaS Security Beyond Scans: Relying solely on vulnerability scans for SaaS environments is often insufficient. As Mike Cotay noted, scans can be unreliable, and a dependency showing up in a scan doesn't mean it's exploitable within a large cloud provider's highly mitigated environment. Defenders should instead seek assurance through:
• Compliance Regimes and Third-Party Audits: Leverage the reports from independent auditors who verify the CSP's adherence to various security compliance standards (e.g., FedRAMP, ISO 27001).
• Bug Bounty Programs: If a scan flags something suspicious, and you believe it's externally exploitable, consider engaging with the CSP's bug bounty program to validate your findings and potentially get rewarded.
• Own the Relationship with Your Customers: For companies that build and host their own services on cloud platforms, they must take responsibility for communicating security information to their end-users. The CSP will inform the company, but the company must then translate that information and its implications for their specific customer base, as the underlying cloud infrastructure might not be visible to the end-user.
• Utilize CWEs for Best Practices: The mention of enriching CVEs with Common Weakness Enumerations (CWEs) is important. CWEs provide a standardized way to categorize and understand software weaknesses, helping defenders identify root causes and implement better security design principles and best practices to prevent similar vulnerabilities in their own code or configurations.

Key Takeaways

• The CVE 4.0 rules, effective August 2024, significantly broaden the scope for assigning CVEs to cloud vulnerabilities, particularly if they cause "significant harm" or require action/risk assessment by parties other than the CNA.
• Cloud service providers (CSPs) prioritize direct customer protection through automated fixes and explicit communication channels (e.g., health dashboards, emails) over public CVE assignments for immediate customer response.
• While "no action required" for customers is common in SaaS, it doesn't always negate the need for customers to perform risk assessments or review logs for potential incident response, a concept termed "customer agency."
• CVEs for SaaS primarily benefit the broader security ecosystem by fostering transparency, enabling research, informing vulnerability management tools, and allowing cross-provider learning about common security challenges.
• Assuring SaaS security for paranoid customers involves verifying through compliance regimes, third-party auditors, and CSP bug bounty programs, rather than relying solely on potentially unreliable vulnerability scan results.
• The "software naming problem" for deeply embedded, unnamed internal cloud components presents a significant challenge for consistent and meaningful CVE assignment.

About the Speaker(s)

• Don Bailey (Beetle): A seasoned expert in cloud security, Don has been with AWS for 15 years, where he helped found the AWS security team. Prior to his tenure at Amazon, he worked at the MITRE Corporation and holds the unique distinction of being the intern who "broke CVE" during its launch in the summer of 1999. At AWS, he was initially responsible for writing all security bulletins and remains a key point of escalation and involvement in the company's CVE discussions.
• Mike Cotay: Mike leads the Google bug bounty and vulnerability awards program. While not extensively involved with CVEs historically, his role shifted significantly approximately four months prior to the talk when Google committed to publishing CVEs for all critical vulnerabilities found in Google Cloud. His team now oversees the assessment and publication process for these CVEs.
• Lisa Olsen: A prominent figure in vulnerability management, Lisa has been with Microsoft's MSRC (Microsoft Security Response Center) for 12 years, where she runs Patch Tuesday. She joined the CVE board in 2018 and has dedicated considerable time to developing CVE reporting standards. Lisa was instrumental in the evolution of the CVE rules, particularly the internal rules for both CVE 3.0 and 4.0, focusing on how to handle cloud-specific situations.
• Art Coviello: The moderator for this panel, Art guided the discussion, introducing the topic and facilitating the exchange of insights among the panelists.