Serverless computing removed servers from the security conversation and replaced them with something harder to see: dozens of short-lived functions, each wired to event sources, each carrying its own IAM role, each pulling in third-party packages you may never have audited. An AWS Lambda function can run for up to 900 seconds (15 minutes), scale from 128 MB to 10,240 MB of memory, and be invoked by more than a dozen event sources — S3 uploads, SQS queues, DynamoDB streams, API Gateway, EventBridge. Every one of those triggers is a new entry point, and traditional network-perimeter controls do not cover any of them. OWASP formalized this shift in 2017 with the Serverless Top 10, built on research from PureSec, cataloguing risks from SAS-1 (Injection) to SAS-10 (Improper Exception Handling). Nearly a decade later, with Log4Shell (CVE-2021-44228, CVSS 10.0) still turning up in unpatched Lambda layers, the list reads less like history and more like a checklist security teams are still working through.
What is the OWASP Serverless Top 10 and is it still relevant?
Yes — it's still the most widely cited framework for serverless-specific risk, even though it predates most current FaaS platforms' security features. Published in 2017 by OWASP with research contributed by PureSec (later acquired by Palo Alto Networks), the list defines ten categories numbered SAS-1 through SAS-10: Injection, Broken Authentication, Insecure Serverless Deployment Configuration, Over-Privileged Function Permissions and Roles, Inadequate Function Monitoring and Logging, Insecure Third-Party Dependencies, Insecure Application Secrets Storage, Denial of Service & Financial Resource Exhaustion, Serverless Business Logic Manipulation, and Improper Exception Handling and Verbose Error Messages. What hasn't changed since 2017 is the underlying reason these categories exist: in a FaaS model, the cloud provider secures the runtime and host OS, but the customer is entirely responsible for function code, dependencies, event-source configuration, and the IAM policy attached to every single function. AWS, Azure, and Google Cloud all describe this split explicitly in their shared responsibility models, and none of them scan your function's node_modules or requirements.txt for you.
How does serverless change the infrastructure attack surface compared to VMs or containers?
It shrinks the host-level surface and expands the identity and event surface. There's no OS to patch, no SSH port to lock down, and no long-lived process to exploit for persistence — a Lambda execution environment is torn down and rebuilt on a schedule the provider controls, often within minutes to hours. But that same architecture means an attacker who compromises one function inherits that function's IAM execution role, and pivots through whatever that role can touch: an S3 bucket, a DynamoDB table, a Secrets Manager entry, another Lambda function. A single API Gateway endpoint can front dozens of functions, each with its own permission set, so a misconfiguration in one function's role doesn't stay contained to that function — it becomes the blast radius for everything that role can reach. This is precisely SAS-4 (Over-Privileged Function Permissions and Roles), and it's the reason IAM policy review has to be a first-class part of serverless security review, not an afterthought handled by the cloud team.
Why do over-privileged IAM roles remain the top serverless risk?
Because the default posture in most serverless frameworks is permissive, not restrictive. Frameworks like the Serverless Framework and AWS SAM make it trivial to attach a single IAM role across an entire application's functions, or to reach for a managed policy like AWFullAccess-style wildcards during development that never get scoped down before shipping to production. A function that only needs s3:GetObject on one bucket prefix frequently ends up with s3:* on the whole account, because narrowing permissions requires enumerating exact actions and resource ARNs — extra engineering work that gets skipped under deadline pressure. The practical consequence: if an attacker achieves remote code execution inside that function (through SAS-1 injection via an unvalidated event payload, for example), they don't just get code execution — they get whatever that role's policy document grants, which in over-privileged deployments is often lateral access to unrelated data stores, secrets, and downstream functions.
What did Log4Shell reveal about serverless dependency risk?
It showed that "no server to patch" doesn't mean "no vulnerable dependency to patch." When CVE-2021-44228 was disclosed on December 10, 2021, the affected component — Apache Log4j2, versions 2.0-beta9 through 2.14.1 — was bundled inside countless Java-runtime Lambda functions and custom Lambda layers, often several dependency levels deep and invisible in a top-level pom.xml or deployment package review. Unlike a traditional server, where a security team could patch the OS package and be done, each affected Lambda function needed its deployment package or layer rebuilt and redeployed individually, and teams first needed an accurate inventory of which functions even used which layers and transitive dependencies — an inventory most organizations didn't have on hand at 2 a.m. on a Friday in mid-December. This is SAS-6 (Insecure Third-Party Dependencies) made concrete: serverless functions inherit every vulnerability in every package they import, and the ephemeral, distributed nature of FaaS deployments makes tracking that exposure across hundreds of functions significantly harder than tracking it across a fixed set of servers.
What is "Denial of Wallet" and how is it different from a normal DoS attack?
Denial of Wallet is a serverless-specific attack where the goal isn't to take a service offline, it's to run up the victim's cloud bill. Traditional Denial of Service degrades availability by exhausting fixed compute capacity; Denial of Wallet abuses the fact that serverless platforms auto-scale and bill per invocation, per GB-second of memory, and per outbound data transfer, so a flood of requests against a public, unauthenticated, or weakly-throttled function endpoint doesn't just slow things down — it scales cost linearly with attacker-controlled traffic, with no server capacity ceiling to cap the damage. OWASP catalogs this as SAS-8 (Denial of Service & Financial Resource Exhaustion), and it's why default protections matter: API Gateway's default throttle of 10,000 requests per second per account is a starting point, not a solved problem, if a single function behind it has no per-route rate limit, no authentication requirement, and a generous timeout that lets each request consume the maximum allowed 15 minutes of billed execution.
How Safeguard Helps
Safeguard maps these risks directly onto the code and configuration that create them, rather than treating serverless security as a separate checklist. Reachability analysis determines whether a vulnerable dependency — like a Log4j2 version affected by CVE-2021-44228 — is actually invoked by a given function's code path, so teams can triage the layers and packages that matter instead of patching every function with a matching library on the manifest. Griffin AI correlates function-level IAM policies with actual usage patterns to flag over-privileged roles (SAS-4) before they reach production, and Safeguard's SBOM generation and ingest give teams a real-time inventory of every dependency bundled into every function and layer, closing the exact visibility gap that turned Log4Shell into a multi-day scramble. When a fix is available, Safeguard opens auto-fix pull requests that bump the vulnerable package and, where policy drift is detected, propose the scoped-down IAM statement a function actually needs — turning a Serverless Top 10 finding into a merged fix instead of a backlog ticket.