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

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.

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.

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.

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."