Serverless architecture removes a great deal of infrastructure from an organization’s operational workload. But it does not remove the relationships that attackers can exploit.
A function may exist for only seconds. Yet its permissions, event sources, secrets, downstream services, deployment dependencies, and access to other cloud resources can extend much further.
That distinction matters, because serverless security is easy to evaluate at the wrong level. A security team may see a small function with limited code and no persistent server to compromise. An attacker sees something different. It sees an identity with permissions, an event-driven entry point, and temporary credentials. It sees connected services, and potentially a route to something more valuable.
So for security leaders, the real question isn’t simply whether a serverless function is secure. It’s what becomes reachable if that function is compromised.
Executive TL;DR
- Serverless reduces infrastructure management, not attack-path complexity. Risk shifts toward IAM permissions, execution roles, event sources, APIs, secrets, and the relationships between cloud services.
- A compromised function is often only the beginning. Business impact depends on what its execution role can access, invoke, read, modify, or use to reach additional resources.
- Least privilege should be evaluated as a path, not just as individual policies. A function may have limited direct access while still reaching sensitive data indirectly, through another function, identity, or service.
- Ephemeral compute does not eliminate security-relevant state. Serverless execution environments can be reused. Security teams should understand the platform’s actual lifecycle, rather than assume every invocation starts clean.
- Trusted cloud infrastructure can support attacker operations too. Threat actors have used legitimate serverless services, such as AWS Lambda Function URLs, for command-and-control. That weakens simple trust-by-domain or trust-by-provider assumptions.
- Remediation must follow the full attack chain. Fixing the vulnerable function doesn’t establish whether credentials were exposed, downstream resources were accessed, or another foothold was created.
- The executive requirement is effective reachability. CISOs should require evidence of what an attacker could reach after compromising a serverless workload. Passing a configuration review isn’t the same thing.
The Infrastructure Disappeared. The Attack Path Did Not.
Serverless platforms shift much of the responsibility for operating infrastructure to the cloud provider. Operating systems, scaling, most of the runtime, and the physical hosts disappear from the application team’s direct management.
Some security responsibilities move with them. Others remain firmly with the customer.
Research published in the Journal of Cloud Computing describes this distinction well. Serverless Computing: A Security Perspective shows that serverless can reduce infrastructure-level responsibilities. At the same time, it introduces new challenges. Application logic, access control, and service interaction all raise the stakes. So does the sheer number of components involved in a single application.
A more recent 2025 systematic review of serverless security research reaches a similar conclusion from a different angle. The authors examined research published between 2018 and 2024. They organized serverless risk across five layers: runtime, network, function, orchestration, and data. They also flagged continuing gaps, particularly around function-level observability and data lifecycle protection.
The strategic issue, then, is abstraction. The organization manages fewer infrastructure components directly. But security decisions end up scattered across code, IAM policies, and cloud services. They also touch APIs, triggers, resource policies, deployment pipelines, and third-party dependencies.
That can make effective privilege hard to see.
The Function Is Only the Entry Point
Consider a typical AWS Lambda application. A function receives data from an API, a message queue, an object-storage event, a database change, or another AWS service. To complete its task, Lambda assumes an IAM execution role, one that gives the function access to selected AWS resources.
AWS documentation on Lambda execution roles confirms that this role determines which services and resources the function can reach. AWS specifically recommends trimming these permissions down to what the function actually needs, before it ever reaches production.
From an attacker’s perspective, this creates one straightforward question after gaining code execution: what can this identity do?
From Vulnerability to Blast Radius
The original vulnerability itself may be mundane. Unsafe input handling, a vulnerable dependency, an exposed function URL, or insecure application logic can each open the door. The value of the compromise depends on what comes next.
SentinelOne documented a Lambda lateral-movement attack scenario that illustrates exactly this. Vulnerable application code provides the initial execution point. The compromised function also carries an overly permissive IAM role. It stores sensitive values in environment variables, and it has access to other functions. Once code execution is achieved, the attacker can pull information available to the function. From there, they use its permissions to enumerate and invoke additional Lambda functions.
The vulnerability opened the door. The permissions decided how far the attacker could go.
This is the same identity problem organizations face with other non-human identities more broadly. Our article on the hidden risks of service principals and managed identities covers similar ground. Identities built for automation can accumulate real privilege quietly, without the scrutiny given to human privileged accounts.
Serverless functions deserve that same attention.
Least Privilege Can Still Hide a Path
Reviewing permissions function by function is necessary. It may not be sufficient.
GRASP research presented at The Web Conference 2024 examined security policies across 731 open-source AWS Lambda applications. Ninety percent of the applications in the dataset used only global policies, rather than function-specific ones. Thirty percent showed full connectivity between application functions and resources.
But the more important finding is conceptual, not statistical. GRASP models permissions as reachable paths, rather than evaluating each permission relationship in isolation.
One function may not have permission to read a sensitive resource directly. But it might be allowed to invoke another function that can. Individually, Function A cannot access sensitive data, and Function B can. But if Function A can control or invoke Function B, that changes everything. The path becomes Function A → Function B → sensitive data.
The effective security posture is the path, not the first permission in the chain.
Why This Matters for Red Teaming
This matters a great deal for red teaming. Real attacks rarely respect the architectural boundaries defenders use to organize controls. Attackers combine them instead.
Take a low-value function, a permissive execution role, an exposed API, a downstream storage resource, and another trusted service. Reviewed separately, each may look acceptable. Together, they can add up to a viable route into sensitive information.
We’ve seen the same principle play out elsewhere in cloud environments. A storage resource doesn’t need to start out completely public to create exposure. Our analysis of cloud storage misconfiguration attack paths found something similar. Identity relationships and surrounding configuration can matter just as much as the storage setting itself.
Serverless architecture only raises the stakes for understanding those relationships.
Temporary Credentials Can Create Permanent Consequences
AWS Lambda assumes its configured execution role every time the function runs. Those permissions let the function perform the cloud operations the application needs.
If an attacker gains execution inside that function, the compute instance’s lifespan isn’t really the point. What matters is what can be reached while the credentials and permissions are still usable.
That may include reading objects from storage, querying databases, or accessing application secrets. It may mean invoking other functions, interacting with queues or messaging services, or calling internal APIs. In some cases, it extends to modifying cloud resources, or reaching another identity with greater effective privilege.
This changes how the organization should think about blast radius. A function processing a routine business workflow might look low-risk when judged by its code alone. That picture changes fast if its execution role connects to customer records, financial processes, identity systems, or other privileged workloads.
The duration of the function, in other words, is a poor proxy for the duration or scale of business impact.
Ephemeral Does Not Mean Memoryless
There’s another assumption worth challenging: that everything disappears once execution ends.
That isn’t quite how AWS Lambda works. AWS explains, in its execution-environment lifecycle documentation, that execution environments can be frozen and reused. Objects initialized outside the handler can remain available. Contents stored in /tmp can persist while that execution environment is retained. Unfinished background processes can even resume if the environment gets reused.
AWS consequently advises developers against placing security-sensitive user data in reusable execution environments. The risk: exposure across invocations.
This shouldn’t be read as conventional host persistence, though. AWS is explicit that applications shouldn’t assume an execution environment persists indefinitely.
The distinction matters. Security teams should avoid importing server-centric assumptions into serverless environments in either direction. A Lambda function is neither a traditional persistent server, nor a fully disposable security context. Its state can’t always be ignored after invocation.
Testing needs to reflect how the platform actually behaves, not how either extreme assumption suggests it should.
Trusted Cloud Services Can Work for the Attacker Too
Serverless infrastructure doesn’t need a misconfigured Lambda function to enter an attack chain at all.
In 2025, Palo Alto Networks Unit 42 documented a campaign involving a previously undocumented backdoor named HazyBeacon. The attackers, targeting government organizations in Southeast Asia, used AWS Lambda Function URLs as command-and-control infrastructure. Unit 42 described the technique as using legitimate cloud functionality to build a scalable communication channel. It’s one capable of blending into trusted cloud traffic.
This wasn’t a vulnerability in AWS Lambda. It also wasn’t evidence that the victims’ own Lambda deployments had been compromised. It points to a different problem entirely: attackers can use the same trusted infrastructure organizations rely on every day.
A connection to a major cloud provider isn’t inherently benign just because the destination belongs to a recognized provider. Is your monitoring built to tell the difference?
Trust as a Moving Target
This follows a broader attacker pattern we’ve examined in Living off the Land attacks. Legitimate capabilities become valuable precisely because organizations already trust them.
It also resembles the defensive problem posed by modern domain-fronting and cloud-evasion techniques. The mechanism is different, but the strategic problem is similar. Reputation-based trust becomes less reliable once adversaries can operate through legitimate infrastructure.
For CISOs, this means cloud adoption changes more than just the assets that need protecting. It changes what “trusted traffic” even means.
Why Patching the Vulnerable Function Is Not Enough
When a serverless application is compromised through vulnerable code, the immediate response is predictable. Fix the vulnerability, redeploy the function, verify that exploitation no longer works.
That addresses the entry point. It may not address the attack path.
If the compromised role could reach additional resources, security teams need to dig further. What was accessible during the compromise? Which actions were actually performed? Were secrets exposed? Did downstream services change? Did another identity or resource become a new foothold?
This same remediation problem shows up in traditional environments too. Removing the initial vulnerability doesn’t necessarily remove everything an attacker gained afterward. Our previous analysis of attacker persistence after remediation covers this broader failure mode in more depth. Serverless changes the artifacts defenders investigate, but not the fundamental need to trace the full sequence of attacker actions.
The unit of remediation, then, should be the attack path. Not merely the vulnerable component.
What CISOs Should Require From Serverless Security
Security leadership doesn’t need to review every Lambda policy by hand. It does need assurance that the organization can answer the right questions.
What Is Effectively Reachable?
Inventory alone isn’t enough. Security teams should be able to map the relationships between functions, execution roles, and resource policies. That mapping should extend to triggers, APIs, databases, storage, messaging systems, secrets, and other cloud services. The goal is understanding effective reachability, not simply documenting individual permissions.
What Happens After One Function Is Compromised?
Every high-value serverless workload should have a known blast radius. Assume code execution in a function, then ask the hard questions. What credentials become available? What resources can the role access? What other functions or services can it invoke? Can those resources expose another credential or privilege boundary? Can the path eventually reach sensitive data?
This is exactly where offensive testing becomes materially different from a compliance review.
Are Execution Roles Genuinely Function-Specific?
AWS recommends least-privilege execution roles. Organizations should challenge shared or broadly scoped roles, wildcard permissions, and unnecessary cross-service access. Roles that expanded gradually as application requirements changed deserve a second look too. A policy that was appropriate at deployment may not stay appropriate after several development cycles.
Are Event Sources Treated as Attack Surface?
Serverless functions are event-driven by design. API requests, object uploads, and queue messages all represent inputs into application logic. So do database events, scheduled jobs, and calls from other services. Security testing should examine the full set of event sources capable of reaching sensitive functions. Public HTTP endpoints are only part of that picture.
Are Secrets Separated From Application Execution?
Sensitive values shouldn’t be treated as ordinary application configuration. AWS recommends services such as Secrets Manager or Systems Manager Parameter Store for this. Embedding secrets directly in code isn’t the answer.
But there’s a second question worth asking, and it’s just as important. Does the function have access to more secrets than it actually needs? Moving a secret into a vault doesn’t reduce exposure if a compromised workload can still retrieve everything stored inside it.
Can Monitoring Distinguish Trusted Cloud Use From Trusted Cloud Abuse?
HazyBeacon illustrates exactly why domain reputation alone can’t answer that question. Security teams need enough cloud, DNS, network, identity, and application telemetry to understand how cloud services are actually being used. Whether the destination belongs to AWS, Microsoft, Google, or another trusted provider isn’t, by itself, enough to go on.
Test the Path, Not the Component
Serverless environments make a strong case for attack-path-oriented security testing.
A configuration review can tell you a function has a permission. A vulnerability scanner can identify a vulnerable dependency. A CSPM platform can flag an exposed resource. A code scanner can catch unsafe application logic.
Those findings all matter. But an attacker asks a different question: can I combine them?
That’s the question red teaming and adversary simulation are built to answer. Testing should start with realistic entry points. From there, it should trace whether an attacker can move from function compromise to credentials. From credentials, can they reach cloud resources? And from those resources, another identity or service? The end point: data or business processes that matter.
The goal isn’t proving that every misconfiguration is exploitable. It’s identifying the combinations that create material business impact.
Frequently Asked Questions (FAQ)
Is Serverless Inherently Less Secure Than Traditional Infrastructure?
No. Serverless changes the security model. It doesn’t simply make it more or less secure.
Cloud providers manage more of the underlying infrastructure. But organizations remain responsible for application logic, permissions, identities, event sources, data access, secrets, and service-to-service relationships. The real risk is assuming that reduced infrastructure management also means reduced security complexity.
What Is the Biggest Security Risk in Serverless Environments?
There’s no single universal risk. But excessive or poorly understood effective privilege is one of the most consequential.
A vulnerable function becomes far more dangerous when its execution role can reach further. Sensitive storage, databases, secrets, other functions, or higher-value identities all raise the stakes. So the important question isn’t only what permissions a function has directly. It’s what those permissions allow it to reach indirectly.
Can Attackers Move Laterally From a Compromised Serverless Function?
Yes, wherever the function’s permissions and surrounding architecture allow it.
A compromised function may access credentials, invoke additional cloud services, enumerate resources, or interact with storage and databases. It may even reach other functions. Lateral movement in serverless environments is primarily a question of identity, permissions, and service relationships, not movement between traditional hosts.
Does an AWS Lambda Function Disappear Completely After Execution?
Not necessarily.
AWS Lambda execution environments can be reused between invocations. Data stored in /tmp may remain available while that execution environment is retained. So can objects created outside the handler, and some unfinished processes.
That said, this shouldn’t be confused with conventional persistent access to a server. AWS doesn’t guarantee that a particular execution environment will remain available.
Are Temporary Cloud Credentials Low Risk Because They Expire?
Not automatically.
Temporary credentials do reduce some forms of long-term exposure. But an attacker only needs them to stay valid long enough to do damage. That could mean reaching another resource, retrieving data, invoking another service, or exposing another credential. Credential lifetime and business impact are simply different measurements.
Why Are Event Sources Important in Serverless Penetration Testing?
Because event sources determine how execution reaches a function in the first place.
HTTP requests are only one possibility. Functions may also process object uploads, queue messages, database events, scheduled tasks, notifications, and calls from other cloud services. A penetration test that only evaluates public endpoints can miss important entry points and trust relationships as a result.
Can Legitimate Cloud Services Be Used by Attackers?
Yes. The HazyBeacon campaign documented by Unit 42 used AWS Lambda Function URLs as command-and-control infrastructure.
The significance here isn’t that Lambda itself was vulnerable. It’s that attackers were able to use legitimate cloud infrastructure as part of their operations. That makes simple provider reputation an increasingly weak indicator of whether traffic is benign.
What Should CISOs Ask Their Teams About Serverless Security?
A useful starting question: if one high-value function were compromised today, what could the attacker reach next?
Security teams should be able to answer that with real evidence. That evidence should cover execution roles, reachable services, event sources, secrets, storage, downstream identities, monitoring, and potential business impact.
Is a Configuration Review Enough to Assess Serverless Risk?
No.
Configuration reviews are valuable for identifying permissions, exposure, and policy weaknesses. But they don’t necessarily establish whether several individually acceptable configurations can combine into an exploitable attack path.
Offensive testing adds value precisely by validating whether those relationships can actually be chained together under realistic attack conditions.
How Should Organizations Test Serverless Environments?
Testing should move beyond isolated components and evaluate end-to-end attack paths instead.
That means realistic entry points, application vulnerabilities, event sources, execution roles, secrets, downstream services, storage, and identity boundaries. It also means the ability to move from one cloud resource to another. The objective isn’t simply finding more findings. It’s identifying which combinations can produce meaningful business impact.
Serverless Changed the Infrastructure. Security Still Has to Follow the Attacker.
The attraction of serverless is real. Less infrastructure to operate, rapid deployment, and elasticity — all of it is genuine. So is the closer alignment between application logic and business needs.
Security teams should not respond by treating serverless as inherently unsafe. They should respond by testing the assumptions abstraction creates.
A short-lived function can hold powerful permissions. A small policy can create broad connectivity. A trusted cloud endpoint can carry hostile traffic. A fixed vulnerability can leave the consequences of compromise sitting elsewhere in the environment.
For CISOs, the important question isn’t whether the organization has secured each serverless component individually. It’s whether the organization has tested what an attacker can reach once those components connect.
That’s where architecture becomes an attack path, and where offensive security provides the evidence, configuration reviews alone cannot.
If your organization relies on serverless and cloud-native workloads, contact wizlynx group to assess whether the paths between identities, functions, services, and sensitive data hold up under realistic attack conditions.
About wizlynx group
wizlynx group is a CREST-accredited offensive security company headquartered in Switzerland, operating across Europe, North America, Latin America, and Asia. wizlynx group specializes in penetration testing, red teaming, adversary simulation, social engineering, and advanced security assessments for enterprise clients.