In serverless applications, keep secrets out of source code and out of plain environment variables. Store them in a secrets manager, give each function a role that can read only its own secrets, rotate them, and log every access. AWS's own Lambda documentation recommends Secrets Manager over environment variables for credentials.
Why is serverless different?
OWASP's serverless project makes the central point: moving to serverless "passes some of the security threats to the infrastructure provider", but the code you write still runs and can still be vulnerable. You no longer patch a server, yet you still decide where credentials live.
Serverless also multiplies the number of small deployable units. Fifty functions can mean fifty places a database password might be copied. That is the real risk: duplication and drift, not any one function.
What does AWS recommend for Lambda?
The Lambda environment variable documentation includes a note recommending that, "to increase security", you use AWS Secrets Manager instead of environment variables for database credentials and other sensitive values like API keys or authorization tokens. It also explains that environment variables are stored in the function's version specific configuration, and that you can configure a customer managed encryption key for them. Environment variables are fine for non sensitive settings such as a table name or a feature flag. They are a weaker home for a secret, because anyone who can read the function configuration can see them.
Other providers offer equivalents. Whichever you use, the pattern is the same: secrets live in a dedicated store, functions fetch them at runtime.
What do OWASP's rules say?
OWASP's Secrets Management Cheat Sheet states principles that fit serverless well.
Apply least privilege, with fine grained access controls on each secret, so a function reads only what it needs.
Automate secrets management, because manual handling raises the risk of leakage and of human error.
Rotate, and where possible create short lived credentials dynamically instead of keeping long lived ones.
Audit access, so you can answer who or what read a secret and when.
The cheat sheet also covers detection and incident response, which matters because secrets leak: into logs, into repositories, into error messages.
How do functions fetch secrets without slowing down?
Fetch once per container start and cache in memory for the lifetime of the execution environment, with a short expiry so rotation takes effect. Do not log the value, and do not return it in error messages. Keep the code that reads the secret in one small module so you can find it later.
What goes wrong in practice?
A deployment template copies the same database password into forty function definitions. Someone rotates it and misses six. Or a debug statement prints the whole environment to the logs, where it sits unprotected. Or one function role has a wildcard permission on every secret. Each failure is ordinary.
A constructed example
A team has a checkout function, a refund function and a reporting function, all using one shared database user. They split it into three users with different rights, store each in the secrets manager, and attach a role to each function allowing access to just its own secret. The refund secret rotates every thirty days through a scheduled job. When the reporting function later turns out to log request headers, the exposed credential can only read reports.
How to check or apply this
- Search repositories and function configurations for credentials, and rotate whatever you find.
- Move sensitive values into a secrets manager, and keep only non sensitive settings in environment variables.
- Give each function its own role, scoped to its own secrets.
- Cache secrets briefly in memory, and never log them.
- Rotate on a schedule and after any suspected exposure.
- Turn on access logging for the secrets store and review unusual reads.
Safeguard's secrets scanning checks code and history for credentials before they ship, and dependency scanning covers the libraries inside your functions.
Quick check
Are Lambda environment variables safe for secrets?
AWS recommends Secrets Manager instead for credentials and tokens. Use environment variables for non sensitive configuration.
How often should secrets rotate?
Rotate on a regular schedule your risk justifies, and immediately after any suspected exposure. Short lived credentials reduce the need.
Sources
Last reviewed: 18 October 2026.
