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:PassRoleconditions 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.