TETD: Trusted Execution in Trust Domains

CloudFlow: Identifying Security-sensitive Data Flows in Serverless Applications

Speakers: Giuseppe Raffa (University of London); Royal Holloway (University of London); Jorge Blasco (Universidad Politécnica de Madrid); Dan O'Keeffe (University of London); Royal Holloway (University of London); Santanu Kumar Dash (University of Surrey)

Conference: USENIX Security

Overview

The rapid adoption of the serverless computing paradigm has revolutionized cloud application development, offering developers the advantage of focusing solely on business logic while abstracting away infrastructure management. However, this shift introduces novel and complex security challenges, particularly concerning the static analysis of application security. Traditional static analysis tools struggle with the event-driven, asynchronous nature of serverless functions, the intricate web of cloud service interactions, and the black-box proprietary code of cloud platforms. This paper introduces CloudFlow, a groundbreaking framework designed to statically detect security-sensitive data flows in serverless applications, directly addressing these critical challenges.

Developed by Giuseppe Raffa and colleagues, CloudFlow stands out by leveraging infrastructure definitions to identify events, permissions, and entry points, then intelligently instrumenting application code with custom models for events and cloud API calls. This transformation allows existing general-purpose static analysis tools to effectively scrutinize serverless applications for vulnerabilities prior to deployment. The significance of CloudFlow is underscored by its rigorous evaluation against a new suite of 40 microbenchmarks, CloudBench, and an unprecedented analysis of 104 real-world serverless applications, marking the largest security-focused static analysis of such applications to date.

CloudFlow's ability to uncover vulnerabilities like code injection and information leakage in real-world applications before they reach production environments is crucial for bolstering the security posture of modern cloud-native systems. By open-sourcing both CloudFlow and CloudBench, the authors aim to foster further research and development in serverless security, providing essential tools and methodologies for identifying and mitigating risks in this evolving computing landscape.

Background

The serverless computing model, often synonymous with Function-as-a-Service (FaaS), has gained immense popularity due to its promise of reduced operational overheads, allowing developers to concentrate on application logic rather than infrastructure provisioning, scaling, and maintenance. Major cloud providers such as Amazon, Microsoft, and Google offer extensive backend services that facilitate the creation of diverse applications, from image processors to web services. Despite these benefits, the security of serverless applications presents a complex landscape, as highlighted by recent data breaches and industry reports. Under the shared responsibility model, developers bear the primary burden for application security, which is exacerbated by the typically large attack surface of serverless architectures that interact with numerous internal and external services.

Static analysis, a fundamental component of the secure software development lifecycle, faces unique obstacles in the serverless domain. First, serverless applications are inherently event-driven, comprising stateless functions (handlers) triggered by asynchronous events like HTTP requests or database updates. This asynchronous execution, coupled with cloud interactions that are not part of synchronous code flow, makes traditional static analysis challenging. Second, the definition of application permissions is often complex, involving a multitude of mechanisms such as identity and resource policies, time-constrained roles, and attribute-based access control within environments like AWS. Accurately modeling these permissions is vital for precise analysis. Finally, the proprietary and black-box nature of cloud service code means developers cannot directly analyze it, necessitating abstract models to understand its functionality and security implications.

Previous research has explored dynamic information flow analysis, customized access control models, and provenance tracking for serverless applications. However, these often require deploying additional code or runtime information, limiting their utility for pre-deployment security assessments. While some static analysis efforts have focused on call graph generation or security-sensitive data flows, they frequently fall short by not fully integrating infrastructure definitions or by requiring manual modeling of backend service interactions. Existing solutions for other event-driven architectures (ee.g., Node.js or Android) are not directly applicable to serverless platforms due to their inability to process the complex infrastructure-related information critical for serverless analysis. CloudFlow emerges as a solution to these specific limitations, providing a fully automated, static approach to identify security-sensitive data flows by comprehensively understanding both application and infrastructure code.

To illustrate these challenges, the paper presents a motivating example (§2.2) involving a multi-service AWS application with a code injection vulnerability. A user's HTTP POST request triggers an onHTTPPostEvent handler (Listing 2), which sends a message to an SQS queue. This, in turn, triggers an onSQSMessage handler (Listing 3) that processes the user-specified message and uploads a local file to an S3 bucket. The S3 upload then triggers an onS3Upload handler (Listing 4), which reads the uploaded file and updates a DynamoDB table. Finally, the DynamoDB update triggers an onDynamoDBStream handler (Listing 5), which passes user-controlled data from the database item directly to os.system. This chain of events, spanning multiple services and handlers, results in a system command execution with user-controlled input. This example highlights three key challenges:

