# Serverless Security
Serverless security is the practice of identifying, reducing, and managing the vulnerabilities specific to function-as-a-service (FaaS) compute platforms. In serverless architectures, developers deploy discrete functions that execute in response to events: an HTTP request, an S3 object upload, a message arriving on an SQS queue, a scheduled timer. The cloud provider manages the underlying infrastructure, runtime environment, and scaling. The developer owns only the function code and its configuration.
The "serverless" label is accurate from the developer's perspective: there are no servers to provision, patch, or manage. From a security perspective, the phrase obscures what actually changed. The operating system patching burden moved to the provider. The network perimeter as traditionally defined mostly disappeared. In their place emerged a new category of risk organized around function execution roles, event input validation, dependency management, and trust relationships between functions.
This matters because organizations sometimes deploy serverless functions assuming the provider's management of infrastructure eliminates security responsibility. It does not. The AWS shared responsibility model is explicit: AWS manages security of the infrastructure; the customer is responsible for security of what runs on it. A Lambda function with an over-privileged IAM execution role, processing untrusted event input without validation, loading vulnerable third-party packages from an insecure layer, and logging secrets to CloudWatch Logs is vulnerable regardless of how well AWS manages the physical servers underneath it.
Within CDA's PDM, serverless security falls squarely in VSD (Vulnerability and Surface Defense), the oceans layer. The core question of VSD is always the same: what is the exposed surface, and can it be reduced? Serverless architectures create new surfaces (event sources, execution roles, runtime dependencies, environment variables) that require the Continuous Surface Reduction (CSR) methodology to systematically identify and eliminate.
Traditional application security focuses on: network layer (open ports, unpatched services), OS layer (kernel vulnerabilities, unpatched packages), application layer (OWASP Top 10 injection classes), and infrastructure layer (misconfigured servers, default credentials). Serverless eliminates the first two in tenant-managed form. What it introduces in their place:
Function code injection via untrusted event sources. A Lambda function receives its input as a JSON event payload. If that payload originates from user-controlled sources (API Gateway receiving HTTP requests, S3 object names from user uploads, SQS messages from external senders) and the function passes event values to shell commands, SQL queries, OS calls, or template rendering without validation, injection is possible. The injection vector is not the network: it is the event structure the function trusts. Event injection is functionally equivalent to SQL injection or OS command injection but arrives through the serverless trigger mechanism rather than a traditional input field.
Over-privileged IAM execution roles. Every Lambda function runs with an IAM execution role that grants it permissions to interact with other AWS services. If that role has s3: on all buckets, dynamodb: on all tables, or (worst case) AdministratorAccess, a compromised function becomes a pivot point into the entire AWS account. Over-privilege in execution roles is the single most common high-severity misconfiguration in serverless environments. The root cause is developer convenience: giving functions broad permissions is faster than scoping them to the exact resources and actions the function actually requires.
Dependency vulnerabilities in Lambda layers and function packages. Serverless functions typically bundle third-party packages (npm packages in Node.js, pip packages in Python, Maven/Gradle packages in Java). Lambda layers allow sharing dependencies across functions. If a package with a known CVE (log4j, lodash prototype pollution, requests library vulnerabilities) is present in a function's dependency tree, the function is vulnerable. Unlike container images or server deployments, serverless dependency packages may not be continuously scanned after initial deployment: the function can sit in production for 18 months before someone notices the dependency lock file contains a critical vulnerability.
Insecure deserialization of event payloads. Functions that deserialize complex objects from event inputs (pickle in Python, Java serialization) using untrusted data are subject to the same deserialization vulnerabilities that affect traditional applications. In the serverless context, the deserialization happens inside the function execution environment, with the function's IAM role and network access available to any deserialization gadget chain that succeeds.
Secrets in environment variables. AWS Lambda allows environment variables to be set at function configuration time. Developers commonly store database connection strings, API keys, and third-party service credentials as environment variables because it is convenient. The problem: environment variables are visible in the Lambda console to anyone with lambda:GetFunctionConfiguration permissions, are included in some error dumps and debug logs, and are not encrypted at rest by default in some configurations. Secrets stored in environment variables provide a lower security guarantee than secrets stored in AWS Secrets Manager or Parameter Store with KMS encryption.
Function-to-function trust abuse. Serverless architectures frequently have functions invoking other functions: an API handler invokes a processing function, which invokes a notification function. If trust between functions is implicit (any Lambda in the account can invoke any other Lambda), a compromised function can invoke downstream functions with arbitrary payloads, bypassing the validation that upstream callers would normally apply. Resource-based policies on Lambda functions should restrict invocation to specific, named caller principals, not the entire account.
CDA's Continuous Surface Reduction methodology asks: every exposed surface is a surface to eliminate. Applied to serverless:
Least-privilege execution roles. Each function receives an IAM role scoped to exactly the resources and actions it needs. A function that reads one specific DynamoDB table and writes to one specific S3 prefix gets a policy with dynamodb:GetItem on arn:aws:dynamodb:region:account:table/SpecificTableName and s3:PutObject on arn:aws:s3:::bucket-name/prefix/*. Nothing more. AWS IAM Access Analyzer's policy generation feature analyzes CloudTrail data to identify what permissions a function actually used over a trailing period and can suggest minimum-required policies.
Input validation on all event sources. Every event source a function processes must be treated as potentially hostile. API Gateway events validate the HTTP layer but do not validate business-logic fields in the request body: the function must validate. S3 event notifications contain object keys controlled by whoever uploaded the object: the function must sanitize them before using them in paths or queries. SQS messages from external queues may contain injected content: validate before processing. Input validation libraries appropriate to the language (Joi for Node.js, Pydantic for Python, Hibernate Validator for Java) enforce schema constraints at function entry.
Dependency scanning integrated into the deployment pipeline. Snyk, Dependabot, OWASP Dependency Check, and AWS Inspector (which now scans Lambda function packages for vulnerable dependencies) all integrate into CI/CD pipelines to fail builds that include dependencies with CVEs above a defined severity threshold. The critical behavior is continuous scanning, not one-time: a dependency that is clean at deploy time may acquire a CVE three months later. Scheduled dependency scans against production function packages catch vulnerabilities that post-date initial deployment.
Secrets management via AWS Secrets Manager or Parameter Store. Functions retrieve secrets at runtime by calling the Secrets Manager API, not by reading environment variables. The function's IAM role grants access to specific secret ARNs only. Secrets are versioned, audited (Secrets Manager integrates with CloudTrail), and can be rotated automatically without redeploying the function. The tradeoff is a small latency cost for the API call: this is negligible for most functions and is the correct tradeoff.
Runtime protection. Tools like Aqua Security's serverless runtime protection and Datadog's Lambda monitoring instrument function execution to detect anomalous behavior at runtime: unexpected network connections, unusual file system access patterns, memory spikes consistent with memory scraping, and execution of unexpected binaries. Runtime protection is particularly valuable in serverless because traditional host-based agents (EDR) cannot run on the ephemeral function execution environment. The instrumentation is typically implemented as a Lambda layer that wraps the function handler.
Function code review for serverless-specific issues. Standard SAST (Static Application Security Testing) tools catch many serverless vulnerabilities, but specialized serverless security scanners (Checkov, cfn-nag for CloudFormation/SAM templates, Semgrep rules for serverless patterns) additionally check for infrastructure misconfigurations: functions with wildcard IAM permissions, functions with no resource-based policy restricting invocation, environment variable values that appear to be secrets (based on key names like API_KEY, DB_PASSWORD), and functions with no timeout configured (a function with no timeout can run indefinitely, providing attackers with persistent compute if they can trigger it).
Serverless adoption is accelerating. AWS Lambda processes trillions of function invocations per year across millions of customer functions. Azure Functions and Google Cloud Functions have similar scale. The majority of new cloud-native application development includes a serverless component. The attack surface represented by these functions is growing proportionally.
The challenge with serverless security is that the vulnerabilities are non-obvious to developers who came from traditional server-based backgrounds. A developer who understands SQL injection and XSS may not recognize that processing an S3 object key in a Lambda function without sanitization is an injection risk, or that a broad IAM execution role turns every function vulnerability into an account-wide blast radius.
Several publicly documented incidents illustrate the real-world risk. Misconfigured Lambda execution roles with broad IAM permissions have been used to pivot from an initial function compromise to full AWS account takeover, including exfiltration of secrets from other services, creation of new IAM users for persistence, and manipulation of other Lambda functions. Dependency vulnerabilities in Lambda packages have been exploited to achieve remote code execution within function execution environments, providing attackers access to the function's role credentials through the IMDS-equivalent endpoint available to Lambda functions.
The financial exposure in a serverless account compromise can be substantial. Lambda functions with overpowered execution roles may have access to production databases, payment data, PII repositories, and other regulated data stores. An attacker who compromises a single vulnerable function and pivots through its role may access data across the entire AWS account, triggering breach notification obligations and regulatory penalties regardless of how small the initial foothold was.
Lambda functions receive temporary IAM credentials for their execution role via the Lambda runtime environment. These credentials are available to code running inside the function through the standard AWS SDK credential chain or by directly querying the Lambda credentials endpoint (a metadata endpoint similar to EC2 IMDS). An attacker who achieves code execution inside a Lambda function can exfiltrate these temporary credentials and use them outside the Lambda environment (from their own infrastructure) for as long as the credentials remain valid (up to 12 hours for role-assumed credentials).
This is why over-privileged execution roles are treated as a critical misconfiguration, not a medium-severity finding. Execution credential theft converts local function code execution into persistent, authenticated AWS API access from attacker-controlled infrastructure.
Lambda functions have "cold starts" when a new execution environment is initialized after a period of inactivity. The initialization code (code outside the handler function, in the module initialization scope) runs during cold start. Secrets fetched during cold start (from Secrets Manager or Parameter Store) may be cached in the execution context and reused across multiple invocations, which is desirable for performance. The security consideration is ensuring that cached secrets are not accessible across concurrent execution environments and that cached credentials are refreshed before expiration.
Most Lambda deployments use AWS SAM, CloudFormation, Serverless Framework, or Terraform to define function infrastructure as code. Security misconfigurations in IAM roles, event source mappings, and function policies are captured in these templates: scanning templates for security issues (using Checkov, cfn-nag, or tfsec) at code review time catches misconfigurations before they reach production, at a fraction of the cost of remediating a deployed misconfiguration.
Serverless represents a surface transformation, not a surface elimination, and CSR (Continuous Surface Reduction) applies to transformed surfaces with the same rigor as to traditional ones. CDA's VSD domain work in this context means mapping the new attack surface that serverless creates (event sources, execution roles, dependency chains, environment variables) and systematically reducing each vector.
The most actionable CSR application to serverless is IAM discipline. CDA assesses execution role policies as part of any cloud security posture engagement, and over-privileged Lambda roles are among the most consistently found misconfigurations across client environments regardless of organization size. The remediation is tractable: AWS IAM Access Analyzer can identify minimum required permissions automatically from CloudTrail data, making role scoping an automatable task rather than a manual policy-writing exercise.
Dependency risk in serverless functions connects VSD to the broader software supply chain threat landscape. A function pulling packages from public registries at build time, without pinned versions and vulnerability scanning, is an uncontrolled supply chain input. CDA's surface reduction work includes establishing approved package registries, enforcing dependency pinning in CI/CD, and integrating continuous dependency scanning into deployment pipelines.
The intersection of VSD and IAT (Identity Access and Trust) is particularly sharp in serverless: the function's execution role is an identity. Every overpowered role is a violation of Zero Possession Architecture principles, where machine identities should possess only the minimum permissions required to perform their function. Serverless security done correctly is ZPA applied to compute identity, not just human identity.
Amazon Web Services. Lambda Security Best Practices. AWS Documentation. https://docs.aws.amazon.com/lambda/latest/dg/lambda-security.html
Amazon Web Services. IAM Access Analyzer Policy Generation. https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html
OWASP. Serverless Top 10. OWASP Foundation. https://owasp.org/www-project-serverless-top-10/
Snyk. State of Open Source Security 2023. https://snyk.io/reports/open-source-security/
Bridgecrew / Checkov. Infrastructure as Code Static Analysis. https://www.checkov.io/
Aqua Security. Serverless Security. https://www.aquasec.com/cloud-native-academy/serverless-security/
CDA, LLC. Planetary Defense Model Master Reference. CDA Canon, 2026.