CloudFlow: Identifying Security-sensitive Data Flows in Serverless Applications
Giuseppe Raffa
34th USENIX Security Symposium (USENIX Security '25) · Day 1 · System Security 2: Trusted and Robust Computing
Overview
In this presentation, Giuseppe Raffa introduces CloudFlow, a novel framework designed to statically detect security-sensitive data flows within serverless applications. As enterprises increasingly adopt serverless computing for its agility and reduced operational overhead, the complexity of securing these applications has become a significant challenge. CloudFlow addresses this by providing a mechanism to inspect applications for vulnerabilities before deployment, a critical advantage over traditional dynamic analysis methods.

Key moments
- 0:00 Introduction and challenges of serverless security
- 2:00 Motivating example: Event-triggered code injection vulnerability
- 4:00 CloudFlow's static analysis methodology and instrumentation
- 6:00 CloudBench: New security benchmarks and evaluation results
- 8:00 Real-world application analysis and vulnerability types
- 10:00 CloudFlow performance and overhead analysis
CloudFlow: Identifying Security-sensitive Data Flows in Serverless Applications
Speakers: Giuseppe Raffa
Conference: USENIX Security
YouTube: https://www.youtube.com/watch?v=Jd3kmfkk2dQ
Overview
In this presentation, Giuseppe Raffa introduces CloudFlow, a novel framework designed to statically detect security-sensitive data flows within serverless applications. As enterprises increasingly adopt serverless computing for its agility and reduced operational overhead, the complexity of securing these applications has become a significant challenge. CloudFlow addresses this by providing a mechanism to inspect applications for vulnerabilities before deployment, a critical advantage over traditional dynamic analysis methods.
The core motivation behind CloudFlow stems from the inherent difficulties in statically analyzing serverless environments. These applications are highly event-driven, relying on interactions with cloud platform services; they utilize diverse mechanisms for defining permissions; and crucially, the underlying platform service code remains proprietary and inaccessible for analysis. CloudFlow's innovative approach combines insights from both the application's infrastructure configuration and its code to overcome these hurdles, enabling the identification of complex, event-triggered data flows that could lead to severe vulnerabilities like code injection.
The research not only presents the CloudFlow framework but also introduces CloudBench, a new suite of security-oriented microbenchmarks specifically tailored for serverless environments. Through rigorous evaluation against CloudBench and a comprehensive analysis of 104 real-world serverless applications, CloudFlow demonstrates its effectiveness in identifying previously undetected vulnerabilities, solidifying its importance in the evolving landscape of serverless security.
Background
▶ Watch: Introduction and challenges of serverless security (0:00)
Serverless computing has revolutionized application development by abstracting away infrastructure management, allowing developers to concentrate solely on business logic. Platforms like AWS Lambda handle scalability, maintenance, and underlying server operations, offering significant benefits in terms of agility and cost-efficiency. However, this abstraction also introduces unique security complexities that traditional analysis tools often fail to address.
The primary challenge in securing serverless applications lies in their event-driven nature. Functions (or handlers) are invoked in response to various events—such as HTTP requests, messages arriving in a queue, or database updates—creating intricate, asynchronous execution paths. A user's input might traverse multiple independent functions, triggered by a chain of events, before finally reaching a sensitive sink. General-purpose static analysis tools struggle to model these event-triggered interactions, often failing to recognize data flows that span across different handlers and services. Prior research in this area has predominantly focused on dynamic information flow analysis, which inspects applications during runtime. While valuable, dynamic analysis inherently occurs post-deployment, leaving a window of vulnerability open if flaws are not caught earlier.
Furthermore, serverless environments present three specific obstacles for static analysis:
- Event-driven interactions: The intricate web of events and triggers linking functions and cloud services must be accurately modeled.
- Diverse permission mechanisms: Applications leverage various methods to define resource access permissions, which influence data flow and potential attack paths.
- Proprietary platform code: The underlying code for cloud services (e.g., SQS, S3, DynamoDB) is closed-source, making it impossible for analyzers to directly inspect its behavior or infer security properties.
To illustrate these challenges, consider a motivating example presented in the talk: a simple serverless application processing an HTTP POST request. This request triggers a chain of events:
- An initial Lambda handler receives the HTTP POST and sends a message to an SQS (Simple Queue Service) queue.
- The SQS service then triggers a "consumer" Lambda handler.
- This consumer handler calls an
API upload filefunction, which in turn raises an event. - This event triggers a third handler, which updates a database.
- Finally, a fourth handler is executed, taking a string initialized from the new database item and passing it to
os.system.
The critical flaw here is that part of the original user input from the HTTP POST request flows through this entire event-driven chain, ending up as an argument to os.system in the final handler. This constitutes a code injection vulnerability. A standard static analysis tool would likely only analyze each Lambda function in isolation or struggle to connect the asynchronous, event-driven triggers, thus failing to detect this sophisticated interprocedural data flow. CloudFlow aims to bridge this gap by comprehensively modeling these event-driven interactions.
Key Findings
▶ Watch: CloudFlow's static analysis methodology and instrumentation (4:00)
CloudFlow represents a significant advancement in the static analysis of serverless applications, delivering several key findings and contributions:
Firstly, the framework successfully constructs an asynchronous representation of serverless applications by intelligently combining information extracted from both the application's infrastructure configuration and its source code. This hybrid approach enables CloudFlow to model the complex event-triggered data flows that are characteristic of serverless architectures, a capability largely absent in prior static analysis tools.
A major contribution of this research is the introduction of CloudBench, a novel suite of security-oriented microbenchmarks specifically designed for serverless environments. CloudBench comprises 40 AWS Python applications, with 30 focused on interprocedural data flows (data flows beginning and ending in different handlers, invariably involving event-triggered code) and nine on intraprocedural flows. The emphasis on interprocedural scenarios reflects their greater complexity and prevalence in real-world vulnerabilities. Critically, 27 of these microbenchmarks target code injection, identified by industry experts as one of the most critical risks for serverless applications. CloudFlow demonstrated strong performance on this suite, successfully passing 37 out of 40 microbenchmarks. The analysis of the three failed cases revealed one false positive attributed to a CloudFlow limitation and two false negatives due to the underlying general-purpose static analysis tool integrated with CloudFlow.
Beyond synthetic benchmarks, CloudFlow was rigorously evaluated against 104 real-world serverless applications. In this comprehensive analysis, the framework identified a total of 205 security-sensitive data flows. Following manual validation, 11 of these were confirmed as actual vulnerabilities, while 64 were categorized as "potential vulnerabilities" (e.g., cases with a high number of involved function calls requiring further manual inspection). The remaining 130 cases were determined not to be security concerns.
The vulnerabilities discovered in real-world applications fell into three distinct categories:
- Code injection due to unchecked command line parameters: This involves user input being directly passed to system commands without proper sanitization.
- Code injection caused by HTTP request-triggered data flow: This aligns with the motivating example, where malicious input from an HTTP request propagates through event chains to a command execution sink.
- Exception traceback leakage: Four vulnerabilities were identified where detailed exception traceback objects were returned as part of HTTP responses. While not directly exploitable, this information leakage can provide attackers with valuable insights into the application's internal structure, aiding further exploitation. Notably, one of these was an intraprocedural data flow, while most other discovered vulnerabilities were interprocedural.
Finally, the performance evaluation of CloudFlow demonstrated its practicality. While total execution times increased with application size (specifically, when repositories exceeded approximately 3,000 lines of code), this increase was primarily attributed to the computationally intensive nature of the underlying general-purpose static analysis tool. Crucially, the CloudFlow-specific overhead was found to be generally acceptable, with the box plot showing that for 75% of the analyzed applications, the framework's overhead was 12.8% or less of the total execution time. This indicates that CloudFlow can be integrated into development workflows without imposing prohibitive performance penalties.
Technical Deep Dive
▶ Watch: CloudBench: New security benchmarks and evaluation results (6:00)
CloudFlow's core innovation lies in its ability to bridge the gap between static code analysis and the dynamic, event-driven nature of serverless applications. It achieves this by combining information from two distinct sources: the application's infrastructure definition and its source code.
The first step in the CloudFlow pipeline involves extracting critical infrastructure information. This includes Permissions, Events, and Handler-related parameters (referred to as PEH in the presentation). These details are crucial because they define how different functions interact with cloud services and how events trigger their execution. For example, an infrastructure definition might specify that an SQS queue event triggers a particular Lambda function, or that an S3 bucket upload triggers another. Without this context, a static analyzer would perceive these functions as isolated entities.
Once the infrastructure information is gathered, CloudFlow proceeds to analyze the application's source code. This involves processing the Abstract Syntax Tree (AST) of the code to identify cloud API calls. These are calls to cloud service SDKs (e.g., boto3 in Python for AWS), which are often the nexus of data interaction with the cloud platform. Each identified cloud API call is then analyzed using models that define its security-relevant inputs and outputs. These models are essential for understanding how data flows into and out of cloud services, even though the service's internal code is proprietary. For instance, a model for an S3 upload API call would specify which parameters might contain sensitive data (like a file name or content) that could later become an event payload.
The most critical component of CloudFlow is its representation mechanism, which allows the framework to instrument the application code. This instrumentation transforms the inherently asynchronous, event-driven serverless execution flow into a synchronous, "light" program execution flow that can be analyzed by general-purpose static analysis tools.
Let's consider the example of instrumenting the upload file API call from the motivating example:
- Event Object Initialization: CloudFlow first synthesizes an event object. This object is an approximation of the data structure that would be encapsulated in the real-world event. It includes crucial metadata like the event name (extracted from the infrastructure code) and relevant data like the cloud-based repository name (obtained from one of the API inputs). This object essentially simulates the payload that an event would carry.
- Synthesized Handler Call: Next, CloudFlow synthesizes a call to the event-triggered handler. This handler is identified from the infrastructure information as the function that would be invoked by the event created by the
upload fileAPI call. The newly initialized event object is passed as one of the inputs to this synthesized handler call. - Call Re-injection: Finally, this synthesized call to the event-triggered handler is re-injected into the code immediately after the original cloud API call. This effectively emulates a standard, synchronous function call within the application's code. By doing this, CloudFlow makes the implicit, asynchronous event flow explicit and sequential, allowing a standard static analyzer to trace data from the API call, through the simulated event, and into the subsequent handler.
The current implementation of CloudFlow focuses on Python applications, leveraging its dynamic nature for instrumentation. To further enhance the accuracy of the results, the framework also adds type annotations to the instrumented code. This is particularly beneficial for underlying static analysis tools that can leverage type information to improve their data flow analysis.
Once the code is instrumented and transformed into this synchronous representation, it can then be fed into a general-purpose static analysis tool capable of detecting data flows, such as Pysa (Facebook's security-focused static analyzer for Python). Pysa, or similar tools, can then effectively trace the flow of tainted data through the now-sequentialized execution path, including the simulated event-triggered transitions, to identify potential security vulnerabilities. This elegant combination of infrastructure-aware instrumentation and existing powerful static analysis tools is what makes CloudFlow effective in uncovering complex serverless vulnerabilities.
Demo / Proof of Concept
▶ Watch: Real-world application analysis and vulnerability types (8:00)
While the presentation did not feature a live, interactive demonstration of CloudFlow in action, its capabilities and effectiveness were thoroughly demonstrated through a compelling motivating example, rigorous evaluation against a custom benchmark suite, and the discovery of actual vulnerabilities in real-world applications. These serve as powerful proofs of concept for the framework's design and implementation.
The motivating example detailed in the "Background" section acts as a conceptual demonstration. It vividly illustrates a multi-stage, event-driven data flow where user input from an HTTP POST request propagates through an SQS queue, multiple Lambda handlers, an API call, and a database update, ultimately leading to a code injection vulnerability via os.system. The speaker explicitly states that a general-purpose static analysis tool would fail to detect this because it wouldn't consider the effect of the triggered events. CloudFlow's proposed instrumentation strategy, converting this asynchronous chain into a synchronous, analyzable flow, directly showcases how it would detect such a vulnerability. The detailed explanation of how CloudFlow synthesizes event objects and re-injects handler calls provides a clear, step-by-step conceptual walkthrough of its detection mechanism.
Further validation comes from the development and use of CloudBench, a suite of 40 AWS Python security-oriented microbenchmarks. CloudBench specifically targets challenging scenarios, including 30 interprocedural data flows that involve event-triggered code, and 27 cases of code injection. CloudFlow's success in passing 37 out of these 40 microbenchmarks serves as a strong empirical proof of concept, demonstrating its ability to correctly identify these complex vulnerabilities in controlled environments.
Perhaps the most impactful demonstration of CloudFlow's efficacy is its application to 104 real-world serverless applications. Through this analysis, CloudFlow identified 11 actual vulnerabilities and 64 potential ones. The identification of these previously unknown flaws in production-grade code provides undeniable evidence of CloudFlow's practical utility. The presentation specifically highlights an example of exception traceback leakage, where a function returns a detailed traceback object e as part of an HTTP response if an exception is raised. This intraprocedural flow, while not directly exploitable, reveals sensitive internal application details. The fact that CloudFlow could pinpoint such nuanced security concerns, alongside more critical code injection flaws, underscores its comprehensive detection capabilities across various vulnerability types in real-world scenarios. The manual validation of all 205 detected data flows (11 confirmed vulnerabilities, 64 potential, 130 not security concerns) further attests to the robustness and accuracy of CloudFlow's findings.
Defensive Implications
▶ Watch: CloudFlow performance and overhead analysis (10:00)
The insights and capabilities offered by CloudFlow carry significant implications for developers, security engineers, and organizations deploying serverless applications. Adopting a proactive security posture, informed by CloudFlow's approach, can drastically reduce the attack surface and mitigate risks.
- Shift Left with Static Analysis: The most critical defensive implication is to integrate static analysis frameworks like CloudFlow into the CI/CD pipeline before deployment. As demonstrated, dynamic analysis only catches issues post-deployment. CloudFlow enables early detection of vulnerabilities, allowing developers to remediate flaws during development, which is far more cost-effective and secure than patching in production.
- Understand Event-Driven Data Flows: Defenders must recognize that the security of serverless applications is fundamentally tied to their event-driven architecture. Traditional security practices and static analysis tools often fail to connect the dots across asynchronous event chains. Organizations should educate their developers on the unique security model of serverless and the potential for user input to traverse multiple services and functions via events, leading to unexpected vulnerabilities.
- Sanitize All User Input Rigorously: The prevalence of code injection vulnerabilities, particularly due to unchecked command line parameters or HTTP request-triggered data flows, highlights the enduring importance of input validation and sanitization. Any data originating from external sources (HTTP requests, queue messages, database entries derived from user input) must be treated as untrusted and thoroughly sanitized before being used in sensitive operations, especially those involving
os.systemor database queries.
- Guard Against Information Leakage: The discovery of exception traceback leakage underscores the need for careful error handling. While tracebacks are invaluable during development and testing, they should never be exposed in production environments. Attackers can leverage detailed error messages to understand application logic, identify vulnerable components, and craft more targeted attacks. Implement robust error handling that logs full tracebacks internally but returns only generic error messages to clients.
- Review Infrastructure as Code (IaC): CloudFlow's reliance on infrastructure information (PEH) emphasizes the security criticality of Infrastructure as Code (IaC) templates (e.g., AWS SAM, Serverless Framework, CloudFormation). These templates define event triggers, permissions, and resource configurations that directly influence data flow and potential attack paths. Security reviews of IaC should be as stringent as code reviews, ensuring that event configurations are not inadvertently creating insecure data flow pathways.
- Leverage Security-Oriented Benchmarks: The release of CloudBench provides a valuable resource for the community. Defenders can use CloudBench to test their own static analysis tools, security configurations, or even train developers on identifying common serverless vulnerabilities. This benchmark suite offers a standardized way to evaluate the effectiveness of serverless security measures.
- Consider Interprocedural Flows: The fact that most identified vulnerabilities were interprocedural (spanning multiple handlers) reinforces the need for a holistic view of serverless applications. Security analysis should not treat individual Lambda functions in isolation but consider the entire application graph, including all triggered events and service interactions.
By incorporating CloudFlow's methodology and findings into their security strategies, organizations can build more resilient serverless applications, proactively identify complex vulnerabilities, and ultimately enhance their overall cloud security posture.
Key Takeaways
- Static analysis is crucial for serverless security: CloudFlow demonstrates the feasibility and necessity of statically identifying vulnerabilities in serverless applications before deployment, a critical advantage over dynamic methods.
- CloudFlow's novel approach models event-driven flows: The framework effectively combines infrastructure and application code analysis to create a synchronous representation, enabling general-purpose static analyzers to detect complex, asynchronous data flows across multiple serverless functions.
- CloudBench provides a vital benchmark suite: The introduction of CloudBench offers the security community a much-needed, security-oriented microbenchmark suite for evaluating serverless security tools and practices, particularly for interprocedural vulnerabilities.
- Real-world serverless applications have significant vulnerabilities: CloudFlow successfully identified 11 actual vulnerabilities and 64 potential ones in 104 real-world applications, including critical code injection flaws and sensitive information leakage.
- Interprocedural data flows are a primary concern: The majority of detected vulnerabilities spanned multiple functions and services, underscoring that security analysis must consider the entire event-driven execution graph, not just individual handlers.
- CloudFlow offers practical performance: The framework introduces an acceptable overhead (less than 12.8% for 75% of applications), making it a viable addition to existing development and security pipelines.
About the Speaker(s)
Giuseppe Raffa is the speaker and researcher who presented this work on CloudFlow. The transcript and metadata provided do not offer specific details about his current title or organizational affiliation beyond his name. His research, as showcased in this presentation, focuses on advancing static analysis techniques for complex cloud environments, specifically addressing the unique security challenges posed by serverless computing.
Reviews
Dr. Zero (Offensive Security Researcher) — STRONG ACCEPT
CloudFlow is legitimate academic security research solving a real and underserved problem: static taint analysis that actually understands the asynchronous, event-driven execution model of serverless architectures. The core contribution — synthesizing synchronous representations from IaC + source code to feed into existing analyzers like Pysa — is a clever engineering insight, not just a conceptual claim, and the CloudBench artifact plus the 104-app real-world evaluation give it empirical teeth.
Heather Calloway (CISO) — SOLID
CloudFlow is legitimate academic security research that solves a real problem — static analysis of event-driven serverless data flows is genuinely hard, and the approach is technically sound. But this talk is aimed at researchers, not operators, and the gap between the tool's capabilities and an enterprise defender's next action is never bridged.
→ Top-rated talks at 34th USENIX Security Symposium (USENIX Security '25)
All talks from 34th USENIX Security Symposium (USENIX Security '25)