1. Event Propagation from Cloud API Calls: General-purpose static analysis tools cannot infer that an API call like send_message in Listing 2 triggers onSQSMessage because this information resides in the infrastructure definition, not the application source code. Custom models for event objects are essential.
2. Complex Permission Mechanisms: The numerous ways to define permissions (e.g., IAM role statements in Listing 1) make it difficult for general-purpose tools to accurately assess allowed actions.
3. Black-Box Cloud Service Code: The proprietary nature of cloud services means their code cannot be analyzed, necessitating models to approximate their functionality and security behavior. CloudFlow's design directly addresses these specific challenges.

Key Findings

CloudFlow's evaluation yielded several significant findings that underscore its effectiveness and contribution to serverless security:

• High Detection Rate on Microbenchmarks: CloudFlow successfully identified expected data flows in 37 out of 40 (92.5%) microbenchmarks within the newly developed CloudBench suite. This demonstrates a substantial improvement over previous baseline frameworks, which passed only 27 microbenchmarks. The ablation study further confirmed that CloudFlow's novel features, such as environment variable inspection, plugin analysis, and resource analysis, were crucial for this enhanced performance, with plugin analysis being the most frequently occurring contributor.
• Discovery of Real-World Vulnerabilities: The framework analyzed 104 real-world AWS serverless applications written in Python, selected from the AWSomePy dataset. This extensive analysis, the largest security-focused study of its kind to date, identified a total of 205 security-sensitive data flows. Critically, after manual validation, 11 confirmed vulnerabilities were found across five different applications. These included seven code injection vulnerabilities (five via HTTP requests, two via command-line interface parameters) and four information leakage vulnerabilities (specifically, exception traceback leakage).
• Scalability and Acceptable Overhead: CloudFlow demonstrated practical scalability, with its execution times increasing primarily due to the underlying static analysis tool, Pysa, for repositories exceeding approximately 3,000 lines of code. The CloudFlow-specific overhead was found to be generally acceptable, with a median overhead of 5.7% and 75% of analyzed applications experiencing an overhead of 12.8% or less. This indicates that CloudFlow can be integrated into development workflows without imposing prohibitive performance penalties.
• Novel Automated Framework: CloudFlow represents a novel, fully automated framework for statically detecting security-sensitive data flows in event-driven serverless applications. It achieves this by transforming the asynchronous nature of serverless into a synchronous representation, making it amenable to general-purpose static analysis tools. This allows developers to identify potential security vulnerabilities before deployment.
• New Security-Oriented Microbenchmark Suite: The introduction of CloudBench provides a crucial resource for future research. This suite of 40 security-oriented microbenchmarks, including 30 new additions compared to prior work, supports five AWS services and covers both inter-procedural and intra-procedural data flows, explicitly focusing on harder-to-detect cross-handler vulnerabilities. CloudBench is open-source, enabling other researchers to test and compare static analysis tools for serverless environments.
• Comprehensive Understanding of Serverless Architecture: The framework's ability to parse and integrate information from both infrastructure-as-code definitions and application source code, coupled with custom models for cloud APIs and event objects, highlights the necessity of a holistic approach to serverless security analysis. This comprehensive understanding is key to accurately mapping potential attack paths across distributed serverless components.

Technical Deep Dive

CloudFlow's core technical contribution lies in its novel approach to transform an event-driven serverless application into a synchronous equivalent that can be effectively analyzed by existing general-purpose static analysis tools, such as Pysa. This transformation is achieved through a sophisticated, three-stage pipeline (Fig. 2) that meticulously processes both infrastructure-as-code definitions and application source code.

Stage 1: Initial Analysis

The first stage of CloudFlow focuses on gathering comprehensive information from the application's infrastructure and codebases.

