ELASTIC D2.2: Serverless FaaS with Lightweight Containers

Horizon Europe Framework Programme HORIZON JU Research and Innovation Action Reliable Services and Smart Security Efficient, portabLe And Secure orchesTration for reliable servICes D2.2: Serverless FaaS with Lightweight Containers Abstract: This deliverable presents a secure, privacy-aware, and architecture-agnostic execution framework for WebAssembly (Wasm)-based serverless workloads. It delivers two complementary contributions that address vulnerabilities spanning the entire serverless lifecycle—from deployment to runtime. First, we conduct a large-scale analysis of public serverless repositories, revealing critical risks such as outdated dependencies, insecure configurations, misuse of sensitive parameters, typo-squatting, and the embedding of malicious code within compressed artifacts. Second, we introduce a novel side-channel attack against Wasm applications running inside Trusted Execution Environments (TEEs), demonstrating how system call traces can be exploited to fingerprint embedded libraries or components with high accuracy, enabling stealthy and targeted attacks. Building on these findings, we propose the Serverless Security Toolbox—a consolidated, defence-in-depth collection of techniques and recommendations spanning supply chain security, runtime confidentiality, and secure interfunction communication. By integrating these countermeasures, the framework addresses both deployment-stage and runtime threats, advancing the state of the art in secure and privacypreserving Wasm-based serverless computing. This work has been carried out under Task 2.2 of the ELASTIC project. Contractual Date of Delivery 31/08/2025 Actual Date of Delivery 31/08/2025 Deliverable Security Class Public Editor Eduard Marin (TID) Contributors TID, AMA Internal Reviewers Dusan Borovcanin (UVC) Lachlan Gunn (AAL) ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 2 - August 31, 2025 The ELASTIC Consortium Part . No. Participant organisation name Participan t Short Name Role Countr y 1 POLYTECHNEIO KRITIS TUC Coordinator EL 2 ERICSSON AB ERS Principal Contractor SE 3 OY L M ERICSSON AB ERF Principal Contractor FI 4 TELEFONICA INNOVACION DIGITAL SL TID Principal Contractor ES 5 THALES SIX GTS FRANCE SAS THS Principal Contractor FR 6 THALES DIS FRANCE SAS THD Principal Contractor FR 7 INTERUNIVERSITAIR MICROELECTRONICA CENTRUM IME Principal Contractor BE 8 ULTRAVIOLET CONSULT DOO UVC Principal Contractor RS 9 AALTO KORKEAKOULUSAATIO SR AAL Principal Contractor FI 10 LUNDS UNIVERSITET LUN Principal Contractor SE 11 ABSTRACT MACHINES SAS AMA Principal Contractor FR 12 PRIVREDNO DRUSTVO ZENTRIX LAB DRUSTVO SA OGRANICENOM ODGOVORNOSCU PANCEVO ZEN Principal Contractor RS 13 POLITECNICO DI TORINO POLITO Principal Contractor IT ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 3 - August 31, 2025 Document Revisions & Quality Assurance Internal Reviewers 1. Dusan Borovcanin, UVC 2. Lachlan Gunn, AAL Revisions Version Date By Overview 1.0 22/08/2025 TUC, THS Comments and approval from the PC and the STPM 0.8 21/08/2025 TUC Quality check 0.7 21/08/2025 UVC, AMA, IMEC Approval from the IRs 0.6 20/08/2025 TID 2nd draft 0.5 06/08/2025 UVC, AMA, IMEC Comments on the 1st draft 0.4 28/07/2025 TID First draft 0.3 25/07/2025 TID, AMA Input received 0.2 11/04/2025 IMEC, THS, TUC Comments on the TOC 0.1 06/03/2025 TID TOC Disclaimer The work described in this document has been conducted within the ELASTIC project. This project has received funding from the Smart Networks and Services Joint Undertaking (SNS JU) under the European Union’s Horizon Europe research and innovation programme under Grant Agreement No 101139067. This document does not reflect the opinion of the European Union, and the European Union is not responsible for any use that might be made of the information contained therein. This document contains information that is proprietary to the ELASTIC Consortium partners. Neither this document nor the information contained herein shall be used, duplicated, or communicated by any means to any third party, in whole or in parts, except with prior written consent of the ELASTIC Consortium. The quality of this deliverable was improved with the assistance of digital tools; all content was reviewed and approved by the authors. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 4 - August 31, 2025 Table of Contents LIST OF TABLES .................................................................................................................................................. 5 LIST OF FIGURES ................................................................................................................................................ 6 LIST OF ABBREVIATIONS ................................................................................................................................ 7 EXECUTIVE SUMMARY .................................................................................................................................... 9 1 INTRODUCTION....................................................................................................................................... 10 1.1 PURPOSE AND SCOPE OF THE DOCUMENT ............................................................................................ 10 1.2 RELATION TO WORK PACKAGES, DELIVERABLES AND ACTIVITIES ..................................................... 10 1.3 CONTRIBUTION TO WP2 AND PROJECT OBJECTIVES ............................................................................ 10 1.4 STRUCTURE OF THE DOCUMENT .......................................................................................................... 11 2 OBJECTIVES ............................................................................................................................................. 12 3 ARCHITECTURE AND COMPONENTS............................................................................................... 14 4 SECURING WEBASSEMBLY-BASED SERVERLESS APPLICATIONS ........................................ 15 4.1 INTRODUCTION..................................................................................................................................... 15 4.2 BACKGROUND AND MOTIVATION ......................................................................................................... 16 4.2.1 Serverless deployment models ........................................................................................................ 16 4.2.2 Attack vectors in public serverless repositories ............................................................................. 17 4.2.3 Threat model ................................................................................................................................... 18 4.3 SERVERLESS REPOSITORY ANALYSIS FRAMEWORK .............................................................................. 18 4.4 APPLICATION SECURITY RISKS ............................................................................................................. 20 4.4.1 Vulnerability Analysis in Third-party Libraries ............................................................................. 20 4.4.2 Hiding Malicious Behaviour in Compressed Serverless Components ........................................... 23 4.5 CONFIGURATION AND DEPLOYMENT SECURITY RISKS.......................................................................... 24 4.5.1 Sensitive Parameter Misuse in Docker Run Commands ................................................................ 24 4.5.2 Security Analysis of IaC Templates ................................................................................................ 25 4.5.3 Typo-squatting Attacks ................................................................................................................... 27 4.6 KEY INSIGHTS AND DISCUSSION .......................................................................................................... 28 5 PRIVACY RISKS OF WEBASSEMBLY APPLICATIONS IN TRUSTED EXECUTION ENVIRONMENTS ............................................................................................................................................... 29 5.1 INTRODUCTION..................................................................................................................................... 29 5.2 BACKGROUND ...................................................................................................................................... 30 5.2.1 Isolation and sandboxing in WebAssembly .................................................................................... 30 5.2.2 Structure and Composition of WebAssembly Modules ................................................................... 31 5.2.3 Trusted Execution Environments .................................................................................................... 32 5.2.4 Source code, IR and Binary Obfuscation ....................................................................................... 33 5.3 THREAT MODEL ................................................................................................................................... 34 5.4 MOTIVATION AND TECHNICAL CHALLENGES ...................................................................................... 34 5.5 METHODOLOGY ................................................................................................................................... 35 5.6 EVALUATION ........................................................................................................................................ 37 5.6.1 A first look at the system call traces ............................................................................................... 39 5.6.2 Identifying target objects deployed in a standalone manner .......................................................... 41 5.6.3 Identifying target objects that run within Wasm applications ........................................................ 43 6 SERVERLESS SECURITY TOOLBOX .................................................................................................. 47 6.1 SECURITY OF SERVERLESS COMPONENTS FROM PUBLIC REPOSITORIES .............................................. 47 6.2 SYSTEM CALL OBFUSCATION FOR TEE-BASED WORKLOADS ............................................................. 50 6.3 SECURING FUNCTION-TO-FUNCTION AND FUNCTION-TO-SERVICE COMMUNICATION ........................ 51 7 CONCLUSIONS ......................................................................................................................................... 53 ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 5 - August 31, 2025 List of Tables Table 1: The applicability of attack vectors by deployment model. A filled dot indicates that an attack vector is applicable; an empty dot indicates it is not applicable ............................................................ 17 Table 2: Vulnerability statistics per repository using data collected from Trivy (blue) and Grype (red), respectively ............................................................................................................................................ 20 Table 3: Breakdown of IaC templates analysed in our serverless repository dataset ............................ 26 ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 6 - August 31, 2025 List of Figures Figure 1. A simplified overview of the ELASTIC architecture. The areas of interest for this deliverable are highlighted in red. ............................................................................................................................ 14 Figure 2. CDF of vulnerability counts per serverless component .......................................................... 21 Figure 3. Vulnerability severity using data from Trivy (left) and Grype (right) ................................... 22 Figure 4. Trivy vs. Grype vulnerability similarity ................................................................................. 22 Figure 5. Relationship between serverless components compressed with various compression algorithms and the number of engines that successfully detect them ...................................................................... 24 Figure 6. Misconfiguration severity reported by Trivy for (a) AWS Serverless Repository and (b) GitHub .................................................................................................................................................... 26 Figure 7. Lexical analysis based on Damerau-Levenshtein distance, applied to image names (left) and usernames (right) .................................................................................................................................... 27 Figure 8. Confidential Wasm applications in the obfuscation scenario (a) and in the TEE scenario (b) ................................................................................................................................................................ 30 Figure 9. Example of C wrapping code for running SQL commands using SQLite API ...................... 40 Figure 10. Average feature importance score (Gain) across all runs (combination size of 4) ............... 43 Figure 11. Average feature vector across all input feature vectors per database engine (combination size of 4) ........................................................................................................................................................ 43 Figure 12. Accuracy and F1-score as a function of the combination size ............................................. 45 Figure 13. Accuracy and F1-score as a function of the maximum number of syscalls considered per trace. From every real-workflow trace, only a subset of syscalls–from the beginning to a varying cutoff point– was considered for feature extraction. ........................................................................................ 46 ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 7 - August 31, 2025 List of Abbreviations ACL Access Control List API Application Programming Interface AoT Ahead-of-Time ARNs Amazon Resource Names AWS SAM AWS Serverless Application Model AWS SAR AWS Serverless Application Repository CDF Cumulative Distribution Function CORS Cross-Origin Resource Sharing CNN Convolutional Neural Network CVEs Common Vulnerabilities and Exposures CVSS Common Vulnerability Scoring System D#.# Deliverable #.# DL Damerau-Levenshtein EC European Commission FaaS Function-as-a-Service FQID Fully Qualified Image Identification gRPC Remote Procedure Call HTTP Hypertext Transfer Protocol IaC Infrastructure as Code IAM Identity and Access Management IPFS InterPlanetary File System IR Intermediate Representation KPIs Key Performance Indicators LLM Large Language Model LLVM Low Level Virtual Machine ML Machine Learning MQTT Message Queuing Telemetry Transport OLLVM Obfuscator-LLVM OS Operating System PEPs Policy Enforcement Points RNN Recurrent Neural Network SGX Software Guard Extensions SQL Structured Query Language ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 8 - August 31, 2025 TCB Trusted Computing Base TEE Trusted Execution Environment TLS Transport Layer Security WAL Write-Ahead Logging files WAMR WebAssembly Micro Runtime WASI WebAssembly System Interface WAT WebAssembly Text Wasm WebAssembly WP Work Package ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 9 - August 31, 2025 Executive Summary D2.2: Serverless FaaS with Lightweight Containers presents our work on designing secure, privacy-aware and architecture-agnostic execution mechanisms for Wasm-based serverless workloads. This deliverable reports on the results of Task 2.2, which addresses the security of Wasm serverless functions—particularly in contexts where developers rely on components from public repositories and when Wasm applications are executed within TEEs. This document: ● Identifies key attack vectors in public serverless repositories: We uncover five major risks in public repositories including: (i) vulnerable third-party libraries, (ii) malicious components hidden within compressed artifacts, (iii) usage of sensitive parameters in Docker run commands, (iv) insecure configurations in Infrastructure-as-Code (IaC) templates, and (v) typo-squatting attacks that exploit naming similarities. ● Performs a large-scale analysis of the serverless ecosystem in public repositories: By examining 2,758 components from five major repositories and 125,936 IaC templates, the study provides a representative overview of current security practices and associated risks in serverless deployments. ● Introduces a fingerprinting attack against confidential Wasm applications: We propose a novel side-channel technique that leverages system call traces to infer internal components—such as embedded Structured Query Language (SQL) engines—within confidential Wasm applications. ● Consolidates best practices into a Serverless Security Toolbox: We present a threelayered defence-in-depth framework covering supply chain, execution, and interaction layers. The toolbox provides actionable, experimentally grounded guidance on securing serverless components from public repositories, mitigating side-channel leakage in TEE-based Wasm workloads, and protecting inter-function and function-to-service communications. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 16 - August 31, 2025 previously undocumented Docker parameters that can be exploited for malicious purposes and assess the susceptibility of these repositories to typo-squatting attacks. To this end, we collect and analyse 2,758 serverless components from five widely-used public repositories among developers and enterprises: (i) Docker Hub 11 , (ii) GitHub 12 , (iii) AWS Serverless Application Repository (SAR) 13 , (iv) Serverless Framework 14 and (v) Red Hat Quay 15 . Our selection includes one repository dedicated to serverless plugins and four hosting serverless functions, spanning both well-maintained platforms (e.g., AWS SAR and Red Hat Quay) and highly popular but less regulated ecosystems such as Docker Hub and GitHub. Additionally, we analyse 125,936 IaC templates across three widely used frameworks including Terraform, CloudFormation and AWS SAM. By examining multiple repositories and diverse attack vectors, we aim to provide a representative assessment of current security practices in public serverless ecosystems. 4.2 Background and motivation 4.2.1 Serverless deployment models Serverless functions can be deployed using various methods, including: (i) packaging the function as a Docker container image 16 , 17 , 18 , (ii) uploading a pre-packaged ZIP folder containing the functions’ code and dependencies 19 , 20 , 21 , (iii) writing code directly in the cloud provider’s console editor 22 , (iv) using YAML templates or configuration files that specify the deployment details, resources and permissions of the serverless functions to be deployed and (v) using IaC frameworks, such as AWS CloudFormation, to automate the deployment and management of serverless functions. Regardless of the method, developers remain responsible for providing the application code. In recent years, it has become increasingly common to accelerate development by integrating components from public repositories. However, this introduces significant security risks, as discussed in the next section. 11 Docker hub, https://hub.docker.com/. [Accessed: Jul. 21, 2025]. 12 Github. https://github.com/. [Accessed: Jul. 21, 2025]. 13 AWS serverless public repository. https://aws.amazon.com/serverless/serverlessrepo/. [Accessed: Jul. 21, 2025]. 14 Serverless framework plugins. https://www.serverless.com/plugins/. [Accessed: Jul. 21, 2025]. 15 Red Hat Quay. https://quay.io/ (2023). [Accessed: Jul. 21, 2025]. 16 Deploy Lambda functions with container images. https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/deploy-lambda-functions-with-container-images.html. [Accessed: Jul. 21, 2025]. 17 GCP Cloud Run: Serverless Deployment. https://medium.com/@109manojsaini/serverless-deployment-cloud-run-3332c3817ef9 (ND). [Accessed: Jul. 21, 2025]. 18 Create your first containerized functions on Azure Container Apps. https://learn.microsoft.com/en-us/azure/azure-functions/functions-deploy-container-apps. [Accessed: Jul. 21, 2025]. 19 Zip deployment for Azure Functions. https://learn.microsoft.com/en-us/azure/azure-functions/deployment-zip-push. [Accessed: Jul. 21, 2025]. 20 Deploy a Cloud Function. https://cloud.google.com/functions/docs/deploy. [Accessed: Jul. 21, 2025]. 21 Deploying Lambda functions as .zip file archives.. [Accessed: Jul. 21, 2025]. https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-zip.html. [Accessed: Jul. 21, 2025]. 22 AWS CLI Command Reference. https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html. [Accessed: Jul. 21, 2025]. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 17 - August 31, 2025 Table 1: The applicability of attack vectors by deployment model. A filled dot indicates that an attack vector is applicable; an empty dot indicates it is not applicable 4.2.2 Attack vectors in public serverless repositories We identify five primary attack vectors (V1 –V5) that pose significant security risks to public serverless repositories. It is important to note that some attack vectors are relevant only to specific deployment methods (see Table 1) (V1) Vulnerable third-party libraries: Serverless components typically rely on third-party libraries, many of which contain known vulnerabilities that introduce security risks 23 . Even when patches are available, outdated libraries often remain in use for extended periods, offering adversaries ample opportunities to exploit those weaknesses 24 . The rapid development cycles inherent to serverless applications make them particularly vulnerable to these risks. (V2) Malicious serverless components or IaC templates: Many repositories allow anyone to upload serverless components or IaC templates after a simple registration process, enabling adversaries to easily distribute malicious content 25 , 26 . In the case of serverless components, most platforms support uploading pre-packaged compressed archives that bundle both application code and its dependencies, creating opportunities for more sophisticated attacks. Compressed formats can be exploited to better obfuscate malicious behaviour, making detection by traditional security tools significantly more difficult. (V3) Risky parameters in “run commands”: Some repositories (e.g., Docker Hub) allow contributors to provide execution instructions specifying how their components should be run. Adversaries can exploit this feature and include malicious Docker run commands that contain risky parameters (e.g., –privileged or –pid=host). Users who download these components are likely to follow the provided (malicious) run commands, potentially compromising container isolation and jeopardising the security of the underlying host. (V4) Misconfigurations in IaC templates: IaC tools (e.g., AWS CloudFormation) are widely used to specify and deploy serverless functions in production environments. They enable developers to declaratively define the serverless functions and their associated resources, configurations, permissions and policies in a structured and repeatable manner through templates. It is common practice for developers to contribute their IaC templates and reuse those shared by others. However, to date, no systematic study has examined whether such 23 Hacking serverless runtimes profiling lambda, azure, and more. https: //www.blackhat.com/docs/us-17/wednesday/us-17Krug-Hacking-Severless-Runtimes.pdf (2024). [Accessed: Jul. 21, 2025]. 24 Ladisa, P., Plate, H., Martinez, M., Barais, O.: Sok: Taxonomy of attacks on open-source software supply chains. In: S&P. pp. 1509–1526 (2023) 25 Franco, J., Acar, A., Aris, A., Uluagac, S.: Forensic analysis of cryptojacking in host-based docker containers using honeypots. In: ICC. pp. 4860–4865 (2023) 26 Dahlmanns, M., Sander, C., Decker, R., Wehrle, K.: Secrets Revealed in Container Images: An Internet-wide Study on Occurrence and Impact. In: ASIACCS. pp.797–811 (2023) ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 18 - August 31, 2025 templates contain misconfigurations or what the security consequences of those misconfigurations can be. (V5) Typo-squatting attacks: Various naming conventions such as Docker’s Fully Qualified Image Identification (FQID) 27 and AWS’s Amazon Resource Names (ARNs) 28 are used to uniquely identify serverless components within repositories. Because developers often enter these names manually (e.g., via terminal or editor), typographical errors are common. Adversaries can exploit this by registering malicious components with names that closely resemble those of popular or trusted ones. This typo-squatting technique leverages human error to surreptitiously distribute malicious serverless components, increasing the likelihood of accidental installation and execution by unsuspecting users. 4.2.3 Threat model We consider adversaries capable of uploading vulnerable (V1) or malicious components (V2) to these repositories, posing significant risks to unsuspecting users who use them. In doing so, adversaries can also supply execution instructions that include Docker run commands with sensitive parameters (e.g., –privileged) (V3), exploiting the tendency of many users to follow the provided instructions 29 . Similarly, adversaries may embed sensitive parameters in the IaC templates they upload to public repositories, causing developers to unknowingly misconfigure serverless applications and inadvertently expose critical information (V4). Finally, when uploading components to these repositories, adversaries can select component names that closely resemble popular entries in the repository (V5), aiming to exploit typographical errors made by developers when retrieving serverless components. Such typographical mistakes can lead to the inadvertent inclusion of malicious serverless components in applications 30 . 4.3 Serverless repository analysis framework In this section, we describe the process used to discover and retrieve serverless components from public repositories, and evaluate their susceptibility to the five attack vectors we consider. 1. Data collection. To automate the extraction of serverless component data from the selected repositories, we developed custom web scrapers using frameworks such as BeautifulSoup 31 and Selenium 32 , tailored to the specific structure and characteristics of each repository. Using these scrapers, we collected key metadata, including: (i) the component name, (ii) the associated pull command or GitHub URL and (iii) the recommended execution instructions (when available). In some cases, this process required performing authenticated queries and adhering to repository-imposed request limits. For repositories hosting both serverless and non-serverless 27 Exploring the Unchartered Space of Container Registry Typosquatting. In: USENIX Security Symposium (USENIX Security) (2022) 28 Identify AWS resources with Amazon Resource Names (ARNs). https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html. [Accessed: Jul. 21, 2025]. 29 Liu, P., Ji, S., Fu, L., Lu, K., Zhang, X., Lee, W.H., Lu, T., Chen, W., Beyah, R.: Understanding the Security Risks of Docker Hub. In: ESORICS. pp. 257–276 (2020) 30 Exploring the Unchartered Space of Container Registry Typosquatting. In: USENIX Security Symposium (USENIX Security) (2022) 31 L. Richardson, Beautiful Soup. [Online]. Available: https://www.crummy.com/software/BeautifulSoup/. Apr. 2007. [Accessed: Jul. 21, 2025]. 32 Selenium. [Online]. Available: https://www.selenium.dev/. 2024. [Accessed: Jul. 21, 2025]. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 19 - August 31, 2025 components, we applied a two-step filtering method to retrieve only their serverless components, as done by Eskandani et al. 33 . 2. Vulnerability analysis. Next, we performed a security analysis of the libraries included in the retrieved serverless components using Trivy 34 and Grype 35 , two widely used and opensource vulnerability scanners. Both tools extract metadata, package information and libraries from container images or source code, and cross-reference them against multiple vulnerability databases 36 . The identified vulnerabilities are classified into five severity levels according to their Common Vulnerability Scoring System (CVSS) 3.1 scores: (i) Critical (9.0–10.0), (ii) High (7.0–8.9), (iii) Medium (4.0–6.9), (iv) Low (0.1–3.9) and (v) Unknown (excluded from the analysis). In the case of Docker Hub and Red Hat Quay, the vulnerability scanners take pulled images as input, while in other repositories, the input is the source code of the serverless component to be analysed. Each serverless component was scanned separately with both tools and the results were stored in separate files. Using multiple scanners helps account for tool variability, as each may rely on different vulnerability databases and detection heuristics, potentially identifying distinct sets of vulnerabilities. 3. Hiding malicious behaviour in compressed serverless components. To examine whether compression can be used to conceal malicious behaviour in serverless components, we used VirusTotal 37 , a widely used platform that aggregates results from numerous antivirus engines. Our hypothesis was that adversaries could exploit common compression formats to evade detection. To test this, we generated serverless components compressed with widely used algorithms, creating both benign samples and variants containing embedded malware. We submitted these samples to VirusTotal and analysed the detection rates reported by its integrated antivirus engines to evaluate their ability in order to identify malicious serverless components. 4. Identification of risky Docker parameters. We analysed the execution instructions provided by component owners to identify docker run commands that include sensitive parameters potentially exploitable for security attacks. Our analysis consisted of two stages. First, we examined all serverless components hosted on Docker Hub for the presence of sensitive parameters previously documented in the literature 38 . In the second stage, we extended our investigation and discovered several previously undocumented Docker parameters that introduce significant security risks. These newly identified parameters could enable adversaries to escalate privileges, bypass security controls or gain unauthorised access, increasing the potential impact of compromised serverless components distributed through public repositories. 5. Finding sensitive parameters in IaC templates. We retrieved and analysed a large corpus of IaC templates to determine whether they contained sensitive parameters or insecure configurations that could be exploited by adversaries to compromise serverless applications. Using Trivy, we scanned these templates 39 for misconfigurations across widely used frameworks, including Terraform, AWS CloudFormation and AWS SAM, and then classified 33 Eskandani, N., Salvaneschi, G.: The Wonderless Dataset for Serverless Computing. In: 2021 IEEE/ACM 18th International Conference on Mining Software Repositories (MSR). pp. 565–569 (2021). 34 Trivy Documentation. [Online]. Available: https://aquasecurity.github.io/trivy/v0.44/docs/. [Accessed: Jul. 21, 2025]. 35 Grype Documentation. [Online]. Available: https://docs.anchore.com/current/docs/. [Accessed: Jul. 21, 2025]. 36 Ladisa, P., Plate, H., Martinez, M., Barais, O.: Sok: Taxonomy of attacks on open-source software supply chains. In: S&P. pp. 1509–1526 (2023) 37 Virustotal. [Online]. Available: https://www.virustotal.com/. 2024. [Accessed: Jul. 21, 2025]. 38 Liu, P., Ji, S., Fu, L., Lu, K., Zhang, X., Lee, W.H., Lu, T., Chen, W., Beyah, R.: Understanding the Security Risks of Docker Hub. In: ESORICS. pp. 257–276 (2020) 39 Trivy - infrastructure as code (iac). [Online]. Available: https://trivy.dev/v0.19.2/misconfiguration/iac/. [Accessed: Jul. 21, 2025]. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 20 - August 31, 2025 the identified issues into four severity levels. For parameters frequently associated with security risks, we conducted in-depth analysis to evaluate their potential impact and trace their underlying root causes. In parallel, we manually reviewed the IaC templates to uncover previously undocumented misconfigurations that may not be detected through Trivy’s automated analysis. 6. Detection of potential typo-squatting attacks. To identify potential typo-squatting attacks, we measured the similarity between component names using the Damerau-Levenshtein (DL) distance metric, which quantifies the minimum number of operations (i.e., insertions, deletions, substitutions or transpositions) required to transform one string into another. For each repository, we extracted both the username and image name associated with every serverless component and performed exhaustive pairwise comparisons to detect suspiciously similar naming patterns indicative of typo-squatting attempts. We then focused on name pairs with low DL distances, as these indicate identical or highly similar names. 4.4 Application security risks In this section, we assess the extent to which the collected serverless components are exposed to application-level security risks (RQ1). We begin by analysing the presence of known vulnerabilities in third-party libraries included in these components (V1). We then investigate the potential for concealing malicious behaviour when these components are distributed in compressed formats (V2). 4.4.1 Vulnerability Analysis in Third-party Libraries Table 2: Vulnerability statistics per repository using data collected from Trivy (blue) and Grype (red), respectively Statistical analysis of vulnerabilities across repositories. To characterise the vulnerability landscape of each repository, we begin by reporting key statistical metrics—including the mean, median, minimum, maximum and standard deviation of vulnerability counts—based on data obtained from both Trivy and Grype (see Table 2). Our findings reveal a consistent discrepancy between both tools, with Grype systematically reporting higher vulnerability counts. This difference is rooted in their distinct design philosophies: Grype prioritises sensitivity and broad detection coverage at the cost of a higher false positive rate 40 , 41 , while Trivy adopts a more conservative approach focused on minimising false positives that may 40 D. Luhring, Why Chainguard uses Grype as its first line of defense for CVEs. [Online]. Available: https://www.chainguard.dev/unchained/why-chainguard-uses-grype-as-its-first-line-of-defense-for-cves. 2023. [Accessed: Jul. 21, 2025]. 41 T. Dunlap, Z. Newman, Stemming the tide of false positive vulnerabilities. [Online]. Available: https://www.chainguard.dev/unchained/stemming-the-tide-of-false-positive-vulnerabilities. 2023. [Accessed: Jul. 21, 2025]. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 21 - August 31, 2025 occasionally lead to missed vulnerabilities 42 . Among the repositories we analysed, Docker Hub and Red Hat Quay exhibit the highest mean and median vulnerability counts, as well as the largest variability among components. GitHub falls in an intermediate position, with several components exhibiting significant vulnerabilities, though generally fewer than those in Docker Hub and Red Hat Quay. Conversely, we found that the Serverless Framework and AWS SAR consistently report lower vulnerability counts. Figure 2. CDF of vulnerability counts per serverless component Distribution of vulnerabilities across serverless components. To further understand the distribution of vulnerabilities within repositories, we analyse the Cumulative Distribution Function (CDF) of vulnerability counts per serverless component based on Trivy scan results (see Figure 2). Our results show that approximately 80% of Docker Hub components and 60% of Red Hat Quay components have more than 100 vulnerabilities. GitHub presents a slightly better security posture: around 40% of its components contain between 10 and 100 vulnerabilities, with 10% exceeding 100 vulnerabilities. By contrast, serverless components from the AWS SAR and Serverless Framework are significantly less affected. Many components have no known vulnerabilities, and most affected ones contain fewer than 10, with only a few exceeding 100. 42 Multiple False Positive and False Negative CVEs. [Online]. Available: https://github.com/aquasecurity/trivy/issues/3010. 2023. [Accessed: Jul. 21, 2025]. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 22 - August 31, 2025 Figure 3. Vulnerability severity using data from Trivy (left) and Grype (right) Distribution of vulnerability severity across repositories. While previous analyses focused on vulnerability counts, we also examined severity, a key factor in assessing real-world security risk (see Figure 3). Although Docker Hub and Red Hat Quay report the highest total vulnerabilities, the proportion of critical and high-severity issues is relatively low, only 5% critical and 29% high in Docker Hub, and 3% critical and 23% high in Red Hat Quay. In contrast, AWS SAR and Serverless Framework, which have the lowest average vulnerability counts per component (see Table 2), show the highest proportions of severe vulnerabilities: 68% in AWS SAR and 57% in Serverless Framework are classified as critical or high. Figure 4. Trivy vs. Grype vulnerability similarity Comparison of Grype and Trivy detection results. Although Trivy and Grype use similar techniques for vulnerability detection, their results often differ significantly (see Table 2). To quantify this divergence, we computed the Jaccard similarity between the sets of vulnerabilities identified by each tool (see Figure 4). A score of 1 indicates complete agreement while a score of 0 indicates no overlap. For components from AWS SAR, GitHub, and the Serverless Framework, many showed a Jaccard similarity of 1, suggesting identical results. However, manual inspection revealed that many of these components had no detected vulnerabilities. In contrast, components from Docker Hub and Red Hat Quay showed greater discrepancies, with fewer instances of high similarity. These findings underscore the importance of using multiple scanners in parallel to gain a more complete view of security risks. Importantly, there is no ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 23 - August 31, 2025 universally accepted ‘ground truth’ for vulnerability detection. Some organisations prioritise precision by using the intersection of scanner outputs to minimise false positives, while others prioritise recall by taking the union to maximise coverage, even at the cost of increased false positives. 4.4.2 Hiding Malicious Behaviour in Compressed Serverless Components To evaluate the potential for concealing malicious behaviour within compressed serverless components, we randomly selected 1,794 components from public repositories, including 356 from AWS SAR, 657 from GitHub, 352 from the Serverless Framework, 354 from Docker Hub and 75 from Red Hat Quay. We compressed each component in its original form using eight widely adopted compression formats: 7z, tar, tar.bz2, tar.gz, tar.lzma, tar.xz, tar.zst and zip. As a preliminary step, we verified that none of the selected components was flagged as malicious by VirusTotal. We then selected six malicious files obtained from reputable open-source malware repositories: (i) the eicar.txt file for antivirus testing, (ii) a Python remote access trojan, (iii) a Java infector, (iv) a PHP backdoor, (v) a Python backdoor and (vi) a Python trojan. This allowed us to generate malicious samples by injecting one malicious file at a time into each serverless component and compressing the modified components with each compression format. We examined how the choice of compression format affects the detection of malicious behaviour. Figure 5 shows the CDF of antivirus engines that flagged malicious components for each compression format. Although all injected files were detected by at least one engine, components compressed with 7z and tar.zst were flagged by significantly fewer engines, indicating lower detection reliability. This is concerning because, due to trade-offs between false positives and false negatives, a component is typically considered malicious only if flagged by a minimum number of engines. In prior work, this threshold was set at five engines 43 . In our analysis, we observed several cases where malicious components compressed with specific formats fell below this threshold, suggesting that embedding malicious behaviour within compressed serverless components could be an effective evasion technique. 43 L. Richardson, Beautiful Soup. [Online]. Available: https://www.crummy.com/software/BeautifulSoup/. Apr. 2007. [Accessed: Jul. 21, 2025]. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 24 - August 31, 2025 Figure 5. Relationship between serverless components compressed with various compression algorithms and the number of engines that successfully detect them 4.5 Configuration and deployment security risks In this section, we examine the security risks associated with the configuration and deployment of serverless components (RQ2), focusing on three attack vectors: (i) risky Docker run parameters (V3), (ii) exposure of sensitive parameters in IaC templates (V4) and (iii) potential typo-squatting attacks (V5) 4.5.1 Sensitive Parameter Misuse in Docker Run Commands We analysed the Docker run commands included in the execution instructions for serverless components hosted on Docker Hub (V3). We first targeted Docker parameters previously identified as sensitive by Liu et al. 44 , including –privileged, -v, and –pid. These options can undermine container isolation and host integrity. For example, the -v <src>:<dest> option mounts host directories into a container, potentially leaking sensitive files; –privileged grants unrestricted access to host resources; and –pid=host allows containerised processes to view and interact with all host processes, facilitating reconnaissance or privilege escalation. Our analysis found 137 uses of -v, two instances of –privileged but no occurrences of –pid. Identification of previously undocumented risky Docker parameters. Beyond measuring the prevalence of known risky Docker parameters in public serverless components, our analysis uncovered three previously undocumented parameters that pose significant security risks. 44 L. Richardson, Beautiful Soup. [Online]. Available: https://www.crummy.com/software/BeautifulSoup/. Apr. 2007. [Accessed: Jul. 21, 2025]. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 25 - August 31, 2025 1. Hard-coded credentials. We discovered a case where AWS access keys were hard-coded directly into a Docker run command. Executing such commands may inadvertently expose sensitive credentials, allowing adversaries to take control of the associated cloud environment. This can lead to a range of attacks, including unauthorised access to S3 buckets or launching cryptojacking campaigns 45 . To mitigate this risk, we recommend avoiding credential injection via command-line arguments and instead using secure methods such as Docker secrets (e.g., –secret aws_key and –secret aws_secret) for handling sensitive information. 2. Sensitive information passed via environment variables. We found 47 instances where the - e parameter was used to pass sensitive information, such as credentials, tokens or keys, to containers. Adversaries with access to the Docker daemon (e.g., external adversaries who exploited a misconfiguration) can retrieve these values using commands like docker inspect. This exposure could lead to unauthorised access to cloud services, data exfiltration or financial abuse. As with hard-coded credentials, this risk can be mitigated by using Docker secrets. 3. Mounting the Docker daemon socket within containers. We identified a case where the Docker daemon socket (/var/run/docker.sock) was mounted directly into a container. This configuration effectively grants the container full control over the Docker daemon, allowing an adversary who compromises the container to escalate privileges and gain control over the host system. The security implications are comparable to those of the –privileged flag and are widely regarded as a critical misconfiguration. 4.5.2 Security Analysis of IaC Templates Given their critical role in automating the deployment of serverless applications, we conducted an in-depth analysis of IaC templates across three widely adopted frameworks: (i) Terraform, (ii) AWS CloudFormation and (iii) AWS Serverless Application Model (SAM) (V4 ). Our dataset includes IaC templates from AWS SAR and GitHub, as container-based platforms such as Docker Hub, Red Hat Quay and Serverless Framework typically do not include IaC 45 R. Lakshmanan, Elektra-leak cryptojacking attacks exploit aws IAM credentials exposed on github. [Online]. Available: https://thehackernews.com/2023/10/elektra-leak-cryptojacking-attacks.html. 2023. [Accessed: Jul. 21, 2025]. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 32 - August 31, 2025 ● Global section: Declares global variables used by the module, along with their types and initial values. Globals may be mutable or immutable. ● Start Section (optional): Identifies a single function to be invoked automatically at module instantiation. This is typically used to initialise the module’s internal state before execution begins. By default, Wasm binaries reveal substantial information about an application’s internal structure to any entity with access to the binary. For example, the Wasm instruction set architecture provides structured control flow primitives that immediately reveal information on the structure of the code that would otherwise need to be adduced heuristically by a decompiler. Several tools can convert Wasm binaries into a human-readable format known as WebAssembly Text (WAT). A widely used tool, wasm2wat, disassembles binaries into a structured textual representation. While such tools facilitate debugging, analysis, and auditing, they also substantially lower the barrier to reverse engineering, introducing potential security and intellectual property risks for Wasm-based applications. 5.2.3 Trusted Execution Environments TEEs provide hardware-enforced isolated execution environments designed to protect the confidentiality and integrity of code and data, even in the presence of a compromised or malicious operating system 63 . While implementations vary, all TEEs enforce strong isolation guarantees that prevent unauthorised access to protected resources by privileged software such as the Operating System (OS) or hypervisor. Depending on the architecture, TEEs may take different forms: enclave-based TEEs (e.g., Intel SGX) use dedicated secure memory regions within user space, while VM-based TEEs (e.g., Intel TDX) provide isolated virtual machines, and split-world TEEs (e.g., Arm TrustZone) divide execution between a secure world and a normal world. In each case, the secure execution context is isolated from the rest of the system, and its memory and state remain inaccessible to untrusted components. One of the key advantages of TEEs is their ability to minimise the Trusted Computing Base (TCB), thereby reducing the overall attack surface. Modern TEEs 64 , 65 , 66 , 67 also support the execution of arbitrary application logic within the isolated environment, often with near-native performance, making them particularly suitable for protecting sensitive workloads in cloud, edge, and embedded systems. Recent research has explored integrating Wasm runtimes with TEEs to enhance the security of Wasm applications. For example, the WebAssembly Micro Runtime (WAMR) has been ported to run within Intel SGX enclaves, enabling Wasm applications to benefit from SGX's hardwarebacked isolation on untrusted platforms 68 . Parallel efforts have also introduced a trusted Wasm runtime for ARM TrustZone, expanding TEE support beyond Intel architectures 69 . 63 Microsoft Learn, Trusted Execution Environments. [Online]. Available: https://learn.microsoft.com/enus/azure/confidential-computing/trusted-execution-environment. Jul. 2025. [Accessed: Jul. 21, 2025]. 64 Intel SGX. [Online]. Available: https://www.intel.com/content/www/us/en/products/docs/accelerator-engines/softwareguard-extensions.html. [Accessed: Jul. 21, 2025]. 65 Arm TrustZone. [Online]. Available: https://www.arm.com/technologies/trustzone-for-cortex-a. [Accessed: Jul. 21, 2025]. 66 AMD SEV. [Online]. Available: https://www.amd.com/en/developer/sev.html. [Accessed: Jul. 21, 2025]. 67 Intel TDX. [Online]. Available: https://www.intel.com/content/www/us/en/developer/tools/trust-domainextensions/overview.html. [Accessed: Jul. 21, 2025]. 68 J. Ménétrey, M. Pasin, P. Felber, V. Schiavoni,. Twine: An embedded trusted runtime for webassembly. In IEEE 37th International Conference on Data Engineering (ICDE), 2021. p. 205-216, 69 J. Ménétrey, M. Pasin, P. Felber, V. Schiavoni, Watz: A trusted webassembly runtime environment with remote attestation for trustzone. In IEEE 42nd International Conference on Distributed Computing Systems (ICDCS), 2021. p. 1177-1189 ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 33 - August 31, 2025 5.2.4 Source code, IR and Binary Obfuscation Obfuscation techniques are commonly used to protect applications from reverse engineering, while preserving their original functionality. These techniques can be applied at various stages of the software development lifecycle, including the source code, intermediate representation (IR) and binary levels. Source-level obfuscation (e.g., Tigress 70 for C) modifies high-level code to hinder analysis. However, it is language-specific, requires access to the source code and may lose effectiveness after compilation. IR-level obfuscation targets compiler bytecode (e.g., LLVM via OLLVM 71 ), offering improved portability across backends. Still, it depends on source availability and does not fully capture the semantics of the final binary. Binary-level obfuscation is often considered the most effective and portable approach. It operates directly on compiled executables, enabling fine-grained transformations independent of source language or build toolchain and provides stronger resistance to reverse engineering. In the context of WebAssembly, WASMixer 72 is a prominent tool specifically designed to protect Wasm binaries from reverse engineering. WASMixer supports four obfuscation techniques—two targeting data obfuscation and two targeting code obfuscation. Developers can apply these techniques individually or in combination to tailor the level of protection. Data obfuscation. This technique aims to prevent attackers from extracting sensitive or meaningful information by inspecting a Wasm binary. Potential leakage sources include function names in the Import/Export sections, metadata in Custom or debug sections, and plaintext strings embedded in linear memory. While import/export names—such as WASI syscall identifiers—are typically hard to obfuscate and reveal limited application logic, custom sections often carry rich metadata that may expose proprietary design elements. Static inspection can reveal function signatures, memory and table layouts, and embedded constants, all of which can aid reverse engineering if not properly obfuscated. WASMixer addresses this via Name Obfuscation, which replaces function names and other identifiers with random strings, reducing the potential for leakage. A more critical concern lies in the module’s linear memory, where plaintext data can disclose application functionality or embedded secrets. To mitigate this, WASMixer applies Memory Obfuscation, using lightweight XOR-based encryption on store operations, paired with decryption on loads. This approach protects runtime data with minimal performance overhead. Code obfuscation. Code obfuscation techniques aim to hinder reverse engineering by transforming the control flow of a program while preserving its original functionality. Common strategies include control-flow flattening, aliasing disruption and Collatz-based opaque predicates. Control flow flattening transforms a linear sequence of instructions into multiple shuffled code blocks embedded within a switch-case structure. At runtime, the original control flow is reconstructed by iterating through these cases, making the static control flow appear disordered and hard to analyse. Alias disruption replaces direct function calls with indirect calls, complicating call graph reconstruction and confusing static analysers. Opaque predicates are expressions with constant outcomes that appear input-dependent, forcing analysers to explore all possible execution paths and triggering path explosion. WASMixer further enhances these techniques by integrating Collatz-based opaque predicates, which introduce mathematically 70 Tigress. [Online]. Available: https://tigress.wtf/. [Accessed: Jul. 21, 2025]. 71 OLLVM17. [Online]. Available: https://github.com/DreamSoule/ollvm17. [Accessed: Jul. 21, 2025]. 72 S. Cao, N. He, Y. Guo, H. Wang, WASMixer: Binary Obfuscation for WebAssembly, In: European Symposium on Research in Computer Security. Cham: Springer Nature Switzerland, 2024. p. 88-109. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 34 - August 31, 2025 complex but deterministic logic. These are used to select control flow paths in flattened code and to index indirect calls in alias disruption, resulting in two specialised variants: FlattenCollatz and AliasCollatz. 5.3 Threat Model In this section, we consider a scenario where a developer wants to execute a Wasm application in a confidential way, i.e., without revealing the application’s logic to others. To this end, we examine two alternative approaches. In the first, the developer applies binary-level obfuscation techniques (e.g., using tools such as WASMixer) to protect the Wasm modules before uploading them to the platform, where they are executed by the Wasm runtime chosen by the platform operator. Alternatively, instead of obfuscating the binary in advance, the developer may choose to run the application inside a TEE such as Intel SGX. In this case, we assume that a remote attestation is performed first, allowing the developer to establish a secret cryptographic key with the TEE (one that is unknown to the platform provider). This key is then used to encrypt the application before it is uploaded; the TEE subsequently decrypts and executes the application within a hardware-isolated environment. The adversary’s goal is to infer confidential information about the executing application—such as its identity or the inclusion of specific code components—which could enable more targeted, efficient or stealthy attacks. We assume a powerful attacker with root-level access to the host system running the victim’s Wasm module. This adversary may be either a malicious tenant who has escalated privileges or an honest-but-curious cloud or edge provider. In both cases, the attacker is capable of passively observing and analysing system-level events emitted at the runtime–kernel boundary during the module’s execution (e.g., system calls). The attack proceeds in two stages: an offline phase followed by an online phase. In the offline phase, the adversary builds a dataset of Wasm applications by collecting binaries from public sources or compiling arbitrary source code into Wasm. Each application is executed under realistic workloads to simulate plausible usage scenarios, while the corresponding system calls are recorded. These traces are then used to train a machine learning (ML) model. In the online phase, the adversary collects system call traces from the execution of the victim’s Wasm application using the same methodology. These traces are then fed into the pre-trained ML model to infer sensitive information about the victim application. 5.4 Motivation and Technical Challenges While both obfuscation techniques and TEEs are designed to protect Wasm applications against binary-level inspection—either by securing code and data during execution or by concealing control flow and identifiers—they do not shield the application’s interactions with its external environment. This leaves a critical and often overlooked attack surface exposed: system-level events (e.g., system calls), which can serve as unique fingerprints of the application. Importantly, these events are observable by adversaries under our threat model and can be collected passively, without disrupting execution—making such attacks difficult to detect. Gaining insight into the type of application or its internal components may provide a significant advantage to adversaries. With this knowledge, they can search for known vulnerabilities in public databases (e.g., CVEs) that match the identified application or components, enabling them to launch more targeted, efficient, and stealthy attacks. For instance, if attackers learn that MariaDB is being used, they might exploit the remote code execution vulnerability reported in CVE-2021-27928 or the vulnerability reported in CVE-2016-6662. To carry out such an attack, the adversary must replicate the victim’s runtime environment, assemble a representative dataset of confidential Wasm applications, and simulate realistic ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 35 - August 31, 2025 workloads to capture behavioral patterns. Reproducing the runtime environment is relatively tractable, as the ecosystem of Wasm runtimes, obfuscation tools, and TEEs is still limited in scope, and cloud or edge providers often disclose their software stacks. In contrast, constructing a diverse and realistic application dataset remains a key challenge. Currently, no public repository offers a sufficiently broad collection of Wasm applications suitable for fingerprinting, nor are there standardised tools for generating meaningful workloads across varied application domains. To address these limitations, we built our own dataset of Wasm applications. This involved manually compiling several widely used C/C++ programs to WebAssembly—a process made complex by limited support in Wasm toolchains for certain system-level functionalities. We used a standard compiler (clang) and the WAMR runtime without making any modifications to either; the only changes were applied to the applications’ source code. We then employed a combination of benchmarking suites and custom workload generation utilities to simulate realistic execution scenarios. This approach allowed us to systematically capture and analyse the system-level behavior of Wasm applications under conditions representative of confidential deployments. 5.5 Methodology This section details the methodology used to perform the proposed fingerprinting attack on Wasm applications, which also reflects the steps an adversary would need to follow. 1Building the dataset. The first step involves constructing a dataset of Wasm applications that reflect the adversary’s intended fingerprinting targets—referred to as target objects. These targets may include specific libraries, software components, or embedded components (e.g., databases) that can be reused across Wasm applications. Given the absence of a publicly available dataset of server-side Wasm applications, the adversary must curate their own by sourcing relevant code from public repositories (e.g., GitHub), developer communities, and official distribution platforms that host software likely to be compiled into Wasm for cloud or edge deployment. To generate the binary samples, the de facto standard toolchain for serverside Wasm is Clang, typically used in conjunction with the WASI-SDK. One possible strategy for building the dataset is to crawl these code sources using search terms indicative of server-side Wasm compatibility, such as “WASI”, “Wasmtime” or “WAMR”. Another effective approach involves targeting software categories likely to appear within victim applications, such as embedded databases. The adversary can then locate relevant source code in these categories and compile it to Wasm/WASI format. However, compiling source code to Wasm is not a straightforward process. Even for mature programming languages like C/C++ or Rust, Wasm/WASI lacks full support for several system-level features available on native platforms. For instance, in C/C++, key functionalities such as POSIX signals (SIGINT, SIGTERM), the memory management interface (mmap(), munmap(), mprotect()) and system calls like getpid() are only simulated in WASI. These features are typically stubbed, allowing compilation without modifying the source code but at the cost of true runtime support. Other features, however, are completely absent from the WASI-SDK. For instance, POSIX file locking is not supported, since file descriptor handling is completely abstracted away from Wasm code. Consequently, even though WASI-SDK supports multithreading (via -- target=wasm32-wasi-threads and -pthread), any code relying on file locks must be modified to remove those features. Due to the aforementioned constraints, compiling to Wasm/WASI requires removing unsupported functionalities from the codebase. This process can be very laborious, complex and error-prone, especially when such features are deeply embedded within the application ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 36 - August 31, 2025 logic. Crucially, both the developer and the adversary share the objective of preserving the original functional behavior of the application. Therefore, any code modifications must be minimal and non-invasive, prioritising the removal of problematic constructs over their alteration or replacement. Typical strategies include commenting out unsupported header files, eliminating dependent data types and variables or stubbing unavailable functions with fixed return values to maintain the intended execution flow. 2Setting up the scenario. Once the Wasm applications have been compiled, the adversary must recreate the execution environment in which the victim is expected to run their confidential application. This step ensures that any fingerprinting results are representative and applicable to real-world conditions. In the TEE scenario, the relevant TEE technology—such as Intel SGX—must be deployed on a testbed machine that closely mirrors the hardware and configuration available to the tenant. The corresponding confidential runtime (e.g., TWINE) must then be built and installed within the enclave to accurately mirror the victim’s execution context. In the obfuscation-based scenario, the adversary must generate multiple obfuscated variants of the target applications (e.g., embedded database engines). This process allows the adversary to evaluate how different obfuscation strategies influence the structural properties and system-level observability of the resulting Wasm binaries. 3Workflows definition and training syscall trace collection. With the environment properly set up, the adversary must define realistic execution workflows for each application in the dataset. This step is critical to the success of the fingerprinting attack, as it ensures that the operations likely to be performed by the tenant’s confidential application are adequately reflected in the ML model’s training data. Workflows can be derived from real-world applications that utilise or resemble the target components, as well as from open-source benchmarks, usage documentation, or relevant domain-specific coding guidelines. For instance, if the target objects include embedded relational database engines, widely adopted benchmarking tools—such as TPC benchmarks—can be used to construct representative and meaningful workflows. Once workflows are defined, the adversary collects training syscall traces by executing the Wasm applications under these workflows on the testbed machine. The tracing process must introduce minimal overhead to avoid distorting the syscall patterns, which are critical to effective fingerprinting. To this end, the adversary may use off-the-shelf tools such as strace, or opt for lightweight custom solutions based on eBPF, which can hook into kernel tracepoints (e.g., raw_syscalls:sys_enter and raw_syscalls:sys_exit) for fine-grained and high-performance syscall monitoring. Since cloud and edge providers often execute multiple Wasm modules as threads within a single process, the tracing mechanism must also distinguish syscalls at the thread level. Tools like strace support this through the -f flag, which enables tracing of all threads spawned by the target process. For each workflow associated with a target object, a single syscall trace is recorded and stored for model training. 4Features extraction and ML model training. With the syscall traces collected, the adversary proceeds to select meaningful features for the purpose of fingerprinting confidential Wasm applications. This begins with a preliminary trace analysis to identify patterns or distinguishing characteristics across traces belonging to different target objects. Based on the findings of this analysis, feature vectors are constructed using relevant attributes such as syscall order and sequence patterns, specific syscall input parameters or return values, frequency distributions of syscall types or timing or structural metrics (if available). Each resulting feature vector is then annotated with a class label, typically an integer identifier that corresponds to the target object it represents. Following labelling, the dataset is split—commonly using an 80/20 ratio—into training and testing subsets. The ML model is subsequently trained using the ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 37 - August 31, 2025 training portion of the dataset and evaluated on the remaining samples. The choice of ML model is dependent on the nature of the extracted features. For example, if syscall order is a key feature, sequence-aware models such as Convolutional Neural Networks (CNNs) or Recurrent Neural Networks (RNNs) may be suitable, as they can capture temporal dependencies in the syscall sequences. Conversely, for purely statistical features like syscall frequency, simpler models such as decision trees or support vector machines may suffice. In our experiments, we evaluated various combinations of features and ML models. We found that the attack is most effective when using syscall frequency and the boolean presence of certain flags as features, combined with XGBoost. 5Victim syscall traces collection and ML inference. The first four steps of the methodology outline the offline phase, in which the adversary prepares the fingerprinting model. In the subsequent online phase, the adversary collects syscall traces from the victim’s running application using the same tracing setup described earlier. Once the trace is captured, the same feature extraction process detailed in Section 5.6.2 is applied to produce a feature vector representative of the application’s runtime behavior. This vector is then fed into the previously trained machine learning model, which outputs a class label—an integer corresponding to one of the known target objects in the adversary’s dataset. This predicted label constitutes the model’s final inference, effectively identifying the specific library or component being used by the victim application based solely on its system call behavior. 5.6 Evaluation This section demonstrates that individual Wasm applications produce recognisable systemlevel fingerprints. We focus on Wasm applications built around embedded databases, given their relevance and widespread use in cloud and edge environments. To evaluate the trained model’s performance and generalizability, we test it on syscall traces generated by real-world Wasm applications. These applications were not part of the training set but contain the target objects used to train the ML model. This setup allows us to assess the model’s ability to accurately identify target components in previously unseen and diverse execution contexts. Experimental setup. All Wasm applications, including database engines and real-world targets, were compiled using Clang version 14.0.0-1ubuntu1.1, as provided by WASI-SDK release 24.0. We observed no meaningful variation in syscall traces across different compiler optimisation levels. Therefore, we consistently used the -O2 flag for the TEE scenario, while both -O0 and -O2 were applied in the obfuscation scenario due to WASMixer limitations. All experiments were executed using the iwasm 2.1.0 runtime from WAMR, operating in fast interpreter mode. For the TEE scenario, we run iwasm within an Intel SGX enclave in simulation mode. We also validated the consistency of syscall behaviour under Ahead-of-Time (AOT) execution using wamrc as AOT compiler, and found negligible differences compared to the interpreter mode. Experiments were performed on a machine equipped with an Intel Core i7-10610U CPU (4 cores / 8 threads, 1.80 GHz base frequency), 16 GB of RAM, and running Ubuntu 22.04.5 LTS. Target object dataset. We selected relational (SQL-based) embedded database engines as fingerprinting targets. Integrated directly into application binaries rather than running as standalone services, these engines are particularly relevant in Wasm deployments, where monolithic binaries are preferred—especially in privacy-sensitive contexts. Their ubiquity across data-driven applications increases the attack’s general applicability. Unlike NoSQL systems, which vary widely in data models, SQL engines exhibit similar internal structures and access patterns, making them harder to distinguish via syscall analysis—thus forming a worstcase scenario for adversarial fingerprinting. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 38 - August 31, 2025 We model victim applications as comprising (i) an embedded database engine and (ii) a custom logic wrapper. While the wrapper is unique and generally not fingerprintable, the database engine is typically reused and can be identified through behavioural signatures. We emulate this structure with a generic C wrapper capable of executing multiple representative workflows per engine (see Section 5.6.1). Our analysis focuses on engines operating on on-disk .db files, excluding in-memory databases due to their volatility and unsuitability in constrained environments like Intel SGX. We chose three well-known SQL-based engines: SQLite, LibSQL, and DuckDB. SQLite was already available as a WebAssembly package and compiled successfully using WASI-SDK’s Clang. LibSQL, based on SQLite, required similar effort. DuckDB required significantly more work: although a browser-targeted Emscripten build existed, it was incompatible with WASI and server-side use. We compiled the core DuckDB codebase using WASI-SDK’s clang. Due to WASI-SDK’s incomplete support for exception handling, we removed all instances of try, catch, and throw. We also excluded file-locking logic (see Section 5.5), as well as unsupported headers and syscalls: pwd.h, termios.h, ioctl(0, TIOCGWINSZ, &w), sched_getcpu(), umask(S_IXUSR | S_IRWXG | S_IRWXO), and userspace semaphores from the async_concurrentqueue library. Real-world victim applications dataset. To assess the model’s performance on real-world applications, we sought publicly available software using relational embedded databases. Since our target engines are written in C/C++—and WebAssembly compilation is well supported for these languages—we initially focused on C/C++ applications. However, we found no opensource options with sufficient complexity. We therefore turned to higher-level languages, selecting three representative web applications: Petclinic 73 and JPetStore 74 (Java/Spring MVC), and Tweepee 75 (Python/Flask). The first two simulate a veterinary clinic and a retail pet store, respectively, and are widely used in academic benchmarks. Tweepee, a demo app built with the Peewee ORM (11K+ GitHub stars), models a basic social networking platform. To run these in our setup, we manually ported each application to C. All database interactions were rewritten to use the sqlite3.h API—natively supported by SQLite and LibSQL, and compatible with DuckDB via a wrapper layer. We carefully preserved original behaviors through extensive testing, ensuring that SQL queries remained identical. In Java, this was straightforward as queries were hardcoded; in Python, we reconstructed the exact queries by mapping Peewee ORM statements to their underlying SQL equivalents. For HTTP functionality, we used the lightweight Mongoose networking library to replicate the original web interfaces. While this introduced additional system calls unrelated to the database (i.e., noise), it enabled a more realistic and challenging evaluation scenario, as our ML model was not trained on traces involving networking components. SQL database workflows. As noted in Section 5.5, defining realistic workflows is critical to the success of our fingerprinting approach. Although SQL allows for a wide range of query combinations, only a subset meaningfully impacts system-level behavior. Functions like MAX(), MIN(), or clauses such as JOIN, WHERE, and ORDER BY act on data after it has been loaded and thus have negligible influence on syscall traces. Similarly, some statements (e.g., GRANT, REVOKE, LOCK) are unsupported by our selected databases, while others (e.g., BEGIN TRANSACTION, COMMIT, ROLLBACK) are uncommon in simple embedded database scenarios and contribute little to no syscall diversity. We therefore defined a core set of SQL statements likely to be used in real-world Wasm applications and with clear syscall 73 Petclinic. [Online]. Available: https://github.com/spring-projects/spring-petclinic. [Accessed: Jul. 21, 2025]. 74 JPetstore. [Online]. Available: https://github.com/making/spring-jpetstore. [Accessed: Jul. 21, 2025]. 75 Tweepee. [Online]. Available: https://github.com/coleifer/peewee/tree/master/examples/twitter. [Accessed: Jul. 21, 2025]. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 39 - August 31, 2025 relevance: CREATE TABLE, CREATE VIEW, DROP VIEW, SELECT, INSERT, UPDATE, and DELETE. These directly trigger I/O operations, file creation, or memory management, making them suitable for fingerprinting. To execute these workflows meaningfully, we populated the databases using the TPC-H benchmark, which offers a realistic schema and workload model. Its dbgen tool generates eight interrelated tables representing a business data warehouse, with the data size controlled via a scale factor (e.g., 1 = 1 GB). The qgen tool creates SQL queries from 22 templates simulating realistic business operations, with randomised parameters like dates or regions. TPC-H contributes 21 usable SELECT queries (one excluded due to SQLite incompatibility)– one of which including also CREATE VIEW and DROP VIEW statements– and eight CREATE TABLE statements defined in the dss.ddl schema file. To complete coverage of our core statement set, we generated eight custom queries each for CREATE VIEW, DROP VIEW, INSERT, UPDATE, and DELETE using a Large Language Model (LLM), taking advantage of TPC-H’s well-defined schema. This approach allows for easy future expansion. We created three batches of 69 workflows—each with the same structure but different parameters—to reflect runtime variability. We used qgen to vary SELECT queries, and an LLM for consistent variations of INSERT and UPDATE. This yielded 207 total workflows, executed across all database engines. Minor syntax adjustments were made for DuckDB to accommodate dialect differences, such as date arithmetic (date '1995-10-01' + interval '3' MONTH in SQLite vs. date('1995-10-01', '3 months') in DuckDB). Obfuscation vs TEE scenarios. Due to toolchain limitations, we evaluated a subset of obfuscation configurations. For SQLite and LibSQL, we applied Name, Memory, Alias, and FlattenCollatz techniques at -O0 optimisation; for DuckDB, we used Name, Memory, and Alias at -O2. Importantly, obfuscation had no impact on syscall behaviour: traces from obfuscated and non-obfuscated modules were identical under standard WAMR. Similarly, TEE execution introduced only minor and predictable differences (e.g., more limited use of getrandom and rt_sigprocmask). These findings indicate that syscall-level behavior is robust to both protection techniques. 5.6.1 A first look at the system call traces The goal of this experiment is to assess whether different embedded SQL database engines, when compiled to Wasm, exhibit distinguishable patterns in their system call traces. Additionally, we investigate whether such traces remain reliable under code obfuscation and TEE scenarios, which are commonly used to protect Wasm applications. System call collection. For each batch, we compiled the 69 SQL workflows into a C wrapper program for each of the three selected database engines (SQLite, LibSQL, DuckDB), resulting in nine Wasm modules (3 engines × 3 workflow batches). Each wrapper invokes SQL commands using the SQLite API, split into five execution stages: open, prepare, step, finalise, and close (Figure 9). The modules were executed inside a TEE-enabled Wasm runtime (iwasm within Intel SGX in simulation mode), and syscalls were collected using strace with -e 'trace=!mprotect' to suppress SGX-specific noise. To precisely measure syscall contributions per execution stage, we employed incremental stage execution. This involved capturing syscall traces after executing subsets of the API stages (e.g., open → open+prepare → open+prepare+step), then calculating trace differences to isolate the syscalls introduced at each stage. This process was applied to all 207 workflows across the three engines. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 40 - August 31, 2025 Figure 9. Example of C wrapping code for running SQL commands using SQLite API Intra-DB comparison. The goal of this experiment is to evaluate the internal consistency of system call traces generated by a single embedded SQL database engine when executing a variety of SQL commands with differing input parameters. This step is crucial to understanding whether the fingerprinting approach can reliably identify an engine despite normal operational variability. If syscall traces fluctuate widely within the same engine, the effectiveness of any engine-level classification model could be significantly compromised. To assess this, we analysed syscall traces for three database engines—SQLite, LibSQL, and DuckDB—by executing 69 distinct SQL workflows per engine. These workflows included a range of query types (e.g., SELECT, INSERT, UPDATE, DELETE) and were repeated with different input parameters to capture natural execution variability. Each SQL command was issued through a standardised SQLite API and executed inside a controlled TEE-enabled Wasm environment, with system-level traces collected using strace. The results show that syscall traces are largely consistent within each database engine. Trace variability was confined primarily to the step stage of execution—the phase responsible for actually running the SQL command. This is expected, as different SQL statements naturally invoke different execution paths. Still, even in the step stage, the variations were relatively minor. Read operations like SELECT queries produced short, uniform sequences of read syscalls. Write operations (INSERT, UPDATE, DELETE) exhibited more complexity due to interactions with journal and WAL files, but these differences remained within predictable bounds. The most prominent source of variation arose from I/O-related syscalls. The write() syscall used in write statements appears with slight changes in frequency and ordering depending on the command. We observed similar variability when executing the same workflow with different parameters, likely due to non-deterministic factors such as the volume of data, table structure, ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 41 - August 31, 2025 or database file size. Importantly, these fluctuations do not reflect characteristics unique to the database engine and are therefore treated as noise from a fingerprinting standpoint. To minimise the impact of such noise in our analysis, we retained only one representative batch of 69 workflows per engine for the remainder of the evaluation, yielding a final dataset of 207 workflows (3 engines × 69 workflows). Take-home message: Despite minor variations during execution, all engines produced stable and consistent syscall traces overall. This confirms that engine-specific fingerprinting remains viable and that the natural intra-engine noise is unlikely to undermine model accuracy. Inter-DB comparison. This experiment investigates whether different embedded SQL database engines exhibit distinctive system call patterns that could enable their identification through behavioral fingerprinting. While the intra-engine analysis focused on internal consistency, here we aim to determine whether differences across engines are significant enough to be reliably detected by an adversary. To this end, we compared the syscall traces produced by SQLite, LibSQL, and DuckDB across the five execution stages (open, prepare, step, finalise, and close) of the same SQL workflows. While the close stage was largely uniform across all engines, notable variations appeared in nearly every other phase—driven by differences in syscall types, ordering, input arguments, and return values. The three engines show syscall ordering differences mostly when handling disk files such as database files (.db), journal files or Write-Ahead-Log (WAL) files. Also the read/write operations to the database file present some differences. In fact, DuckDB tends to write a larger amount of information inside the database file and this leads to using a notably greater number of write calls. Variability also comes from input parameters and return values of syscalls. For instance, LibSQLconsistently used the O_NOFOLLOW flag when opening database-related files and showed corresponding values in fcntl() return flags—both absent in SQLite and DuckDB. It is worth mentioning that intra-DB variability lowers when enabling the IPFS feature. In fact, IPFS writes to files in chunks in a more concentrated way, hiding part of the original variability. Moreover, DuckDB originally uses positioned vectorized pwritev and preadv syscalls with significantly larger I/O buffer sizes, whereas SQLite and LibSQL rely on lseek + writev or lseek + readv pairs with smaller sizes. This source of difference is hidden by the mapping from filesystem syscalls to IPFS API, resulting in a uniformation of buffer sizes and I/O syscalls: irregardless of the engine, for read statements the database file is read from disk and placed in the enclave memory using mmap in the open stage, whereas for write statements use the write syscall in the step stage. IPFS increases the difficulty of the attack, although it does not completely eliminate the risk of fingerprinting as we will show in the rest of this section. Take-home message: All three engines exhibit distinctive syscall-level behaviors, especially in how they handle file I/O and journaling. These differences provide a strong basis for reliable engine fingerprinting, even in scenarios where engines share a common codebase (e.g., SQLite vs. LibSQL) and where I/O syscalls are uniformed. 5.6.2 Identifying target objects deployed in a standalone manner As previously introduced, victim applications are assumed to include an embedded SQL database engine (the target object) alongside custom logic. In this section, we investigate whether such engines can be reliably identified based solely on their system call patterns, independent of any surrounding application code. This reflects a realistic adversarial setting in which attackers attempt to fingerprint reused components across Wasm applications. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 48 - August 31, 2025 system. Experience has shown that even when patches are available, outdated libraries often remain in use for extended periods, giving adversaries ample opportunity to exploit these weaknesses. Our analysis revealed that a significant proportion of serverless components include vulnerabilities in their libraries, with many classified as high or critical severity. To address this risk, developers incorporating serverless components from public repositories should perform thorough vulnerability scans before deployment, ideally using more than one scanning tool to compensate for differences in detection capabilities and to validate results. After obtaining a detailed list of vulnerabilities for a given component, remediation should prioritise those with critical or high severity ratings. Many scanning tools indicate whether a fix exists in a newer release, enabling faster patching. If updating is not feasible due to compatibility constraints, developers should evaluate alternative libraries, apply temporary mitigations where available, or isolate the component to limit the potential impact of the vulnerability being exploited. It is also very important to treat vulnerability management as a continuous process rather than a one-time task. New flaws are regularly discovered in libraries previously considered secure, making it essential to integrate automated dependency scanning into the CI/CD pipeline. This continuous monitoring, combined with version locking and provenance verification through checksums, signed packages or software bills of materials, can significantly reduce the likelihood of insecure dependencies being introduced into real-world environments. 2Malicious serverless components: Many public repositories allow anyone to upload serverless components or IaC templates after only a simple registration process, creating opportunities for adversaries to distribute malicious code. In the case of serverless components, most platforms also accept pre-packaged compressed archives containing both code and dependencies. While this format is convenient for deployment, it can be exploited to conceal malicious functionality, making detection by traditional security tools significantly more challenging. As there are already documented cases of malicious components in public repositories, within ELASTIC we focused on exploring a more advanced attack scenario in which we exploit the ability to upload components in compressed form to evade detection. Our findings show that antivirus tools often fail to identify malicious content while it remains compressed, indicating that this technique could become increasingly attractive to adversaries. To mitigate this risk, all components from public repositories — regardless of format — should be thoroughly scanned with antivirus engines before use. Aggregated scanning services such as VirusTotal are particularly valuable, as they consolidate results from multiple engines; many organisations consider a component suspicious if it is flagged by three to five engines. However, automated scanning alone is insufficient. Developers should also manually inspect code and dependencies — especially for components from unverified publishers — and test components in an isolated, sandboxed environment to observe runtime behavior. Establishing a policy to only source components from trusted or verified publishers further reduces the likelihood of ingesting malicious components. Finally, our findings highlight the need for more advanced antivirus capabilities capable of detecting threats in compressed artifacts, as existing tools may fail to identify sophisticated archive-based attacks. 3Sensitive parameters in Docker run commands: Some public repositories, such as Docker Hub, allow contributors to provide execution instructions that specify how their components should be run. Adversaries can exploit this feature by embedding unsafe Docker run commands containing risky parameters. Users and developers who blindly follow these instructions, often due to a lack of security expertise, risk weakening container isolation and potentially compromising the host system. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 49 - August 31, 2025 Our analysis confirmed that several sensitive parameters previously reported in the literature remain actively used in public repositories. We extended this work by identifying three additional parameters that can expose serverless components to attack and observed multiple instances of their use in Docker Hub. Notable examples of sensitive parameters used in Docker run commands include -v <src>:<dest>, which mounts host directories into a container and can leak sensitive files; --privileged, which grants unrestricted access to host resources; and -- pid=host, which allows container processes to view and interact with all host processes, enabling reconnaissance or privilege escalation. Within ELASTIC, we also identified cases where credentials were hardcoded in commands or passed via environment variables, both of which introduce significant security risks. In one instance, the Docker daemon socket (/var/run/docker.sock) was mounted directly into a container—effectively granting an attacker full control over the host’s Docker environment. These findings demonstrate that sensitive parameters in Docker run commands remain a persistent and under-addressed security risk. As part of this work, we compiled a consolidated list of parameters that should be avoided entirely or, at the very least, not used with default values. To mitigate these risks, developers and users should carefully review all contributorsupplied Docker run commands before execution, paying close attention to the presence of parameters included in our list of known risky parameters. Hardcoded values, such as credentials or port numbers, should be replaced to prevent adversaries from exploiting this information to target infrastructure. 4Misconfigurations in IaC templates: Just as it is common to reuse serverless components, it is equally common to rely on IaC templates developed by others to accelerate serverless application development. Our research shows that many publicly available IaC templates contain security misconfigurations. This is particularly concerning because developers and users—who are typically not security experts—often adopt default configurations without modification. Common issues include overly permissive IAM roles, unrestricted network access, insecure default environment variables, and inadequate encryption settings. Such misconfigurations can significantly expand the attack surface by granting excessive privileges or exposing resources to potential attackers. It is therefore essential that developers and users avoid trusting default configurations and instead conduct thorough security reviews and automated scans before incorporating IaC templates into their applications. To reduce this risk, developers should adopt a security-by-design approach when authoring or modifying IaC templates. All access permissions should follow the principle of least privilege, and default configurations provided by templates should be reviewed and hardened before use. Network security rules should restrict inbound and outbound access to only what is necessary, and sensitive resources should be protected with explicit access controls. Automated scanning tools, such as Trivy, can be used to detect common misconfigurations before deployment. Our work shows that IaC templates obtained from public repositories should be treated with the same scrutiny as application code, undergoing peer review, static analysis, and security testing to ensure they do not inadvertently introduce vulnerabilities into the environment. 5Typo-squatting attacks: In a typosquatting attack, adversaries exploit the tendency of users and developers to make small typing errors when retrieving components. They upload malicious components with names deliberately crafted to mimic popular ones, differing only by common misspellings, transposed characters, or subtle visual variations that are difficult to detect at a glance (e.g., replacing the letter “l” with the number “1”). Our analysis identified such naming collisions in multiple public repositories, including Docker Hub. This technique can be particularly effective in serverless environments, where developers often integrate components rapidly and applications may depend on a large number of distinct resources, ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 50 - August 31, 2025 increasing the likelihood of a typo going unnoticed. Once a typosquatted component is integrated, adversaries can execute malicious code during deployment or runtime, potentially compromising the application, its data, and the surrounding cloud environment. Mitigating typosquatting requires both developer vigilance and systematic safeguards. Developers should verify the exact names and publishers of components before installation, ideally using repository features that display publisher reputation, verification status, or digital signatures. Organisations can maintain an internal allowlist of approved components, repositories, or contributors and automatically flag or block dependencies that do not match trusted sources. Automated dependency management tools can detect unexpected changes in component naming, versioning, or source, while periodic manual reviews of dependency lists can help uncover suspicious additions. Long-term prevention also requires action from repository maintainers. This includes implementing stronger namespace protections, reserving names of popular components, detecting and rejecting uploads with highly similar names to existing packages, and providing clear warnings when a user attempts to download a component whose name closely resembles another. Repositories should also support mandatory digital signing for all published components, enabling consumers to verify authenticity. Take-away message: We advocate for a security model in which public serverless repository administrators are primarily responsible for securing the components they host, since developers themselves may be untrustworthy and capable of carrying out the attacks described above. Most importantly, transparency and accountability are essential. Repository administrators should clearly disclose their security practices, specifying the scanning methods and tools they use as well as the frequency of their security assessments. Until such transparency becomes the norm, developers and users should operate under the assumption that any component downloaded from a public repository could be compromised and should subject it to rigorous security checks before use. 6.2 System Call Obfuscation for TEE-Based Workloads Confidential computing has emerged to protect customers’ applications not only at rest and in transit, but also while in use. At its core are TEEs), which provide a secure memory compartment for storing data and executing arbitrary code on an untrusted server. TEEs significantly reduce the TCB and protect against attacks even from adversaries with root privileges on the server. In practice, TEEs allow customers to run their applications inside containers as usual, but without enabling cloud providers—or any compromised or malicious software on their servers—to tamper with or gain insight into those applications. Despite these guarantees, numerous attacks against TEEs have been discovered in recent years, with side-channel attacks proving especially prevalent. In Section 5, we introduced a new fingerprinting attack that exploits a previously unstudied side channel, undermining the TEE’s core promise that no entity should be able to infer information about the application executing within it. Our attack leverages system events invoked by confidential Wasm applications running inside a TEE to unintentionally leak sensitive information, such as the type of application being executed. When Wasm is executed inside a TEE, the TEE typically contains the runtime, meaning that WASI calls are not directly visible to an external adversary. However, the attacker can still observe the system events—such as system calls—issued by the Wasm runtime to the underlying host operating system kernel. These observable events can reveal behavioural patterns and application characteristics, even if the application code and data remain encrypted within the TEE. Mitigating this form of leakage requires a careful analysis of the communication between the Wasm runtime and the host OS kernel, identifying which aspects ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 51 - August 31, 2025 of these system interactions can serve as side-channel signals and designing obfuscation or noise-injection strategies to reduce their fidelity. From a defensive perspective, the goal is for all confidential Wasm applications to produce system call traces that are indistinguishable from one another. In theory, this could be achieved by either suppressing or delaying real system calls to reduce leakage, or by injecting artificial system calls to mask real behaviour. The first strategy is often impractical because it can break application functionality or introduce unacceptable latency. The second strategy—injecting fake system calls—offers a more practical path forward, but it must be implemented with care. Privacy protection depends on the quantity and quality of injected events: too few or poorly chosen calls will fail to hide sensitive patterns, while excessive injection will impose significant performance penalties. Logical consistency is also critical, as artificial system events must follow realistic execution patterns to avoid detection. For example, a close or read call should only follow a successful open, and memory operations such as mlock should be logically paired with munlock. These relationships can be systematically derived from syscall documentation, such as Linux man pages, to guide the generation of realistic noise. A more principled solution involves applying differential privacy to guide noise injection, enabling defenders to introduce only the minimal amount of obfuscation necessary to achieve measurable privacy guarantees. This approach allows explicit trade-offs between stronger privacy with higher computational overhead and lighter-weight defences that provide reduced but still quantifiable protection. However, a differential-privacy–based defence assumes that defenders (i.e., developers) have access to representative syscall distributions from a broad range of applications in the same cloud environment. In practice, individual developers often lack visibility into such workload profiles, making it difficult to tune privacy parameters effectively. One possible way to address this limitation is through a crowdsourced approach, in which developers voluntarily share anonymised system call statistics for their applications. Aggregating this data across participants could yield realistic reference distributions for different workload categories, enabling all developers to calibrate their obfuscation strategies more effectively and, ultimately, help each other reduce leakage across the ecosystem. The defence could be implemented as a transparent shim layer within the TEE, functioning as an extension of the Wasm runtime. This shim would intercept system calls before they exit the enclave, injecting artificial events in accordance with the chosen privacy policy. As a result, the system call sequence observed by the host would be obfuscated and stripped of meaningful patterns that could reveal the nature of the workload running inside. This method requires no changes to application code or the runtime itself, is compatible with existing Wasm environments, and can be tuned to achieve the desired balance between privacy and performance based on operational requirements. 6.3 Securing Function-to-Function and Function-to-Service Communication While securing the interactions between confidential Wasm applications and the underlying host is essential, equally important is protecting horizontal interactions—that is, those between serverless functions and between serverless functions and external services. These communications often form the backbone of modern microservice architectures and are particularly critical in FaaS environments where individual functions frequently depend on external APIs, databases, message queues, or other functions for data and control flow. In serverless architectures based on WebAssembly, these interactions are typically implemented over standard protocols (e.g., HTTP, gRPC, or MQTT) or through service meshes ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 52 - August 31, 2025 and messaging middleware. However, these pathways can expose sensitive data and metadata, especially in multi-tenant or adversarial cloud-edge environments. To mitigate these risks and enhance confidentiality, integrity and policy enforcement during function-to-function or function-to-service communication, ELASTIC proposes the following security mechanisms: ● End-to-end encrypted communication channels: All horizontal communication between functions should occur over mutually authenticated and encrypted channels. This can be achieved using TLS with attested keys, enabling encryption even when one or both functions are running in TEEs. Furthermore, key exchange protocols should support remote attestation, binding session keys to enclave identities and ensuring that cryptographic material is only released to attested endpoints. ● Policy-aware communication mediation: ELASTIC advocates the integration of policy enforcement points (PEPs) at the communication layer. These PEPs validate whether a function is allowed to invoke a given service or access particular data, based on pre-defined policies expressed through a high-level policy language (e.g., Rego 76 or Zanzibar-style 77 Access Control Lists (ACLs)). This ensures that even if a function is compromised, its ability to interact with other components is tightly scoped and auditable. ● Capability-based function discovery and routing: To minimise the attack surface associated with traditional service discovery, ELASTIC introduces capability-based routing. Instead of exposing public service names or endpoints, functions are granted cryptographically bound capability tokens (or signed invocation tickets) that authorise specific calls. These tokens act as lightweight, revocable keys that embed both the permissions and contextual constraints of an invocation. A function can only invoke another if it possesses the appropriate capability, ensuring that discovery and access are restricted to authorised interactions. Beyond limiting exposure, this approach also produces an auditable trail of service invocations, enabling stronger accountability in multi-tenant or adversarial environments. ● Shared confidential state and secure data flow: For workflows that span multiple functions, it is often necessary to exchange data between invocations. ELASTIC introduces support for confidential shared state via ephemeral, attested, in-memory storage accessible only within the trusted domain (e.g., enclave-backed in-memory KV stores). This allows sensitive data to flow between functions without ever leaving the trusted execution boundary, reducing leakage risk even in the presence of powerful adversaries. ● Side-channel minimisation in function invocation patterns: Just as vertical interactions are susceptible to side-channel analysis, so too are function call graphs and invocation timing patterns. ELASTIC explores obfuscation strategies at the orchestration layer—such as injecting synthetic traffic, delaying non-critical invocations, or padding execution windows—to reduce the observability of control flow patterns across the function graph. Together, these mechanisms form the basis of a horizontally secure FaaS substrate within the ELASTIC architecture. By treating each serverless function not as an isolated unit but as a participant in a larger, privacy-aware distributed system, ELASTIC enables secure and verifiable composition of services—crucial for 6G-era workloads where confidentiality, integrity, and trust must span heterogeneous infrastructure from edge to cloud. 76 Rego - https://www.openpolicyagent.org/docs/policy-language [Accessed: Jul. 21, 2025]. 77 Zanzibar - https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/ [Accessed: Jul. 21, 2025]. ELASTIC D2.2 HORIZON-JU-SNS-2023/№ 101139067 ELASTIC - 53 - August 31, 2025 7 Conclusions This deliverable presents advances in secure, privacy‑aware, and architecture‑agnostic execution of Wasm‑based serverless workloads. It provides two key contributions: a large‑scale analysis of public serverless repositories, revealing systemic risks such as outdated dependencies, insecure configurations, and malicious artifacts; and a novel fingerprinting attack that infers sensitive details of confidential Wasm applications running in TEEs from system call traces. To mitigate these risks, the deliverable proposes stronger repository governance, syscall obfuscation techniques, and mechanisms to secure inter‑function communications using encryption, policy enforcement, and capability‑based routing. The results form the basis of a security and privacy toolbox for ELASTIC, offering concrete recommendations to strengthen key architecture components.