CASE 97 · LEDGER · 2024
Lambda secrets that never landed in an environment variable.
An accounting SaaS company had 340 Lambda functions, most of them with credentials in environment variables. The credentials were Parameter Store references, sure — but the resolved values were sitting in `aws lambda get-function-configuration` output, readable by anyone with `lambda:GetFunctionConfiguration`. We moved every secret out of env vars and into the Lambda extension pattern.
Accounting SaaS
SECURITY
2024
RESULTS
What changed, by the numbers.
SECRETS IN ENV VARS
0
GETFUNCTIONCONFIG EXPOSURE
ELIMINATED
COLD-START IMPACT
+12ms
ROTATION COVERAGE
+100%
HOW IT WENT
The threat model was specific: an analyst with read-only Lambda permissions, who could legitimately list configurations to support an investigation, would also see every credential the functions used. Some of those credentials were third-party API keys with significant blast radius.
The Parameters and Secrets extension runs as a Lambda layer that fetches secrets at function init time and exposes them on a localhost HTTP endpoint, never in the function configuration. Application code changed from `process.env.DATABASE_URL` to a lightweight HTTP call against the extension.
Cold-start cost was +12ms (acceptable; we measured against the function p99 budget). Every function rotated through the change in a six-week migration. `GetFunctionConfiguration` is now safe to grant to anyone who legitimately needs it; the secrets have moved.
RELATED · SAME DOMAIN
Other engagements in this space.
READY WHEN YOU ARE
Let's get your AWS bill (and architecture) in order.
The discovery call is free. You walk away with at least one concrete idea — even if we never work together.