Serverless Security: The Realistic Guide

What Serverless Actually Removes (and Doesn't)

Serverless removes some real problems:

OS patching (mostly).
Long-lived host compromise — short-lived containers limit dwell time.
SSH/RDP attack surface.
Capacity-based DoS — auto-scaling absorbs many volumetric attacks.

But it adds others:

Function permissions sprawl — hundreds of functions, each with its own role, add up to a permissions blast radius bigger than a few VMs.
Cold-start telemetry gaps — runtime detection tools need to attach in milliseconds.
Dependency depth — function packages with 200 npm dependencies inherit every CVE in the tree.
Event-source confusion — a Lambda triggered by SQS, EventBridge, S3, and API Gateway has four input-validation surfaces, not one.

One Role Per Function. Always.

The cardinal serverless rule: each function gets its own IAM role with only the permissions it needs. Shared roles are how blast radius compounds.

Use iam:PassRole conditions to prevent privilege-escalation paths.
Periodically run IAM Access Analyzer's unused-access scan against function roles — they accumulate cruft fast.
For Cloud Run / Cloud Functions, the same rule applies to GCP service accounts.

Input Validation Across Every Event Source

Functions don't have a single ingress point — they have one per event source. Each one is an attack surface:

API Gateway — request validation, WAF, throttling.
SQS / SNS — message-level signature verification, schema validation, dead-letter handling for malformed messages.
S3 events — file-type validation, size limits, antivirus scanning before downstream processing.
EventBridge / Pub/Sub — schema registry validation.

Secrets and Configuration

Environment variables in Lambda are convenient and have caused real breaches. The safer pattern:

AWS Secrets Manager or Parameter Store — fetch at cold start, cache in memory for the function lifetime.
Lambda extensions for secrets caching reduce cold-start latency.
GCP Secret Manager with --set-secrets on Cloud Functions / Cloud Run.
Avoid long-lived API keys. Use OIDC + workload identity / IRSA wherever possible to talk to other clouds and SaaS.

What Serverless Actually Removes (and Doesn't)

Serverless removes some real problems:

OS patching (mostly).
Long-lived host compromise — short-lived containers limit dwell time.
SSH/RDP attack surface.
Capacity-based DoS — auto-scaling absorbs many volumetric attacks.

But it adds others:

Function permissions sprawl — hundreds of functions, each with its own role, add up to a permissions blast radius bigger than a few VMs.
Cold-start telemetry gaps — runtime detection tools need to attach in milliseconds.
Dependency depth — function packages with 200 npm dependencies inherit every CVE in the tree.
Event-source confusion — a Lambda triggered by SQS, EventBridge, S3, and API Gateway has four input-validation surfaces, not one.

One Role Per Function. Always.

The cardinal serverless rule: each function gets its own IAM role with only the permissions it needs. Shared roles are how blast radius compounds.

Use iam:PassRole conditions to prevent privilege-escalation paths.
Periodically run IAM Access Analyzer's unused-access scan against function roles — they accumulate cruft fast.
For Cloud Run / Cloud Functions, the same rule applies to GCP service accounts.

Input Validation Across Every Event Source

Functions don't have a single ingress point — they have one per event source. Each one is an attack surface:

API Gateway — request validation, WAF, throttling.
SQS / SNS — message-level signature verification, schema validation, dead-letter handling for malformed messages.
S3 events — file-type validation, size limits, antivirus scanning before downstream processing.
EventBridge / Pub/Sub — schema registry validation.

Secrets and Configuration

Environment variables in Lambda are convenient and have caused real breaches. The safer pattern:

AWS Secrets Manager or Parameter Store — fetch at cold start, cache in memory for the function lifetime.
Lambda extensions for secrets caching reduce cold-start latency.
GCP Secret Manager with --set-secrets on Cloud Functions / Cloud Run.
Avoid long-lived API keys. Use OIDC + workload identity / IRSA wherever possible to talk to other clouds and SaaS.

Traditional EDR doesn't work — there's no host. The serverless equivalents:

Distributed tracing (X-Ray, Cloud Trace, OpenTelemetry) — the new "endpoint visibility."
Function-level metrics — invocation count, error rate, duration, throttles. Anomaly detection on these catches abuse patterns.
CloudTrail / Cloud Audit Logs — every function invocation, every IAM call, every config change.
Runtime protection (Sysdig serverless, Datadog SCA, Prisma) — runtime self-protection libraries that hook function execution.

"Serverless doesn't have fewer security problems. It has different ones — and the operational model that lets developers ship 200 functions without security review is exactly what makes them dangerous."

Serverless Security: The Lambda, Cloud Functions, and Cloud Run Reality

What Serverless Actually Removes (and Doesn't)

One Role Per Function. Always.

Input Validation Across Every Event Source

Secrets and Configuration

Serverless Security: The Lambda, Cloud Functions, and Cloud Run Reality

What Serverless Actually Removes (and Doesn't)

One Role Per Function. Always.

Input Validation Across Every Event Source

Secrets and Configuration

Observability That Works for FaaS