Serverless Security: Risks and Controls

Serverless computing eliminates server provisioning from the developer workflow but introduces a distinct set of security risks that differ fundamentally from traditional infrastructure and even container-based deployments. This page covers the definition and scope of serverless security, the mechanisms by which controls are applied, the scenarios where exposures most commonly arise, and the decision boundaries that govern when serverless security tooling or architectural changes are warranted. The subject is operationally significant because the event-driven, ephemeral nature of serverless functions breaks assumptions built into conventional security monitoring, patching, and access control models.

Definition and scope

Serverless security refers to the set of policies, controls, and architectural practices that protect function-as-a-service (FaaS) workloads and their dependencies from exploitation, unauthorized access, data exfiltration, and compliance violations. The primary FaaS platforms in the US market are AWS Lambda, Google Cloud Functions, and Azure Functions — each abstracting the underlying compute infrastructure while exposing execution runtimes, event triggers, and identity bindings as the principal attack surface.

Scope extends beyond the function code itself. It includes the event sources that invoke functions (API gateways, message queues, object storage events), the IAM roles and execution permissions attached to each function, third-party dependencies bundled in deployment packages, environment variables used for secrets injection, and the logging pipelines that produce auditable records. The shared responsibility model applies directly: cloud providers secure the underlying runtime infrastructure, while operators retain responsibility for function code, permissions, and configuration.

Regulatory framing is established by NIST SP 800-53 Rev 5, which covers access control (AC), audit and accountability (AU), and system and communications protection (SC) controls applicable to serverless architectures. Organizations subject to FedRAMP authorization must demonstrate compliance with these controls even when the compute layer is fully managed — as documented in the FedRAMP Authorization framework.

How it works

Serverless security operates across three distinct phases of the function lifecycle:

1. Build phase — Static analysis of function code and dependency manifests identifies known vulnerabilities (CVEs) before deployment. Dependency scanning tools cross-reference packages against the National Vulnerability Database (NVD), maintained by NIST at nvd.nist.gov. Infrastructure-as-code templates are reviewed for misconfigurations, including overly permissive IAM policies and unencrypted environment variable storage.

2. Deploy phase — Deployment pipelines enforce signing and integrity checks on function artifacts. IAM roles are scoped using least-privilege principles — a function that reads from one S3 bucket should hold exactly that permission and no broader s3:* grant. Secrets are injected via dedicated secrets management services rather than plaintext environment variables. This integrates directly with DevSecOps practices that treat policy-as-code as a deployment gate.

3. Runtime phase — Because serverless functions spin up in milliseconds and terminate after execution, traditional agent-based endpoint security cannot operate. Runtime application self-protection (RASP) and behavioral monitoring tools instrument the function execution environment directly. Cloud provider logging services (AWS CloudTrail, Azure Monitor, Google Cloud Audit Logs) capture invocation metadata, which feeds into cloud SIEM and logging pipelines for anomaly detection.

The distinction from container security is operationally significant: containers maintain persistent processes where agent injection is feasible, while serverless functions are stateless and ephemeral, requiring control mechanisms that are embedded in the deployment artifact or enforced at the platform permission layer rather than at the process level. For a comparison of container-layer controls, see Container Security Best Practices.

Common scenarios

Four exposure patterns account for the majority of serverless security incidents:

Excessive IAM permissions — Functions granted administrator-level or wildcard service permissions create lateral movement paths. An attacker who achieves code execution inside a function can call AWS APIs with the function's attached role. The OWASP Serverless Top 10, published by the Open Web Application Security Project, identifies broken function-level authorization as the leading risk category.

Dependency chain compromise — Serverless deployment packages typically bundle third-party libraries. A single compromised npm or PyPI package in a dependency tree can introduce backdoors or exfiltrate environment variables containing database credentials or API keys. This intersects directly with supply chain security risk management.

Insecure event source configuration — Functions triggered by unauthenticated API Gateway endpoints, publicly accessible S3 buckets, or misconfigured SNS topics accept arbitrary input. Injection attacks — including SQL injection and command injection — remain viable when input validation is absent at the function entry point. Cloud API security controls address gateway-layer authentication and input schema enforcement.

Secrets in plaintext — Environment variables in FaaS platforms are visible to any principal with lambda:GetFunctionConfiguration (AWS) or equivalent permissions. Hard-coded secrets in function code are additionally exposed through source control systems and deployment logs.

Decision boundaries

Determining when and how to apply serverless security controls depends on three boundary conditions:

Threat surface classification — Functions handling personally identifiable information (PII), payment card data, or protected health information (PHI) fall under HIPAA (45 CFR Part 164), PCI DSS (PCI Security Standards Council), or FTC regulations and require hardened IAM scoping, audit logging retention, and encryption in transit and at rest — regardless of function execution duration.

Invocation volume and blast radius — A function invoked fewer than 100 times per day and accessing no sensitive data warrants different control depth than a high-frequency payment processing function. Blast radius analysis — mapping which downstream services a compromised function can reach — drives the IAM scoping decision more than invocation frequency alone.

Ownership model — Multi-tenant serverless deployments (where a single function serves requests from multiple organizational clients) require tenant isolation controls that single-tenant deployments do not. Cloud workload protection platforms provide runtime isolation enforcement for these architectures. Organizations evaluating cloud security posture management tools should confirm whether the tool's serverless coverage includes function configuration drift detection, not just infrastructure-layer misconfigurations.

References

• NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations
• NIST National Vulnerability Database (NVD)
• OWASP Serverless Top 10
• FedRAMP Program — General Services Administration
• 45 CFR Part 164 — HIPAA Security Rule (eCFR)
• PCI Security Standards Council — PCI DSS
• AWS Lambda Security Documentation
• Google Cloud Functions Security Overview