1. Configuration Parameters Extraction: CloudFlow begins by parsing the infrastructure code, typically specified in YAML files (e.g., using the Serverless Framework). A custom YAML parser recursively traverses the file to detect and resolve configuration parameters, such as environment variables (os.getenv, os.environ) and resource names (e.g., S3 bucket names) that might depend on deployment stages. This step is crucial for precision, as these parameters often dictate how cloud APIs are called.
2. Permissions, Events, and Handlers (PEH) Identification: An abstraction layer extracts security-relevant information, including associations between events and their triggered handlers, and permissions linked to cloud-based resources (e.g., iamRoleStatements in Listing 1). This addresses the challenge of complex permission mechanisms. CloudFlow also processes event filters, which conditionally trigger handlers (e.g., an S3 event filter for prefix: uploads/), and models deployment tool plugins (e.g., handler-level permissions plugin [55] and AWS Step Functions plugin [56]) to refine architectural and permission analyses.
3. Sources & Sinks Definition: User-controlled entry points (sources), such as HTTP request bodies, and security-sensitive sinks (e.g., cloud-hosted repositories, databases, or system command execution functions like os.system) are identified from the infrastructure code. This is an initial step towards addressing the challenge of identifying event-triggered data flows.
4. Cloud API Calls Identification & Models: CloudFlow analyzes the Abstract Syntax Tree (AST) of the application code to identify calls to language-specific Software Development Kits (SDKs), such as boto3 for Python. It identifies both client and resource interface objects [48]. Security-relevant inputs to these API calls are extracted using documentation-based models that approximate cloud service functionality, addressing the black-box nature of cloud services. The framework attempts to statically resolve these API inputs using configuration parameters extracted earlier, enhancing analysis precision.
5. Language-Specific Processing: For Python applications, CloudFlow leverages Pyre (the static type checker underlying Pysa [41]) for automated type inference. Since Pyre supports only core language types, CloudFlow also modifies the AST nodes of SDK-provided interface objects to insert boto3-specific type annotations (e.g., s3_client: S3Client in Listing 6). This is vital for static analyzers to prevent false negatives caused by missing type information in dynamically typed languages.

Stage 2: Synchronous Representation Creation

This stage is central to CloudFlow's innovation, transforming the asynchronous serverless execution into a synchronous flow that general-purpose static analysis tools can understand.

1. Event Object Model Population: For each cloud API that triggers a handler, CloudFlow populates an event object model. This model contains an approximation of the data structure encapsulated in the platform event (e.g., JSON format models for AWS events).
2. Code Synthesis & Injection: CloudFlow synthesizes two distinct code statements and injects them into the application's AST, typically after the cloud API call site to emulate a standard function call:

• An initialization statement for the event object, constructed from the event object model, including information like the event name (from infrastructure code) and cloud resource details (from API call inputs).
• An explicit handler call, where the event object is passed as one of the inputs.
• Example (Listing 6): The upload_file API call in onSQSMessage is instrumented. After the original s3_client.upload_file call (line 8), CloudFlow injects an event object initialization (lines 9-11) mimicking an S3 ObjectCreated:* event, followed by an explicit call to s3uploadhandler.onS3Upload(event, context) (line 12). This effectively makes the event-driven handler execution appear as a direct, synchronous function call within the analyzed code.

Stage 3: Static Analysis Model Preparation and Data Flow Identification

The final stage prepares the ground for data flow analysis using Pysa.

