Serverless security assessment: what gets missed when functions have no perimeter
Amara OkaforApril 29, 2026
Key takeaways
Serverless functions have no persistent network surface — the attack surface is IAM execution roles, event trigger inputs, execution environment secrets, and dependency packages, none of which standard network-layer scanners assess.
AWS Lambda execution roles routinely carry permissions that would allow account-level privilege escalation if the function code is compromised — in Vulnox assessments, overprivileged execution roles appear in the majority of engagements.
Secrets retrieved correctly from AWS Secrets Manager can still be exposed if the function logs the value during an unhandled exception — the storage mechanism is sound, the logging behavior is not.
Dormant serverless functions — scheduled jobs, event handlers with no active development — carry the oldest dependency trees and the least scrutiny, making them the highest-probability entry point for dependency-chain attacks.
Event injection through SQS, SNS, and S3 trigger payloads is functionally equivalent to web application injection but almost never included in serverless security assessment scopes.
A compromised function's lateral movement surface is defined entirely by its IAM role — no network pivoting required, just AWS API calls authenticated with the function's own identity.
TL;DR
Serverless environments eliminate the persistent infrastructure that traditional security assessment is built around, and most assessment methodology has not fully adapted to what replaced it. The real risk in Lambda and FaaS environments is in IAM role configurations, execution context secret handling, event payload processing, and dependency trees that nobody is actively maintaining. This article covers what a serverless security assessment needs to examine and what it consistently finds when it does.
The function that had been running unreviewed for eleven months
A fintech company requested a cloud security review after expanding their AWS environment. The scope was defined by the security team as: our production Lambda functions. They provided a list of fourteen functions they considered active. Vulnox ran an account-level function inventory first. The account contained 47 functions. The additional 33 included automated report generators, data transformation handlers, a Slack notification webhook, and several functions with names suggesting they were test deployments that had never been cleaned up. All 47 were executing under the same IAM role — the default role created when the first developer set up Lambda access two years earlier.
That default role had accumulated permissions across two years of 'just add what you need to make it work' IAM policy edits. It included s3:* on all buckets, rds:* on all database clusters, and lambda:InvokeFunction with a wildcard resource. It also included iam:PassRole, which under the right conditions allows an attacker to escalate privileges by passing a more permissive role to another service. Eleven of the 33 undiscovered functions had not been updated in over six months. Three had known-vulnerable dependency versions that would have been caught by any routine dependency scan. None of them were in scope for any previous security review because the security team did not know they existed.
Why the serverless attack surface requires a different assessment model
Traditional cloud security assessment starts with the network: what ports are open, what services are exposed, what can be reached from outside the perimeter. Serverless functions have no persistent network presence. A Lambda function exists as a deployment package and an IAM role. It spins up when triggered, executes, and terminates. During its execution window, it has whatever permissions its IAM role grants, whatever secrets were injected into its environment, and whatever input arrived in its event payload. The attack surface is not a network surface. It is an identity surface, a secret-handling surface, and an input-processing surface. Assessment methodology that starts with network enumeration finds nothing, because there is nothing to enumerate at the network layer.
Example
IAM role analysis is the clearest illustration of where the assessment focus needs to go. An execution role is not just a list of permissions — it is a capability set that an attacker can wield if they achieve code execution inside the function. A role that includes iam:AttachRolePolicy allows the function to attach arbitrary policies to IAM identities. A role that includes sts:AssumeRole with broad conditions allows the function to assume other roles. A role that includes ec2:RunInstances allows the function to launch compute infrastructure. None of these capabilities are visible in a network scan. They are visible only in an IAM policy analysis, and specifically in the analysis of what those permissions enable in combination, not just individually.
Effective IAM analysis for serverless environments goes beyond listing attached policies. It requires evaluating the transitive permissions available through policy combinations, the scope of resource ARNs (wildcard versus specific), the conditions on any permission boundaries, and whether the role can be used to modify its own policies or assume roles that could. Tools like Cloudsplaining and Parlament automate portions of this analysis, but the interpretation of what a permission set enables in the context of a specific environment requires manual review of what resources exist and what those resources connect to.
What shows up when the assessment covers the right surface
Assessment base: Vulnox serverless and cloud function security assessments, 2023-2024
Execution roles with privilege escalation paths through IAM API permissions
In Vulnox serverless security assessments, execution roles that enable account-level privilege escalation through combinations of IAM API permissions appear consistently. The pattern is not intentional over-permissioning. It is incremental permission accumulation — each permission was added for a specific operational reason by a developer who needed to unblock a deployment. No single permission addition triggered a security review. The combination of permissions that resulted, analyzed as a set, creates a privilege escalation path that bypasses account-level access controls. The role was never reviewed as a system — only evaluated permission-by-permission at the time each addition was made.
Clients consistently discover this during assessment for the first time. The prior assumption was that IAM permissions had been reviewed because each addition went through a review process. The review process evaluated individual permissions, not cumulative capability. Reviewing each permission in isolation and reviewing the role as a capability set produce different conclusions. Assessment needs to do the latter.
Secrets appearing in CloudWatch log output under exception conditions
AWS Secrets Manager and Parameter Store are the correct mechanisms for secrets management in Lambda environments, and most environments Vulnox assesses are using them. The finding is not that secrets are stored incorrectly. It is that secrets retrieved correctly are subsequently logged. The mechanism: a function retrieves a database password from Secrets Manager, stores it in a local variable, then encounters an unhandled exception. The exception handler logs the local variable scope for debugging. The database password appears in CloudWatch Logs with the default 90-day retention period. Anyone with CloudWatch Logs read access — a broader permission set than Secrets Manager read access — can retrieve it. This finding has appeared across financial services, healthcare, and SaaS environments in Vulnox assessments. It does not appear in static analysis of the secrets storage configuration because the storage is correct. It appears only in dynamic testing that induces exception conditions.
The standard remediation recommendation — use Secrets Manager instead of environment variables — does not address this finding because the environment is already using Secrets Manager. The actual remediation is exception handling that does not log local variable scope, and a CloudWatch Logs review for historical secret exposure in existing log streams. Clients who have already implemented Secrets Manager often assume this class of finding does not apply to them.
Undiscovered and unreviewed functions carrying outdated dependency packages
Function inventory consistently reveals functions that are not tracked in the security team's asset list. These are not rogue deployments — they are legitimate functions created for specific operational purposes, often by developers outside the security team's direct visibility, that were never added to the formal inventory. Scheduled jobs, data transformation utilities, internal notification handlers. Their dependency packages were current at deployment time. They have not been updated since because no active development is occurring. The functions work. No one has a reason to redeploy them. Their dependency trees carry whatever CVEs accumulated since the last deployment, unpatched and unmonitored.
Dependency scanning of known functions in a CI/CD pipeline does not find this finding because these functions do not go through the CI/CD pipeline. They were deployed manually or through an older process. The finding requires account-level function inventory as a prerequisite — listing what exists before deciding what to scan. Most serverless security assessments scope to a provided function list rather than beginning with discovery. That approach has a structural blind spot: it can only find findings in functions the client already knows about.
The most dangerous function in the account is probably the quietest one
Common belief
Security attention in serverless environments naturally concentrates on high-traffic functions — the API handlers, the payment processors, the authentication functions. These handle the most sensitive data and receive the most usage. They are also the most actively developed, most frequently updated, and most likely to have received recent security review.
What we found
When Vulnox runs account-level function inventories sorted by last-modified date and invocation frequency, the functions that have not been modified in the longest time and have the lowest invocation counts consistently produce the highest concentration of high-severity findings. This pattern holds across industries. The correlation between operational obscurity and security debt in serverless environments is strong enough to be a useful heuristic: if you can identify the five functions your team thinks about least, those are where the assessment should start.
Invocation volume does not correlate with security risk in serverless environments. A function invoked 10,000 times per day is actively monitored, frequently redeployed, and visible to the development team. A function invoked once per night by a CloudWatch Events rule to generate a report is invisible in the operational noise. It carries an execution role that was configured when it was built. Its dependencies have not been updated since it was last actively developed. If it was built before the team implemented Secrets Manager, its database credentials might be in environment variables that nobody has reviewed since deployment. The quiet function is the vulnerable function, because quietness and neglect are the same thing in serverless environments.
What standard assessment scopes consistently miss
Event trigger input validation across all trigger types
API Gateway-triggered Lambda functions get tested like web applications because the trigger looks like a web request. SQS, SNS, S3 event notification, DynamoDB stream, and EventBridge triggered functions are almost never tested with adversarial payloads. These triggers deliver structured event objects to the function handler. If the function processes fields from those event objects — extracts a filename from an S3 event and passes it to a shell command, parses a message body from SQS and uses it in a database query — those fields are injection vectors. They are not exposed through an HTTP interface, so they do not appear in web application testing. They require direct queue access, test topic subscriptions, or crafted event payloads delivered through the trigger service to test properly.
Container image-based Lambda security
Lambda functions can be deployed as container images rather than ZIP packages. Container-based deployments carry an entire Linux filesystem and are subject to container image vulnerability classes — base image CVEs, unnecessary binaries in the image that expand the post-compromise capability set, and image pull permissions. Container image scanning for Lambda is a different toolchain than Lambda ZIP dependency scanning. Environments that have implemented dependency scanning for ZIP-based functions frequently have no equivalent process for their container-based functions because the functions were migrated to container deployment for operational reasons and the security process was not updated to follow.
Function URL and resource-based policy exposure
Lambda function URLs allow functions to be invoked directly via HTTPS without API Gateway. Resource-based policies on Lambda functions can grant invoke permissions to other AWS accounts, specific IAM principals, or in misconfiguration cases, to everyone. These policies are separate from the execution role and do not appear in IAM role analysis. A function with a resource-based policy that allows cross-account invocation from an account that was used for a former employee's testing environment, or that allows invocation from a wildcard principal under specific conditions that are easy to satisfy, creates an external access path that does not require any credentials in the target account. Function URL and resource-based policy review needs to be an explicit scope item, not an implicit part of IAM review.
Where serverless security gaps are heading
Within 18 months, a publicly attributed cloud breach will be traced to a serverless privilege escalation chain where a compromised function used its IAM execution role to modify account-level IAM policies, and the post-incident finding will be that the function's role had been flagged by automated tooling but the alert had no assigned owner.
The technical precondition — overprivileged execution roles with IAM API permissions — is common in environments Vulnox assesses. The organizational precondition — automated tooling producing findings with no assigned remediation owner — is equally common. Cloud security posture management tools flag IAM findings continuously. Without an owner and a remediation SLA, flagged findings accumulate. The combination of a known-exploitable technical condition and an organizational process that does not resolve it is structurally predictable.
Confidence: mediumA publicly attributed cloud breach in 2026 or 2027 where the attack chain is traced to serverless IAM privilege escalation and post-incident review reveals the misconfiguration was previously flagged by automated tooling.Serverless dependency scanning will become a mandatory control requirement in SOC 2 Type II assessments for cloud-native SaaS companies within two years, driven by auditor guidance updates following a dependency-chain incident in a Lambda-heavy production environment.
SOC 2 auditor guidance on software supply chain controls has been expanding since the SolarWinds and Log4Shell incidents established dependency chain risk as a concrete audit concern. Serverless functions are the deployment artifact most likely to carry unmonitored dependency trees because they are not subject to server-level patch management. Once a dependency-chain incident is publicly attributed to an unmonitored Lambda package — which is a predictable event given current practices — auditors will add Lambda dependency scanning to their control evidence requirements.
Confidence: mediumSOC 2 auditor guidance or trust service criteria updates mentioning serverless function dependency scanning specifically by 2027.
The shared execution role is the single most dangerous default in serverless architecture
The pattern of multiple Lambda functions sharing a single execution role — usually a default role created early in account setup and expanded over time as functions were added — is the finding most likely to enable catastrophic compromise in serverless environments. A single overprivileged role means a successful exploit of any one function, regardless of how low-risk that function appears, provides the same access as exploiting the most sensitive function in the account. The blast radius of every function is identical because the identity is identical. This is an architectural decision, not a misconfiguration, and it persists because fixing it requires auditing and individually scoping IAM roles for every function — work that is deferred because it is tedious and not immediately visible as risk.
Counterargument
The counterargument is that least-privilege IAM scoping for dozens of functions is operationally expensive, creates ongoing maintenance burden as function requirements change, and produces role proliferation that is itself a management and audit challenge. Some organizations deliberately accept shared roles as an operational tradeoff. This is a legitimate position if it is a documented decision with a risk acceptance record. In practice, it is almost never a documented decision — it is the default that was never revisited. There is a meaningful difference between accepting a risk and being unaware of it.
Where to start this week if you have never done a serverless security assessment
Run an account-level Lambda function inventory before doing anything else. AWS CLI: aws lambda list-functions --region us-east-1 — run it against every region where you operate. Compare the output to your team's documented function list. The gap between those two lists is your first finding. For every function in the gap, pull the execution role and run it through a policy analysis tool — Cloudsplaining works for this. Look specifically for IAM API permissions: iam:AttachRolePolicy, iam:PutRolePolicy, sts:AssumeRole with broad conditions. Any function whose role includes those permissions has a potential privilege escalation path and needs immediate review. That process takes a few hours and does not require an engagement. It will tell you more about your actual serverless risk posture than any compliance checklist you have completed.
Further Reading
Vulnerability Assessment
comprehensive vulnerability assessmentDigital Footprint
mapping digital footprintNIST Vulnerability Assessment Definition
NIST's vulnerability assessment definitionOWASP Testing Methodologies
OWASP penetration testing methodologiesNational Vulnerability Database NIST
NIST National Vulnerability Database
Frequently Asked Questions
What does a serverless security assessment cover that cloud-native security tools miss?
Cloud-native security tools like AWS Security Hub and GuardDuty cover known misconfiguration patterns and network anomalies. They miss IAM privilege chain analysis — whether a function's execution role can be used to escalate to administrative access through attached policies — execution context secrets injected at runtime, event trigger input validation gaps, and transitive dependencies in the function package that carry known CVEs. These require active testing, not passive monitoring.
How do IAM misconfigurations in serverless environments lead to privilege escalation?
Serverless functions execute under IAM roles. When those roles carry permissions beyond what the function requires — common when roles are copied from development environments or assigned by developers who do not want to debug permission errors — an attacker who achieves code execution inside the function can call AWS APIs using the function's identity. If the role includes iam:AttachRolePolicy or sts:AssumeRole with broad conditions, the attacker can escalate from function-level access to account-level access without touching any other resource.
How are secrets exposed in serverless execution environments?
The three most common exposure paths in Vulnox assessments are: environment variables logged by the function runtime during exceptions, secrets passed as plaintext in event payloads that are stored in CloudWatch logs with default retention, and secrets hardcoded in the function package itself that become readable if the deployment artifact is stored in a world-readable S3 bucket. AWS Secrets Manager and Parameter Store solve the storage problem but not the logging problem — a secret retrieved correctly can still be logged by a poorly handled exception.
What is event injection in serverless functions and how do you test for it?
Serverless functions consume events from triggers — API Gateway, SQS, SNS, S3 notifications, DynamoDB streams. The event payload is the function's input. If the function passes event fields directly to downstream services — database queries, shell commands, HTTP requests to internal APIs — without validation, the event payload is an injection vector. Testing involves constructing malformed event payloads that probe for SQL injection, SSRF, and command injection at each trigger type. API Gateway-triggered functions get tested like web applications. SQS-triggered functions require direct queue access or a test queue to probe the deserialization and processing logic.
Why do serverless dependency vulnerabilities persist longer than in traditional applications?
Serverless function packages are immutable deployment artifacts. The dependency versions are pinned at deployment time and do not receive automatic updates. A function deployed with a vulnerable version of a library stays vulnerable until the entire function is redeployed with an updated package. Redeployment requires a CI/CD pipeline run, which requires someone to notice the vulnerability and trigger the process. Functions with no active development — event handlers, scheduled jobs, data transformation utilities — can run with known-vulnerable dependencies for months because no one is actively maintaining them.
What does serverless lateral movement look like after initial function compromise?
A compromised function's execution role defines the lateral movement surface. If the role includes s3:GetObject with a wildcard resource, the attacker can read every S3 object the function could reach. If the role includes lambda:InvokeFunction, the attacker can invoke other functions. If the role includes ec2:DescribeInstances or rds:DescribeDBInstances, the attacker gains infrastructure reconnaissance capability. Lateral movement in serverless environments does not require network pivoting — it happens through AWS API calls authenticated with the compromised function's identity.
How should serverless functions be scoped in a security assessment?
Scope should cover four areas: IAM role analysis for each function including transitive permissions from attached policies and permission boundaries, static analysis of the function package for hardcoded secrets and vulnerable dependencies, dynamic testing of each trigger type with adversarial event payloads, and CloudWatch log review for secrets appearing in historical log output. Functions that appear dormant — low invocation count, old deployment date — warrant specific attention because they are the least likely to have received security review since initial deployment.
Related Articles
API security assessment: what automated tools miss and manual testing finds
Automated API security tools find the vulnerabilities they were designed to look for. The findings that matter in real assessments, broken object-level authorization, JWT algorithm confusion, and unauthenticated internal endpoints, require a tester who understands what the API is supposed to do before probing what it actually does.
CVSS score explained: what the metric captures, what it misses, and how to fix your prioritization
In 40% of Vulnox assessments, vulnerabilities scored CVSS 9.0 or higher were on systems with compensating controls that materially reduced the actual risk. The score was accurate. The priority order it implied was not. This guide covers how to use CVSS correctly and what to layer on top of it.
Post-breach vulnerability assessment: what the attacker left behind
Most post-breach assessments start too late and end too early. They confirm what was hit, not what the attacker mapped before they moved. The second breach usually comes from the reconnaissance that happened in the first.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.