When access keys can deploy Lambda code, the cloud control plane becomes the attacker’s execution path. That breaks the assumption that serverless is insulated from abuse because no server is owned directly. The real failure is over-privileged identity, which lets stolen credentials become deployment authority and turns ordinary application access into malware delivery.
How serverless deployment authority becomes the attack path
When AWS access keys can deploy Lambda code, the control plane is no longer just administration, it is execution. That means a stolen key can move from ordinary authenticated access into code deployment, which collapses the separation between “can use the app” and “can change what the app does.” In practice, the risk is not the presence of serverless, it is the privilege attached to the credential.
That is why the dangerous boundary is the deployment permission itself. A key that can publish or update functions can inject code into a trusted runtime, trigger downstream actions, and persist through infrastructure the defender may not even think of as a host to harden. For workload identity and deployment-path hygiene, see Cloud Workload Identity Guide.
In other words, serverless changes the shape of the target, not the security rule. If the credential can deploy, the attacker does not need to “own a server” in the traditional sense, because the platform will run attacker-supplied code on the account owner’s behalf. That is a privilege problem first, and a serverless architecture problem only secondarily.
What actually breaks: trust, isolation, and blast radius
The first thing that breaks is the assumption that application access and infrastructure change are separate concerns. Once deployment rights sit behind long-lived access keys, the same secret can become a code-injection path, a data-access path, and a persistence path. The attacker can package malicious logic as legitimate deployment activity, which makes detection harder than a simple login anomaly.
The second break is blast-radius containment. Serverless often looks small and ephemeral from the outside, but deployed code can still reach cloud services, read environment variables, call APIs, and invoke other managed resources. If the key is over-privileged, compromise of one credential can cascade into storage access, secret retrieval, or further privilege expansion. The Codefinger incident is a useful reminder that stolen AWS keys are often the bridge from initial compromise to destructive cloud activity, including Codefinger S3 ransomware 2025.
The third break is trust in “managed” execution as a safety blanket. Serverless removes server administration, but it does not remove authentication, authorization, or deployment governance. If the control plane accepts code from a compromised identity, the platform is faithfully executing the attacker’s will, not protecting you from it.
Why this pattern is a cloud identity problem, not just a Lambda problem
The core issue is over-privileged identity. Access keys that can deploy functions are effectively holding production change authority, so key compromise becomes code execution. That is materially different from a read-only or narrowly scoped application key, because the attacker can alter behaviour rather than merely observe or query it.
Practitioners should treat this as a deployment-authority design flaw whenever a single credential can both authenticate and publish code. AWS access keys should be assumed high impact if they can call deployment APIs, especially when they are long-lived, shared, or embedded in build and automation paths. In broader cloud compromise patterns, reused or exposed keys regularly lead to direct account abuse, as shown in Uber breach 2016 and Imperva breach 2019.
Good serverless security therefore starts with the question: should this identity be able to change code at all? If the answer is no, the deployment path should be separated from routine application access, and the credential should be scoped so that compromise cannot become arbitrary function publication. For deeper material on stolen-key abuse and cloud credential fallout, TruffleNet stolen AWS keys campaign 2025 is a good comparison point.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | AWS access keys are authenticators whose lifecycle and rotation affect deploy authority. |
| AC-6 — Least Privilege | The issue is over-privileged identities that can publish Lambda code. | |
| Recommendation — Rotate, scope, and inventory deploy-capable access keys to reduce credential abuse risk. Limit deployment permissions to the smallest set of identities that truly need them. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | A key that can deploy code is an overprivileged non-human identity pattern. |
| Recommendation — Remove code-deploy permissions from credentials that only need runtime or read access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and credential governance are central when access keys can publish code. |
| Recommendation — Review and constrain privileged cloud accounts and keys that can change production code. | ||
| ISO/IEC 27001:2022 | A.8.5 — Secure Authentication | Access keys enabling deployment are authentication material requiring tight control. |
| Recommendation — Protect deploy-capable credentials with strong issuance, rotation, and monitoring controls. | ||
Practitioner Guidance
What to prioritise: Separate deployment authority from runtime access. If the same access key can both operate an application and update Lambda code, treat that as a material privilege-design defect, not a routine permission issue.
What to verify: Check whether function deployment, function configuration updates, and artifact publishing are restricted to a tightly controlled path with short-lived credentials, strong approval, and clear ownership. Any long-lived key with deploy capability deserves immediate blast-radius review.
Common mistake: Teams often secure the function runtime and ignore the deployment plane. That leaves the easiest attack path untouched, because the attacker only needs the right to publish code once, not to exploit the runtime after the fact.
Practitioner takeaway: If a credential can deploy serverless code, assume it can turn trusted cloud execution into attacker-controlled execution; the right fix is to narrow deployment privilege until code change is a separately governed action.
Related resources from NHI Mgmt Group
- What breaks when AWS configuration files expose access keys?
- What breaks when AWS access keys are deleted during an active compromise?
- What breaks when exposed AWS access keys are quarantined but not immediately disabled?
- How should security teams decide whether JIT access is safe for non-human identities?