1. Application-Specific Model Generation: CloudFlow automatically generates Pysa models that mark the event objects processed by all handlers as user-provided sources. This ensures that data flowing from external events, which could be user-controlled, is tracked. This accounts for both intended user input and potentially malicious workflow manipulations.
2. Cloud API Model Retrieval: Custom Pysa models are developed for boto3-specific security-sensitive sinks (e.g., DynamoDB's scan API [1]), complementing Pysa's generic security-sensitive sinks (e.g., os.system). These models define how sensitive data might egress or be processed by cloud services.
3. Permission-Based Model Selection: To minimize false positives, CloudFlow incorporates a serverless-specific feature: custom Pysa models are automatically disabled if they target cloud APIs that are disallowed by the application's permissions. This ensures the analysis respects the actual access control configurations.
4. Data Flow Identification: With all necessary static analysis models in place, the instrumented application code is then fed into Pysa to perform inter-procedural, security-sensitive data flow detection. Pysa traces tainted data from identified sources to sinks, highlighting potential vulnerabilities.

CloudFlow's current implementation targets AWS Lambda applications deployed using the Serverless Framework and is optimized for Python applications, leveraging Pysa as its underlying static analysis engine. While the architecture is generic, these specific choices facilitate a deep and effective analysis within a popular serverless ecosystem.

Demo / Proof of Concept

The efficacy of CloudFlow was rigorously demonstrated through two primary evaluations: a microbenchmark suite called CloudBench and an analysis of real-world serverless applications.

CloudBench Microbenchmark Evaluation (§4)

Recognizing the absence of security-oriented serverless benchmarks, the authors developed CloudBench, a new suite of 40 AWS and Serverless Framework-compatible Python applications designed to test security tools.

• Structure: CloudBench comprises 30 inter-procedural microbenchmarks (75% of the total), where source and sink reside in different handlers and data flows are event-triggered, making them harder to detect. The remaining 9 are intra-procedural, and one simple application includes an AWS Step Function.
• Coverage: The suite supports five key AWS services: S3, DynamoDB, SQS, SNS, and Step Functions.
• Vulnerability Types: 27 microbenchmarks contain code injection vulnerabilities, 5 focus on information leakage and integrity, and 8 are designed to capture false positive scenarios. These vulnerabilities reflect critical risks identified by the Cloud Security Alliance [12].
• Results: CloudFlow successfully identified the expected data flows in 37 out of 40 microbenchmarks, achieving a 92.5% success rate. This significantly surpasses the baseline framework [47], which passed only 27.
• Ablation Study: An ablation study detailed in Table 2 demonstrated the contribution of CloudFlow's unique features. Plugin analysis was the most impactful, enabling detection in four inter-procedural, one intra-procedural, and the simple application benchmarks. Resource analysis and environment variable inspection also played crucial roles, often in combination, to improve detection capabilities.
• False Positive Example: The api-publish-wrong-bucket-key microbenchmark resulted in a false positive (Listing 7). Despite an event filter configured via a YAML prefix tag, CloudFlow could not fully resolve the s3BucketKey variable (initialized via os.path.join). Consequently, it relied solely on API permissions, detecting a non-existent data flow to minimize false negatives.
• False Negative Examples:
• api-put-item-via-file (Listing 8): Pysa failed to merge two partial data flows due to a taint propagation issue with context managers, treating outputFileObjA and outputFileA as independent variables. This was confirmed as a limitation of the Pysa engine.
• api-publish-boto3-client: This false negative was hypothesized to be caused by an unidentified Pysa post-processing configuration parameter, as partial data flows were correctly identified, but the full flow was not reported.

Real-World Application Analysis (§5)

CloudFlow was deployed to analyze 104 real-world Python serverless applications from the AWSomePy dataset, initially comprising 145 applications [46].

• Dataset Triage: 41 applications were filtered out due to being templates, incompatible with CloudFlow (e.g., obsolete Python versions, legacy APIs), incompatible with Pysa (e.g., invalid file/folder names for Python identifiers), or having inconsistent infrastructure or application code.
• Identified Data Flows: CloudFlow detected a total of 205 security-sensitive data flows. Following manual validation to ascertain actual exploitability, these were categorized:
• 11 confirmed vulnerabilities in 5 distinct applications.
• 64 potential vulnerabilities, requiring further investigation due to complex function call chains or reliance on pre-configured cloud resources.
• 130 non-vulnerabilities, where identified data flows were deemed not to be security concerns.
• Vulnerability Types (§5.2, Table 5):
• Code Injection via HTTP (5 vulnerabilities in 3 applications): This was the most common type. User-controlled, unsanitized parts of HTTP requests were directly used to initialize commands executed via standard library functions like subprocess.Popen or subprocess.check_output.
• Case Study (Listing 9): An image_transform function in one application processed user-supplied s3_key and raw_ops from a HTTP event. If the source_filename (derived from s3_key) contained malicious commands, these would be executed by subprocess.check_output without proper sanitization. CloudFlow detected this by marking the handler event input as a source.
• Code Injection via CLI (2 vulnerabilities in 1 application): Unchecked command-line parameters were used to modify shell scripts executed via os.system.
• Exception Traceback Leakage (4 vulnerabilities in 1 application): Traceback objects, containing detailed exception information, were returned unfiltered as part of HTTP responses, making them visible to users. While not directly exploitable, this exposes sensitive internal application details.
• Case Study (Listing 10): An event_process function returned str(e) directly in a Response object upon an exception, leaking the traceback.
• Manual Analysis Overhead: Manual inspection of each identified data flow took approximately 20 minutes on average for the researchers, who were unfamiliar with the applications. This time is expected to be significantly lower for developers knowledgeable about their own codebase.
• Performance Evaluation (§5.4): CloudFlow's execution times were measured, showing that the overall analysis time (CloudFlow + Pysa) increased for repositories larger than approximately 3,000 LOC, primarily due to Pysa's computationally intensive type inference and data flow identification. However, the CloudFlow-specific overhead was minimal: the median overhead was 5.7%, and for 75% of applications, it was 12.8% or less (Fig. 4). This confirms CloudFlow's practical scalability and acceptable performance for integration into development pipelines.

Defensive Implications

The findings from CloudFlow's development and evaluation provide critical insights for developers, security architects, and organizations building and securing serverless applications:

• Integrate Static Analysis Early: Adopt frameworks like CloudFlow into the Secure Software Development Lifecycle (SSDLC), particularly within Continuous Integration/Continuous Deployment (CI/CD) pipelines. Detecting security-sensitive data flows and vulnerabilities pre-deployment is far more cost-effective and secure than discovering them in production.
• Prioritize Infrastructure-as-Code (IaC) Security: Recognize that IaC (e.g., Serverless Framework YAML files) is not merely for deployment but a crucial source of security-relevant information. Tools must parse and understand these definitions (events, permissions, resource configurations) to build an accurate model of the application's attack surface.
• Implement Robust Input Validation and Sanitization: The prevalence of code injection vulnerabilities (both HTTP and CLI-based) highlights the persistent threat of unsanitized user input. Developers must meticulously validate and sanitize all external inputs, especially when they are used in system commands (os.system, subprocess.check_output), file paths, or database queries.
• Practice Secure Error Handling: Avoid leaking sensitive information, such as full exception tracebacks, in production environments. While useful for debugging, these can provide attackers with valuable reconnaissance about the application's internal structure and vulnerabilities. Implement custom, generic error messages for end-users.
• Understand Inter-Service Event-Driven Flows: Serverless applications often involve complex chains of event-triggered functions spanning multiple cloud services (e.g., SQS -> S3 -> DynamoDB). Defenders must mentally model or use tools to visualize these asynchronous data flows, as a vulnerability can originate from an initial event and propagate across the entire chain.
• Adhere to the Principle of Least Privilege for IAM: Carefully define AWS Identity and Access Management (IAM) roles and resource policies. Over-privileged functions or resources can exacerbate the impact of a vulnerability. CloudFlow's ability to integrate permission analysis helps identify misconfigurations that might lead to unintended data flows.
• Model Cloud API Interactions: Developers should explicitly understand the security implications of boto3 (or other SDK) API calls. Custom models within static analysis tools are essential to approximate the behavior of black-box cloud services and identify security-sensitive sinks.
• Leverage Security Benchmarks: Utilize resources like CloudBench to test the effectiveness of internal security controls, custom static analysis rules, or security training programs. These benchmarks provide a controlled environment to validate detection capabilities against known serverless vulnerability patterns.
• Complement Static Analysis with Dynamic Tools: While CloudFlow significantly advances static analysis for serverless, it's not a silver bullet. Some complex configurations, runtime-only information, or highly dynamic code generation might still require dynamic analysis, runtime monitoring, or observability tools to provide a complete security picture. A hybrid approach offers the strongest defense.
• Stay Updated with SDKs and Cloud Services: Cloud providers frequently update their services and SDKs. Security teams and developers should ensure their static analysis tools and custom models are regularly updated to reflect these changes, preventing blind spots in their security assessments.

Key Takeaways

• Serverless static analysis is feasible and critical: CloudFlow demonstrates that the unique challenges of serverless applications (event-driven, black-box services, complex permissions) can be effectively overcome through specialized static analysis techniques, enabling pre-deployment vulnerability detection.
• Infrastructure-as-Code is a security goldmine: Leveraging information from infrastructure definitions (YAML files) about events, permissions, and resource configurations is fundamental for accurate and comprehensive security analysis of serverless applications.
• Asynchronous-to-synchronous transformation is key: CloudFlow's innovative approach of instrumenting event-driven serverless code to create a synchronous representation allows general-purpose static analysis tools like Pysa to effectively identify security-sensitive data flows across distributed functions.
• Real-world serverless applications are vulnerable: Extensive analysis of 104 applications confirmed the presence of exploitable vulnerabilities, including code injection (via HTTP and CLI) and information leakage (traceback leaks), underscoring the practical need for such security frameworks.
• CloudBench fosters future research: The release of CloudBench provides a valuable, open-source suite of 40 security-oriented microbenchmarks, essential for testing and comparing new serverless security tools and advancing research in this domain.
• Practical scalability with low overhead: CloudFlow exhibits acceptable performance overhead (median 5.7%), confirming its potential for practical integration into existing development workflows without significantly impeding productivity.

About the Speaker(s)

The research presented in "CloudFlow: Identifying Security-sensitive Data Flows in Serverless Applications" was a collaborative effort by academics from several institutions. The primary authors include Giuseppe Raffa and Dan O'Keeffe, both affiliated with the University of London and Royal Holloway (University of London). They are joined by Jorge Blasco from Universidad Politécnica de Madrid and Santanu Kumar Dash from the University of Surrey. Their collective expertise spans the areas of system security, cloud computing, and static analysis, as evidenced by their work on developing advanced tools and methodologies to enhance the security of modern software paradigms like serverless.