serverless-security

• SKILL.mdcore · 7,031 bytes
• SKILL.mdcore · 7,031 bytes
• SKILL.mdcore · 7,031 bytes
• metadata.jsonasset · 1,542 bytes
• references/platform-settings.mddoc · 7,479 bytes
• references/verifying-findings.mddoc · 3,854 bytes

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. -->
<!-- Do not edit by hand; the source of truth is skills/serverless-security/SKILL.md. -->

# Serverless Security

What a function-as-a-service platform changes: an execution environment reused between invocations so /tmp and module globals outlive a request, an event envelope that is attacker-influenced whichever trigger delivered it, encrypted-at-rest configuration that the control-plane API still returns in cleartext, and concurrency as the boundary between an incident and a bill. Use when generating Lambda, Cloud Functions, or Azure Functions code, serverless.yml or SAM templates, or wiring API Gateway, EventBridge, SQS, or S3 triggers.

## ALWAYS

- Treat the **execution environment as reused**. The platform freezes it when the handler returns and thaws it for the next invocation, which may serve a different tenant. So a module-level global holding per-request state — a decrypted payload, an authorization decision, a tenant id, a connection bound to one caller's credentials — is visible to the next request. Cache only what is safe to share, and reset or scope everything else inside the handler.
- Treat **`/tmp` as shared, persistent, and finite**. It is the only writable path, it survives across invocations in the same environment, and a fixed filename written for one user is readable by the next. Use a per-invocation subdirectory, delete it before returning, and never read back a path without having written it in the same invocation.
- Validate the **whole event, envelope included**. The trigger's identity is not authentication: an S3 object key is chosen by whoever can PUT to the bucket, SQS message attributes and EventBridge `detail` are producer-supplied, and an API Gateway authorizer context is only as trustworthy as the authorizer. Validate against an explicit schema before any code touches the payload, and where a function has more than one trigger, check the source discriminant and route by allowlist.
- Give each function its **own execution role** with only the permissions its stated job needs. `iam-best-practices` owns policy scope and the escalation paths; what is serverless-specific is one role per function, never shared, because a shared role gives every function the union of what any of them needs.
- Set concurrency deliberately, and know which control you are reaching for. **Reserved** concurrency caps a function's parallel executions and is the denial-of-wallet control; **provisioned** concurrency pre-initialises environments to remove cold starts and *bills for them whether or not they are used*. Reserved capacity is also drawn from a shared account pool, so setting it per function is a decision about the account, not just that function.