The Risk of Exposed Cloud Functions and How to Harden

Mandiant assessments highlight frequent exposure of serverless applications lacking authentication, often due to business needs. These deployments run custom code with third-party packages, making them vulnerable to application-level attacks. Successful exploitation can grant attackers control over container instances, serving as a foothold for broader cloud environment compromise. The guidance focuses on securing Google Cloud Run services and functions that must remain publicly accessible, though principles apply to all public serverless deployments.

Serverless applications, or Function-as-a-Service (FaaS), enable code deployment as microservices without managing underlying infrastructure. They support automatic scaling and instant deployment, reducing operational overhead. Major applications, including e-commerce, media, and AI workflows, rely on serverless functions. The rapid adoption of generative AI has further driven serverless architecture use, increasing the urgency for enterprise security teams to address vulnerabilities in these environments.

Publicly exposed serverless workloads can serve as initial access points for threat actors. Vulnerabilities may exist in code, imported packages, or runtime environments. Attackers often escalate privileges or move laterally after exploitation. Common techniques include extracting secrets from application code, reviewing logic for further attack vectors, and exfiltrating service account tokens via Remote Code Execution (RCE). Compromised secrets or accounts enable pivoting to adjacent systems, potentially leading to total environment takeover if hardening strategies are absent.

Simplified scenarios demonstrate how serverless functions can be compromised and how attackers pivot post-exploitation. In one example, a Python/Flask function accepts user input to open files without validation, enabling Local File Inclusion (LFI). Attackers exploit this to retrieve sensitive files such as requirements.txt, package.json, or environment files containing secrets. Best practices include avoiding hardcoded secrets and using dedicated solutions like Secret Manager. Another scenario shows unsanitized user input enabling arbitrary command execution, allowing attackers to retrieve service account bearer tokens from the GCP metadata service.