Part 3 of 4 in the Lambda Security Series
Part 1 described the risks. Part 2 introduced lambda-security-scanner and the nineteen checks it runs against every function. This part closes the loop. A finding is only useful if it leads somewhere, and it usually needs to lead to two places: a compliance control that an auditor cares about, and a command that an engineer can run to make the finding go away. The scanner produces both.
Why Compliance Maps to Serverless at All
Compliance frameworks were mostly written before serverless existed, so people assume they do not apply. They do. The controls are about outcomes, not implementation. “Restrict network access between trusted and untrusted zones,” “authenticate access to system components,” “enforce least privilege,” and “retain audit logs” are all requirements that a Lambda function either meets or violates, regardless of the fact that there is no server to point at.
The scanner evaluates each function against ten frameworks and reports which controls pass and which fail, per function. In total it maps to 81 controls:
| Framework | Controls | Focus |
|------------------------------------------|----------|---------------------------------------|
| AWS Foundational Security Best Practices | 5 | Lambda-specific Security Hub controls |
| CIS AWS Compute Services Benchmark | 8 | Compute service hardening |
| PCI DSS v4.0.1 | 8 | Payment card data protection |
| HIPAA Security Rule | 9 | Healthcare data security |
| SOC 2 | 11 | Service organization controls |
| ISO 27001:2022 | 11 | Information security management |
| ISO 27017:2015 | 4 | Cloud-specific security controls |
| ISO 27018:2019 | 5 | Protection of PII in the cloud |
| GDPR | 8 | EU data protection |
| NIST SP 800-53 Rev5 | 12 | Federal security controls |
One honest note on the control identifiers, because credibility depends on it. Most frameworks use their real citations: HIPAA **_164.312(a)(1)_**, ISO 27001 **_A.5.15_**, SOC 2 **_CC6.1_**, NIST **_AC-3_**, and so on. The CIS entries are different. They map to the genuine CIS AWS Compute Services Benchmark guidance for Lambda, but the **_CIS-Lambda.N_** identifiers are the scanner’s own labels, not the benchmark’s official recommendation numbers, which live under section 5. They are an alignment aid, not a verbatim citation. The scanner says so in its own documentation, and so do I.
How a Single Finding Becomes Compliance Evidence
The mapping is many-to-many. One misconfiguration usually breaks several controls at once, which is exactly why these findings matter to an audit.
Take a public function URL with **_AuthType: NONE_**. That single finding fails an authentication control in PCI DSS, an access-restriction control in SOC 2, an access-control requirement in NIST 800–53, and the corresponding AWS FSBP Lambda control, all from one misconfiguration. Fix the one thing and several controls flip to passing together. The same is true in reverse for plaintext secrets, which touch data-protection requirements across PCI DSS, HIPAA, ISO 27018, and GDPR simultaneously.
If you only need the posture and not the full security scan, run the compliance report on its own:
lambda-security-scanner security --compliance-only
That produces a per-function, per-framework breakdown of passed and failed controls, written as a JSON report on every run. It is the artifact to hand to an auditor or attach to a control review.
Fixing Every Finding
The rest of this article is the remediation playbook: one fix per check, with the AWS CLI command to apply it. Run these against your own functions after a scan tells you which ones need them.
A.1: Update deprecated and blocked runtimes
aws lambda update-function-configuration \
--function-name my-function \
--runtime python3.13
As of May 2026, examples of current supported runtimes are **_nodejs24.x_**, **_nodejs22.x_**, **_python3.14_**, **_python3.13_**, **_java25_**, **_java21_**, **_dotnet10_**, **_dotnet8_**, **_ruby4.0_**, **_ruby3.4_**, and **_provided.al2023_**. Update before the runtime’s block-update date arrives, not after, because a blocked runtime can no longer be updated in place and forces a more disruptive migration.
A.2: Reduce the maximum timeout
aws lambda update-function-configuration \
--function-name my-function \
--timeout 30
Set the timeout to what the function actually needs. A 900-second timeout on a function that finishes in three seconds means a stuck or abused invocation can burn compute for fifteen minutes before Lambda stops it.
A.3: Move secrets out of environment variables
# Store the secret in Secrets Manager
aws secretsmanager create-secret \
--name my-function/db-password \
--secret-string "MyPr0ductionP@ss!"
# Replace the plaintext value with a reference
aws lambda update-function-configuration \
--function-name my-function \
--environment '{"Variables":{"DB_SECRET_ARN":"arn:aws:secretsmanager:us-east-1:123456789012:secret:my-function/db-password-AbCdEf"}}'
Then resolve the secret at runtime with **_secretsmanager:GetSecretValue_**. The environment variable now holds a pointer, which is exactly the pattern the scanner treats as clean.
A.4: Reduce ephemeral storage
aws lambda update-function-configuration \
--function-name my-function \
--ephemeral-storage '{"Size": 512}'
The default is 512 MB. If the function does not need more, do not allocate more. Larger scratch space increases what a compromised function can stage locally.
A.5: Review external layers
aws lambda get-function-configuration \
--function-name my-function \
--query "Layers[*].Arn"
Any layer owned by an account that is not yours runs arbitrary code inside your function with your function’s permissions. Confirm every external layer comes from a source you trust.
A.6: Enable X-Ray tracing
aws lambda update-function-configuration \
--function-name my-function \
--tracing-config Mode=Active
A.7: Configure a dead letter queue
aws sqs create-queue --queue-name my-function-dlq
aws lambda update-function-configuration \
--function-name my-function \
--dead-letter-config TargetArn=arn:aws:sqs:us-east-1:123456789012:my-function-dlq
B.1: Restrict the resource policy
# Remove the wildcard statement
aws lambda remove-permission \
--function-name my-function \
--statement-id public-access
# Add a scoped permission instead
aws lambda add-permission \
--function-name my-function \
--statement-id api-gateway-invoke \
--action lambda:InvokeFunction \
--principal apigateway.amazonaws.com \
--source-arn arn:aws:execute-api:us-east-1:123456789012:myapi/*/GET/resource
B.2: Secure function URLs
# Require signed requests
aws lambda update-function-url-config \
--function-name my-function \
--auth-type AWS_IAM
# Or remove the function URL entirely
aws lambda delete-function-url-config \
--function-name my-function
B.3: Restrict CORS origins
aws lambda update-function-url-config \
--function-name my-function \
--cors '{"AllowOrigins":["https://myapp.example.com"]}'
B.4: Scope down execution roles
# Detach the overprivileged managed policy
aws iam detach-role-policy \
--role-name my-function-role \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
# Attach a least-privilege policy
aws iam attach-role-policy \
--role-name my-function-role \
--policy-arn arn:aws:iam::123456789012:policy/my-function-least-privilege
Use IAM Access Analyzer to generate a least-privilege policy from the function’s actual CloudTrail activity, rather than guessing at the permission set.
B.5: Give each function its own role
Each function should assume a role scoped to only what that function needs. Sharing one role across functions means a compromise of the weakest function inherits the access of all the others.
C.1: Attach a VPC when the function needs private resources
aws lambda update-function-configuration \
--function-name my-function \
--vpc-config SubnetIds=subnet-abc123,subnet-def456,SecurityGroupIds=sg-12345678
Not every function needs a VPC. Functions that reach databases, internal APIs, or other private resources do.
C.2: Span multiple Availability Zones
aws lambda update-function-configuration \
--function-name my-function \
--vpc-config SubnetIds=subnet-abc123,subnet-def456,SecurityGroupIds=sg-12345678
Provide subnets in at least two AZs. A single-AZ deployment goes down with that one AZ.
C.3: Restrict security group egress
aws ec2 revoke-security-group-egress \
--group-id sg-12345678 \
--ip-permissions '[{"IpProtocol": "-1", "IpRanges": [{"CidrIp": "0.0.0.0/0"}]}]'
aws ec2 authorize-security-group-egress \
--group-id sg-12345678 \
--ip-permissions '[{"IpProtocol": "tcp", "FromPort": 443, "ToPort": 443, "IpRanges": [{"CidrIp": "10.0.0.0/8"}]}]'
Replace allow-all outbound with the specific destinations the function needs. Unrestricted egress is how a compromised function exfiltrates data to anywhere.
D.1: Set log retention
aws logs put-retention-policy \
--log-group-name /aws/lambda/my-function \
--retention-in-days 90
D.2: Set reserved concurrency
aws lambda put-function-concurrency \
--function-name my-function \
--reserved-concurrent-executions 100
This matters most for functions that are reachable from outside. Without a concurrency cap, an attacker who can invoke the function can invoke it without limit.
E.1: Enable code signing
aws signer put-signing-profile \
--profile-name my-signing-profile \
--platform-id AWSLambda-SHA384-ECDSA
aws lambda create-code-signing-config \
--allowed-publishers SigningProfileVersionArns=arn:aws:signer:us-east-1:123456789012:/signing-profiles/my-signing-profile \
--code-signing-policies UntrustedArtifactOnDeployment=Enforce
aws lambda put-function-code-signing-config \
--function-name my-function \
--code-signing-config-arn arn:aws:lambda:us-east-1:123456789012:code-signing-config:csc-abc123
Set the policy to **_Enforce_**, not **_Warn_**. Warn logs an untrusted artifact and deploys it anyway.
E.2: Add failure destinations to event source mappings
aws lambda update-event-source-mapping \
--uuid my-esm-uuid \
--destination-config '{"OnFailure":{"Destination":"arn:aws:sqs:us-east-1:123456789012:my-function-esm-dlq"}}'
Fix Them in This Order
If you fix everything in score order, you fix the right things first. The scanner’s deductions already encode the priority:
- Public access. A public resource policy and a public function URL each cost 25 points. Remove wildcard principals and require authentication on function URLs. Do this today.
- Plaintext secrets. Worth 20 points without KMS. They are readable by anyone with a common configuration-read permission. Move them to Secrets Manager or SSM.
- Overprivileged execution roles. An admin-equivalent role costs 20 points; service wildcards and privilege escalation cost 10. Scope them to least privilege.
- Blocked runtimes at 15 points, then deprecated runtimes at 10. Blocked runtimes can no longer be patched at all. Deprecated runtimes have stopped receiving patches.
- CORS and shared roles, 10 points each. Restrict origins and split shared roles into per-function roles.
- Everything else: logging and retention, network controls, code signing, dead letter queues, tracing, and concurrency. Lower individual weight, but together they are the difference between a function you can investigate after an incident and one you cannot.
One Layer Left
Part 1 was the problem: serverless moved the attack surface closer to your code, and the misconfigurations are invisible until they are exploited. Part 2 was the tool: nineteen read-only checks, a score per function, and a clear list of what is wrong. This part was the payoff: every finding mapped to the compliance controls that care about it, and a command to fix each one.
That covers the configuration layer completely, which is what lambda-security-scanner checks and what most teams get wrong first. But there is one layer no posture scanner reaches: the code that runs inside the function, the dependencies it ships, and the credentials it holds at runtime. A clean configuration scan and a vulnerable function are entirely compatible. Part 4 covers that application layer, and it is the difference between a competent Lambda security posture and a complete one.
The project is open source under the MIT license:
