Serverless security

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

Serverless Security

Lambda / Cloud Functions / Azure Functions hardening: IAM, timeouts, secrets, event injection

ALWAYS

• Give each function its own IAM execution role with the minimum permissions needed. Never share roles across functions; never reuse the bootstrap / developer role.
• Set a concrete function timeout (≤ 30s for synchronous APIs, ≤ 15min for background jobs). Defaults like 6s or 900s are footguns in different directions.
• Set reserved or provisioned concurrency limits per function to avoid bill blow-outs and to keep one noisy tenant from starving the rest of the account.
• Pull secrets at cold-start from a secret manager (AWS Secrets Manager / GCP Secret Manager / Azure Key Vault) with caching, not from plaintext environment variables.
• Validate every event payload against a schema before any code that touches it. Lambda doesn't care that the event arrived from "your" SQS queue — it could be a poison message.
• Enable structured logging that redacts known secret patterns (delegate to the logging-security skill).
• Enable X-Ray / OpenTelemetry tracing and CloudWatch / Cloud Monitoring alerts on error rate, throttle count, duration p95.
• Use a VPC for functions that touch a private database or service; otherwise the function gets full outbound internet, which is rarely desirable.

NEVER

• Use arn:aws:iam::*:role/* (wildcard PassRole), *:* action/resource, or iam:* permissions on a function role.
• Put secrets in environment variables in plaintext (use Secrets Manager references / aws_lambda_function.environment with kms_key_arn).
• Pass user-controlled strings to exec, os.system, child_process, subprocess.Popen(shell=True) — function URLs become RCE shortcuts when someone shells out.
• Trust the Lambda function URL or API Gateway resource as authentication. Function URLs with AUTH_TYPE=NONE are unauthenticated; require IAM, Cognito, or a Lambda authorizer.
• Disable aws_lambda_function.code_signing_config_arn for production functions; sign and verify on deploy.
• Use the latest image tag for container-image functions; pin by digest.
• Use long-lived static AWS access keys to call AWS from Lambda — use the execution role.
• Skip validation of S3 / SQS / EventBridge event payloads — assume any caller can post any shape, even if the trigger is "trusted".

KNOWN FALSE POSITIVES

• Custom CloudFormation / Lambda resource handlers (cfn-response) sometimes legitimately need broad permissions for short-lived setup.
• Cold-start warmer hacks (pinging the function on a CloudWatch Events schedule) are not, themselves, a security issue.
• Step Functions iterators with thousands of map states are not an "untracked concurrency" problem if the StateMachine has its own concurrency cap.