AgentStack
SKILL unreviewed MIT Self-run

Serverless Security

skill-shieldnet-360-secure-vibe-serverless-security · by ShieldNet-360

Lambda / Cloud Functions / Azure Functions hardening: IAM, timeouts, secrets, event injection — Applies to: when generating AWS Lambda / GCP Cloud Functions / Azure Functions code; when generating serverless.yml / SAM templates / functions framework; when wiring API Gateway, EventBridge, SQS, S3 triggers

No reviews yet
0 installs
6 views
0.0% view→install

Install

$ agentstack add skill-shieldnet-360-secure-vibe-serverless-security

Open-source listing — not yet scanned by AgentStack. Follow the source repository for install instructions.

Security review

⚠ Flagged

1 finding(s); flagged for manual review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures
  • high Dangerous shell/eval execution.

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution Used
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Serverless Security? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.