Why serverless security testing matters for regulated teams
If you are about to launch a service built on functions behind API Gateway, a customer security questionnaire or an insurer may already be asking for evidence that it has been tested. Serverless security testing examines the functions, their triggers and the identities and services they reach, and it gives you a findings report with reproducible descriptions and prioritized remediation that you can share with an auditor or customer. Because there is no server to harden in the traditional sense, the risk concentrates in four places: the event data a function accepts from API Gateway, S3 or queues, the execution role the function assumes, the way secrets reach the code, and the outbound requests the function makes. Server-side request forgery is the category to plan for on the outbound side. The OWASP API Security Top 10 2023 lists it as API7:2023, and a function that fetches a URL taken from user input can be pointed at the cloud metadata endpoint to obtain temporary credentials.
Under the AWS shared responsibility model, AWS secures the infrastructure that runs Lambda and API Gateway, while your team remains responsible for what you configure: the code, the event sources, the roles, the environment variables and the network paths. That split is why a provider-hosted runtime still needs testing. Confirm before you commission work that the functions, API Gateway stages and any AppSync APIs in scope appear on the AWS list of services customers may test without prior approval, and that any test involving command and control needs prior approval. The AWS penetration testing policy sets those boundaries, and your provider should confirm them in writing before any traffic is sent.
Start the decision by listing each function, its trigger, the role it runs under and the secrets it reads. Ask whether the role grants more than the function needs, whether credentials are stored in environment variables or retrieved from a managed secrets store, and which internal or metadata addresses the function can reach. Those answers determine the depth of testing and the evidence an auditor will want to see. A serverless test that covers only the public endpoint leaves the execution role and outbound path untested, which is where many regulated teams find their most consequential issues.
What can be in scope for a serverless test
A serverless test is defined by its entry points, the data and identities behind them, and the accounts and functions the tester is allowed to touch. Each card below is a scoping decision that should be written down before any testing starts.
Lambda and Lambda@Edge functions
Functions are the code paths that handle input, so they are the core of the test. Scope should list each function by name, its runtime, its trigger, and whether it runs in the Regional or the edge deployment. Lambda@Edge functions run close to viewers, so confirm which CloudFront distributions invoke them. Both AWS services appear on the AWS list of services customers may test without prior approval, but the rules of engagement still need to name the functions in writing.
API Gateway and AppSync entry points
API Gateway and AppSync are the public doors that pass request data into functions, so they define the attack surface. Scope should cover each API stage, its authorizers, its request validation settings, and any custom domains. Confirm whether the test includes a WebSocket or GraphQL endpoint, since these are often missed in inventories. Both services are on AWS's no-prior-approval list, which covers this kind of testing.
Event sources, queues and storage
Functions rarely act alone. They read from S3 buckets, SQS queues, SNS topics, DynamoDB streams and EventBridge rules, and each source can carry attacker-controlled content into the function. Scope should list every source that feeds each in-scope function, and state whether the tester may send test events into queues or upload objects to buckets. Agree on test data and cleanup rules so that shared resources are not left polluted.
Execution roles and assumed identities
Each function runs under an execution role, and the role determines what a compromised function can reach. Scope should list the roles attached to in-scope functions, any roles they can assume, and the services those roles can call. Reviewing identity paths is often a separate Cloud IAM review, so state clearly whether role permissions are tested in this engagement or only reported as findings.
Accounts, regions and environments
Scope should name the AWS accounts, regions and environments in which testing may occur, and exclude shared accounts that host other tenants or production data the tester should not reach. Confirm that the tester only accesses resources the client owns and controls. Testing in a staging account that mirrors production is a common choice, but the written scope should say whether production is included.
Rules of engagement and command and control
Put the rules of engagement in writing, covering permitted techniques, forbidden actions such as denial of service, testing windows, contacts and escalation paths. Services on AWS's no-prior-approval list do not need approval for ordinary assessment, but any testing that includes command and control (C2) needs prior approval from AWS. Ask the provider to confirm early whether any planned activity falls into that category.
How a serverless engagement runs, phase by phase
The sequence moves from agreed scope and rules of engagement through function, trigger and identity review to active testing, so that each finding is tied to a specific function, trigger or role and can be verified after fixes.
Agree scope and rules of engagement
DeployOpen and the client agree in writing which AWS accounts, regions, API Gateway stages, Lambda functions and event sources are in scope, and which are excluded. The client confirms the account owner and that every target belongs to them. Testing of Lambda, API Gateway and AppSync does not need prior approval under the AWS penetration testing policy, but any command and control testing does, and denial of service, flooding and similar activity is prohibited. The output is a signed scope document and a list of test windows and contacts.
Inventory functions, triggers and identities
The tester builds a map of every function, the events that invoke it (HTTP routes, queues, streams, schedules, storage notifications), the environment variables it reads, and the execution role attached to each. Infrastructure-as-code templates and read-only console or CLI views are reviewed against the client's own records. The output is an inventory that shows which entry points are reachable from the internet and which identities they can assume.
Review function code and execution roles
Reviewers read function source and dependencies for unsafe handling of event data, such as values passed into queries, shell calls, file paths or downstream HTTP requests. They also compare each execution role's policy against what the function actually calls, looking for wildcard actions, broad resource scopes, cross-account trust and permissions that allow changing the function or its role. The output is a list of code and privilege findings with the function name, the line or policy statement, and the suggested least-privilege change.
Test each trigger and event path
Testers send crafted requests to each exposed entry point to check how event data is validated, how authentication and authorization are enforced at API Gateway and inside the function, and whether errors reveal internal detail. This covers injection categories and broken object-level authorization, mapped to the OWASP API Security Top 10 2023. Testing is paced to avoid flooding or denial of service. The output is a set of reproduced findings with request and response evidence, kept to the minimum needed to prove each issue.
Check secrets handling and metadata access
Reviewers check whether credentials, API keys and connection strings are stored in environment variables, parameter stores or a secrets manager, and whether they are logged or returned in responses. Where a function accepts URLs or fetches remote resources, testers check for server-side request forgery and whether the function can reach the instance metadata service and obtain role credentials. The output records which secrets are exposed, which metadata paths are reachable, and whether the metadata service enforces its current access controls.
Verify logging and detection coverage
Testers confirm which invocations, authorization decisions and failed requests generate logs, and whether those logs are retained and reviewed. They compare the account's logging configuration with the relevant CIS AWS Foundations Benchmark version 7.1.0 recommendations on audit logging, which the client's own team should confirm against their environment. The output is a table of logging gaps that show where an attack in the tests would have gone unrecorded.
Report findings and agree remediation
The report ranks each finding by impact and likelihood, names the affected function, trigger or role, explains the weakness category in plain language, and gives remediation steps the client's engineers can apply. Findings are reviewed in a closing meeting so the client can contest facts before the report is final. The output is a final written report and a remediation list with owners agreed by the client.
Retest fixed findings
After the client applies fixes, DeployOpen retests each finding against the same function, trigger or role, confirms the fix works, and checks that the change did not open a related path. The retest result is recorded against each original finding ID, with status marked as resolved, partly resolved or open. The output is a retest addendum that the client can share with its auditor or customer alongside the original report.
Weakness categories in functions and their triggers
This table maps the main weakness categories in serverless functions and their event triggers to what each looks like in a real deployment and why it matters. Read each row as a question to ask in scoping: if the function and its trigger have this pattern, the assessment should test it. Rows describe categories only, not methods.
| Weakness category | What it looks like in this target | Why it matters |
|---|---|---|
| Injection through event data | Event fields from API Gateway requests, S3 object metadata or queue messages reach a query, shell, template or downstream API without validation | The event payload is attacker-influenced input, and function code often trusts it more than it would trust a web form |
| Missing input validation on event sources | Functions accept any event shape from a trigger, with no schema check on types, sizes or allowed values | Unchecked fields widen the attack surface for injection, logic abuse and resource exhaustion across every trigger type |
| Over-privileged execution roles | The function's IAM role grants wildcard actions or resources far beyond what the code needs | A single compromised function can then reach data and services it was never designed to touch |
| Excessive permissions to other services | The role allows writes or reads to unrelated databases, buckets, queues or other functions, sometimes inherited from a shared role | Lateral movement from one function into the wider account becomes a short, unmonitored path |
| Secrets in environment variables or code | API keys, database passwords or tokens are stored as plain function configuration or hard-coded in source or packages | Secrets readable by anyone with configuration access, or leaked through logs, repositories and deployment artifacts, enable direct access to backends |
| SSRF to metadata and internal endpoints | Functions fetch user-supplied URLs, and requests can reach the instance metadata service at 169.254.169.254 or internal addresses | Metadata endpoints can return temporary credentials for the function role, turning a fetch feature into credential exposure |
How testing a function differs from testing a server
A Lambda function has no persistent host to port-scan or patch, so the testing effort moves to the places where the function's behavior is actually decided. In a server assessment, much of the work starts with the operating system, open ports and patch level. For a function behind Amazon API Gateway, the attack surface is the event the function receives, the execution role it assumes, the environment variables and secrets it reads, and the downstream services it can reach. A tester should map each trigger (API Gateway routes, authorizers, event source mappings, S3 or EventBridge notifications) and ask what the function trusts about the incoming event. Injection flaws in event fields, such as values passed into a shell, a query or a template, are the core of this work. The AWS list of services customers may test without prior approval includes Lambda, API Gateway and AppSync, so the tester can exercise these entry points within AWS's published rules, but the scope document should still name each trigger and the account it belongs to.
The execution role is usually the most consequential finding source in a serverless review. A function's role defines what a successful injection can reach, so the tester should compare each role's policy with what the code actually calls, looking for wildcard actions, resources left open to *, and permissions to read other functions' environment variables or to write to shared buckets. Credentials are ephemeral and injected at invocation, which means the tester should confirm where secrets live (Secrets Manager, Parameter Store or plain environment variables) and whether any are logged or returned in error messages. Server-side request forgery is also specific here: a function that fetches a URL taken from an event can reach the instance metadata service and obtain the role's temporary credentials. The OWASP API Security Top 10 lists this under API7:2023, and the OWASP API Security Top 10 2023 is the reference to align the finding categories with.
Short-lived execution changes how evidence is collected. A function may exist for seconds and leave no state to inspect afterward, so the tester cannot rely on logging into a host to see what happened during a test. Before testing starts, confirm that CloudWatch Logs, AWS X-Ray tracing and CloudTrail data events are enabled for the functions and API stages in scope, and that retention is long enough for the report to be verified. Ask the tester to record invocation identifiers for every test request so each finding can be traced to a specific log entry. Logging review is itself a finding area: a function that writes full request bodies, tokens or role credentials to its logs turns the log store into a secondary target. Confirm with your provider whether the scope includes reviewing log content and who may access it.
What drives serverless testing cost and duration
This table compares the components that move the cost and effort of a serverless test, showing who is paid for each, whether it is one-time or recurring, and what to request in a quote. Use it to check that a proposal scopes each driver explicitly. No price or duration is implied, since DeployOpen quotes follow from the written scope.
| Cost component | Who is paid for what | One-time or recurring, and what to request in a quote |
|---|---|---|
| Functions and triggers in scope | Tester time to map each Lambda function, its event sources (API Gateway, AppSync, queues, storage events) and the code paths that consume event data | One-time for the initial test. Request a written inventory of functions, triggers and event sources, with the ones excluded and why. |
| AWS accounts and environments | Tester time to set up access, confirm account ownership and repeat checks in each account or stage such as dev, test and production | One-time per account, with extra effort for each added environment. Request the account list, the environments covered and whether production testing is included. |
| Execution role complexity | Time to review each function's IAM role, trust relationships, resource policies and any cross-account paths to find over-broad or escalatable permissions | One-time review, which grows with the number of distinct roles. Request the count of roles reviewed and whether policy analysis is included or handled as a separate IAM review. |
| Depth of code review | Hours spent reading handler code, dependency use and input handling, separate from the black-box testing of triggers | One-time, and it scales with codebase size and language count. Request whether source code is provided and whether review covers third-party libraries. |
| Outbound calls capable of SSRF | Time to test functions that fetch URLs, call internal services or reach metadata endpoints, and to confirm that network and IMDS controls limit impact | One-time for each outbound path. Request the list of functions that make user-influenced outbound requests and the controls the tester should verify. |
| Command and control testing approval | Work to prepare the approval request to AWS and to scope any C2 activity. AWS requires prior approval for testing that includes command and control, so this adds lead time | One-time request per engagement, with added lead time. Request confirmation of whether C2 is in scope and who submits the AWS approval request. |
| Retest after remediation | Tester time to verify fixes, rerun affected test cases and update the report | Recurring per remediation cycle. Request the number of retest rounds included and the deadline for submitting fixes. |
Serverless testing across AWS, Azure and Google Cloud
AWS publishes a penetration testing policy that lists services customers may assess without prior approval. The list includes AWS Lambda and Lambda@Edge, API Gateway and AppSync, which cover the common serverless entry points. A serverless test on AWS therefore usually starts from the function, its event sources and its execution role, and the policy sets the outer boundary for what the tester may do.
- Covered services: Confirm that every function, trigger and integration in scope sits on the listed services. Anything outside the list needs a review against the policy before testing.
- Prohibited activity: DNS zone walking, denial of service, request flooding and S3 bucket or subdomain takeover are excluded from customer testing.
- Simulated events: Red, blue or purple team exercises, simulated phishing and DDoS simulations need a request at least 2 weeks ahead, per the policy.
- Command and control: Any testing that includes C2 needs prior approval from AWS.
- Configuration baseline: The CIS Amazon Web Services Foundations Benchmark at version 7.1.0 gives a reference for IAM, logging and storage settings that surround the functions.
Ask the provider to map each function and trigger to the in-scope services in writing before testing starts.
Azure testing is governed by Microsoft's Cloud penetration testing rules of engagement rather than a service list. Those rules prohibit DDoS under all circumstances, phishing or social engineering of Microsoft employees, access to data or tenants the tester does not own, and network-intensive fuzzing. Serverless work on Azure must therefore stay inside subscriptions and tenants that the client controls and must avoid load that could affect shared platform services.
- Owned resources only: Testing must stay within the client's subscriptions and tenants. Shared identity or cross-tenant paths need explicit scoping before work begins.
- Excluded techniques: Denial of service and network-intensive fuzzing are not permitted, which shapes how function triggers and event payloads are exercised.
- Vulnerability reporting: Weaknesses found in Microsoft services must be reported to MSRC, so the provider should explain how any platform-level finding would be handled.
- Configuration baseline: The CIS Microsoft Azure Foundations Benchmark at version 6.0.0 covers role assignments, storage, logging and network exposure around the serverless resources.
- Entra ID links: Confirm how function identities and managed identities connect to Entra ID, since role scope often drives the most serious findings.
Check the current rules of engagement before scoping, because the testing requirements belong to Microsoft and can change.
Google Cloud does not require customers to notify Google before penetration testing their own infrastructure. The condition is that the test follows the Acceptable Use Policy and Terms of Service and affects only the customer's own projects. For serverless work, that means the test scope is defined by project boundaries, and any function, trigger or service account reaching into another project falls outside the permitted scope.
- No pre-notification: Google does not require advance notice for testing your own projects, so the scope document becomes the main control.
- Project boundaries: Confirm which projects host the functions, their triggers and any service accounts they use, and whether any call crosses into a project the client does not own.
- Acceptable Use and Terms: Testing must follow Google's Acceptable Use Policy and Terms of Service, which the provider should confirm in its methodology.
- Configuration baseline: The CIS Google Cloud Platform Foundation Benchmark at version 5.0.0 supports review of IAM bindings, service account keys and audit logging.
- Service account scope: Over-broad service account roles are a frequent finding in serverless reviews, so the provider should list them explicitly in the test plan.
Confirm the project list and service account inventory in writing before testing, because the scope depends on it.
Serverless entry point coverage differs by provider, and the rules that apply to a function on one cloud may not map cleanly to another. The services a provider lists as testable, the activities it excludes and the notice it requires all vary. Scope should therefore be built per provider, not copied from one tab to another, and each provider's current terms should be checked at the time of the engagement.
- Per-provider scope: Build a separate scope table for each cloud that lists functions, triggers, identities and data stores.
- Written confirmation: Ask the provider to confirm in writing which serverless services are covered and which activities are excluded.
- Hybrid estates: Where functions call services on another cloud, the testing rules of both providers apply to the relevant calls.
- Change control: Provider terms and benchmark versions change, so record the versions used in the engagement.
- Testing approach: Injection through event data, over-privileged execution roles, secrets handling and SSRF to metadata services apply on every cloud, but the permitted tests differ.
Ask your provider to confirm the testing rules for each cloud in writing before any serverless test begins.
Frameworks that expect serverless testing
This table compares the frameworks and customer reviews that ask for application and cloud testing, and shows where serverless functions and their triggers fall within each one. Use it to see which evidence a test can support, then confirm with your auditor or customer which controls the report needs to cover. The main takeaway is that DORA's access review and vulnerability scanning expectations apply to serverless components as much as to servers.
| Framework or review | What it expects | How serverless testing supports it |
|---|---|---|
| DORA, Article 21 (Delegated Regulation (EU) 2024/1774) | Review access rights at least every 6 months for systems supporting critical or important functions | Execution roles, invoke permissions and API Gateway authorizers can be reviewed for over-broad grants and unused access, with findings recorded for the access review |
| DORA, Article 10 (Delegated Regulation (EU) 2024/1774) | Automated vulnerability scanning of critical or important assets at least weekly | Scanning covers dependencies and runtimes, but it does not replace manual testing of event inputs, triggers and secrets handling, so ask whether the test complements the scanning cadence |
| Customer security reviews | Evidence that the vendor tests its cloud-hosted application and its entry points | Penetration test scope can name specific functions, API routes and triggers, with results showing which event sources were tested |
| AWS testing policy | Pre-approval rules for customer testing of managed services | Lambda, API Gateway and AppSync are on the listed services that customers may test without prior approval, so the scope should confirm that no command and control testing is planned |
| Internal audit and risk committees | Evidence that cloud-hosted components were assessed against a defined method | Test reports can map findings to injection through event data, SSRF to metadata services and secrets exposure, with severity and retest status |
What you receive and whether it satisfies an auditor or customer
A serverless engagement produces evidence that can feed an audit, a customer security review or an internal remediation plan, but each piece has a different purpose and a different owner. The cards below separate what DeployOpen delivers from what an independent auditor or certification body issues, so you can match the package to the audience that will read it.
Report structure and scope statement
The main report should open with the agreed scope: which functions, triggers, event sources, execution roles and secrets stores were in and out of the test, and which accounts they belonged to. It should state the test window, the testing approach and any AWS testing policy conditions that applied to API Gateway or Lambda. Ask for the scope section to be checked against the signed statement of work before the report is shared outside your organization.
Severity ratings with stated criteria
Each finding should carry a severity rating and a short explanation of how that rating was reached, including the exposure of the entry point and what the function could reach through its execution role. Ask whether the rating method is documented, whether it is consistent across findings, and whether a finding with a lower base rating was raised because of the permissions it held.
Reproduction context at category level
Findings should describe the weakness category, the affected component and the conditions under which it was observed, such as an event field passed unvalidated to a query. The report should not contain working payloads, exploit code or step-by-step commands. Ask for enough detail that your engineers can confirm the fix independently, and confirm how sensitive evidence such as captured tokens is redacted and stored.
Remediation tied to configuration changes
Remediation guidance should name the change to make: a narrower execution role policy, a secret moved from an environment variable to a managed secrets store, an IMDSv2 requirement on the function's host path, or an input schema enforced at the API Gateway. Each item should map to a finding ID so your engineers can track it in your change process and prioritize the work against your own risk register.
Retest results and closure record
A retest confirms whether each remediated finding is closed, partially closed or still open, and records the configuration evidence used to decide. Ask for the retest to be listed as a separate section with its own date, so an auditor or customer can see the sequence of findings, fixes and verification. Confirm in advance whether retesting is included in the fixed-scope fee or quoted separately.
Attestation-style letter, not an audit report
DeployOpen can provide a letter summarizing that testing was performed, its scope and its high-level outcome. This letter is not an audit report, attestation or certification. Auditors and certification bodies issue their own reports, and a customer or assessor may require their own review of your evidence. Ask in advance which document your auditor or customer expects so the package fits their process.
What your team prepares before testing starts
The most useful preparation is read access to the function code, deployment packaging and configuration before the test begins. Without it, the tester can only infer how an event is parsed, which runtime and libraries are in use, and what the execution role can reach, so findings for injection through event data and over-privileged roles become guesses. Ask for read access to the function definitions, the trigger configuration (API Gateway routes and authorizers, AppSync resolvers, event source mappings), the attached execution roles and their policies, and the environment variable names. Confirm in writing who will hold that access and whether it is read-only, because a tester who can change a role or variable is no longer testing the system as deployed.
Two more inputs decide whether the test stays inside agreed boundaries. The first is a dedicated test account or staging environment that mirrors production functions, triggers and data stores. Testing live functions that write to payment, customer or health records can corrupt data and trigger downstream actions, so the scope document should name the account IDs, function names and any resources that are out of bounds. The second is a current inventory of functions and triggers, including the ones nobody remembers building. Serverless estates grow quickly, and an untracked function with a public URL is often where the most serious findings sit. Check the inventory against the account before scoping, and record which functions handle regulated data.
Operational preparation is what keeps the test safe and attributable. Name one technical contact who can stop testing, one owner who can approve changes to the test window, and an on-call contact for the operations team. Agree a change freeze for the window so that deployments do not alter functions mid-test and make findings unreproducible. Confirm that logging is enabled for the functions, API Gateway and the account, so that the tester's activity and the platform's responses can be reviewed afterward and so that the security operations team can separate test traffic from real attacks. Finally, agree the rules for outbound traffic from functions, including whether tests may trigger calls to external endpoints and whether metadata service requests from the function are in scope. Confirm the exact rules with your provider and your cloud provider's current testing terms before the window is booked.
What to check before choosing a serverless testing provider
Serverless testing depends on how well a provider understands cloud rules, function-level risk and the paperwork that follows the test. The cards below cover the evidence, approvals, scope terms and deliverables to request before you sign, so you can compare providers on the same terms.
Evidence of AWS serverless experience
Ask for a description of past AWS serverless engagements, covering the services involved, such as Lambda behind API Gateway or AppSync, and the kinds of findings reviewed. Look for specifics about event sources, execution roles and how functions were reached during testing. Vague claims about cloud experience do not show that a team has tested functions, so ask for the testers' hands-on work with this architecture. Confirm any client references under confidentiality terms.
Understanding of the AWS testing policy
AWS lets customers test a listed set of services without prior approval, and that list includes Lambda, API Gateway and AppSync. Any testing that includes command and control needs prior approval, and some simulated events require a request at least 2 weeks ahead. A provider should explain which activities fall inside these rules, which need approval, and how it avoids prohibited activities such as denial of service.
Written scope and rules of engagement
Require a written scope that names the accounts, regions, functions, API stages and triggers in play, along with the excluded resources and the testing windows. Rules of engagement should state which techniques are allowed, such as event payload fuzzing, and which are not. Check that the provider confirms it will test only resources your organization owns, because function code often calls third-party services that are outside your authority to test.
Method for event-driven attack paths
Ask how the provider traces input from each trigger, such as HTTP requests, queues, object storage events and scheduled jobs, into function code and downstream calls. Testers should explain how they check for injection through event data, over-broad execution roles and access to metadata services from inside a function. A method that only runs a web scanner against the public endpoint misses most serverless risk.
Secrets and identity review approach
Confirm that the provider reviews how functions obtain credentials, including environment variables, parameter stores, secret managers and the execution role attached to each function. Ask whether the review covers which identities a compromised function could reach and whether it considers secrets written into deployment packages or logs. The answer should show a clear path from code to permissions.
Deliverable samples and retest terms
Ask for a redacted sample report that shows severity rationale, reproduction steps written for developers, and remediation guidance tied to the affected function or role. Confirm the retest terms in writing: whether one retest is included, how long after the report it must be requested, and whether retest findings appear in an updated report. Ask which artifacts an auditor or customer can rely on.
Methodology references and confidentiality
Ask the provider to name the methodology it follows, such as the OWASP guidance for APIs or the CIS AWS Foundations Benchmark for configuration review, and to explain how it applies them to serverless components. Confirm the confidentiality terms cover test data, credentials found during testing and report contents. Verify any certification claims directly with the issuing body, because certifications held by individual staff differ from company-level assurance.
Serverless security testing questions buyers ask
Do we need serverless security testing if no compliance framework requires it?
Not always, but the decision should rest on exposure rather than on the presence of a framework. A function behind API Gateway is a public entry point that accepts untrusted input, runs under an execution role, and often reads secrets from configuration. If that function handles customer data, payments or access decisions, a test shows whether event data can be abused, whether the role can reach more than the function needs, and whether the function can call internal metadata or private services. Customers, insurers and internal risk committees also ask for this evidence. If the function is low risk and sits behind strong controls, a configuration review or IAM review may answer the question at lower effort.
What drives the cost of serverless security testing?
Cost follows the size and shape of the written scope. The main drivers are the number of functions and triggers in scope, such as API Gateway routes, AppSync resolvers, queue or storage event sources and scheduled jobs; how many distinct execution roles and secrets stores must be reviewed; whether the work includes only configuration review, only black-box testing of entry points, or both; the number of environments and accounts involved; and how much time the client's team must spend on access, documentation and walkthroughs. Retesting after fixes is usually priced separately. Ask the provider to list each component in the quote so you can see what is one-time work and what would recur if you add functions later. DeployOpen does not publish a price list; a quote follows from the written scope.
How long does a serverless security test take?
Duration depends on the number of functions and triggers in scope, the depth of the configuration review, the number of accounts and the time needed for access and clarifications. Testing time is only one part; scoping, environment preparation, reporting and the client review meeting also take calendar time. Confirm the expected duration, the start conditions and the dates for each deliverable in the written quote, and ask what would extend the timeline. Timelines should be agreed in writing before work starts, since most engagements are fixed-scope.
What does our team need to provide for a serverless test?
Plan for a named technical contact, read access to the account or accounts in scope, a list of functions, triggers and API definitions, and a description of which data each function processes. Engineers should expect to explain how events are generated, how secrets are injected and rotated, and which downstream systems the functions call. Test accounts or non-production copies are preferable for any active testing. Confirm the access model, the testing window and who approves changes in the quote so the provider does not wait on basic information during the engagement.
Can our in-house team test serverless functions ourselves?
Yes, many teams run configuration checks and basic input testing internally, and that is a reasonable first step. Internal testers are often strong on the application and know the business logic, but independent testing adds value when the function handles regulated data, when a customer or auditor asks for an independent report, or when the same team builds and reviews its own code. The practical test is whether your team can document the scope, follow a defined methodology, record evidence and retest fixes. If any of these is missing, a fixed-scope external test is usually the better route for the first engagement, with knowledge transfer built into the deliverables.
Does Lambda or API Gateway testing need AWS approval first?
For the services on the AWS list of those customers may test without prior approval, approval is not required. That list includes AWS Lambda and Lambda@Edge functions, API Gateway and AppSync, alongside EC2, RDS, Fargate and others. Under AWS's penetration testing policy, customers may assess their own infrastructure on those services without asking first, but the policy still prohibits certain activities, including denial of service and request flooding, and requires advance notice for simulated events such as red team exercises. Any testing that includes command and control needs prior approval. Confirm the current policy before the test, and make sure the scope excludes prohibited activities and any third-party services the functions call.
How is retesting billed after findings are fixed?
Retesting is usually scoped separately from the original test. It covers the findings you fixed, the code or configuration changes you made and the evidence needed to show closure. Cost depends on how many findings are retested, whether the fixes touch shared roles or triggers that need broader checks, and whether a new configuration review is needed. Ask the provider to state in the quote whether retesting is included, how many rounds are allowed, the deadline for requesting it and how the updated report will record each finding's status. Ongoing or continuous testing can be arranged as a retainer if your functions change frequently.
Official sources for serverless testing rules
Before scoping a serverless test, read the AWS penetration testing policy for your account. It lists AWS Lambda, API Gateway and AppSync among the services customers may test without prior approval, which covers the usual entry points for functions. The same policy prohibits certain activity in customer testing, including denial of service and request flooding, and requires advance notice for simulated events such as red team exercises. Ask your provider to confirm in writing which of these rules apply to each function, trigger and account in scope, and whether any planned technique, such as command and control, needs prior approval from AWS.
The AWS shared responsibility model sets the boundary for what you can fix. AWS secures the infrastructure that runs Lambda and API Gateway, while your team owns the function code, its execution role, environment variables, trigger configuration and the data it touches. Serverless findings therefore land mostly in customer territory. Agree in the statement of work which owner will act on each finding category, so that a weakness in an execution role is not left between your platform team and the cloud provider.
For the test cases themselves, the OWASP API Security Top 10 2023 gives a shared vocabulary for injection through event data and for server-side request forgery, which it lists as API7:2023. Pair it with the CIS Amazon Web Services Foundations Benchmark, currently at version 7.1.0 according to CIS, to check IAM, logging and configuration baselines. Confirm with your provider which benchmark version and which control sections they will map findings against, since the benchmark is licensed for commercial use and the mapping should match the version your auditor expects.
How DeployOpen scopes, tests, reports and retests serverless workloads
DeployOpen starts every Serverless security testing engagement with a written, fixed scope that names the functions, triggers, execution roles and secrets in play. The test is then run against that agreed boundary, and the findings, retest and handover are documented so your team and your auditors can follow them.
How we scope
- We list every function, trigger such as API Gateway or AppSync, and event source included in the written scope.
- We confirm which AWS services and tests fall within AWS's published rules, and flag anything needing prior approval.
- We agree which accounts, regions and data stores are in bounds, and which third-party integrations are excluded.
How we build
- We review each function's execution role against the permissions it actually needs, and map privilege escalation paths.
- We test how event data from HTTP requests, queues and storage triggers is validated before it reaches interpreters or queries.
- We check how secrets are stored, injected and rotated, and whether outbound requests can reach cloud metadata endpoints.
How we hand over
- You receive findings mapped to the affected function, role, trigger or configuration, with severity and reproduction context.
- Remediation guidance is written so your engineers can change the function code, IAM policy or configuration directly.
- Retesting of agreed findings is documented separately, so you can show closure to an auditor or customer security team.
How we support
- Ongoing support, upgrades and continuous testing for serverless estates are available as a retainer.
- Retainer scope, cadence and included retests are agreed in writing before any work starts.
- Ask us to confirm which parts of your serverless estate a retainer covers as functions and triggers change.
