Getting listed on AWS Marketplace opens your product to enterprise buyers, AWS partner-led deals, and procurement workflows that bypass most traditional sales friction.
This post covers exactly what the AWS Seller Assurance program evaluates, what your penetration test needs to cover, what documentation you need to submit, and how to get ready before your deadline.
What the AWS Marketplace security review actually evaluates
AWS Marketplace’s Seller Assurance program is not a single checklist applied uniformly to every listing. The depth of review depends on what you’re listing and how you’re listing it.
If you’re listing a SaaS product, a container product, or an AMI that processes customer data, you will almost always trigger the full security review. Free trial listings, BYOL offerings, and data products may see a lighter version. If your listing falls under categories like security, healthcare, or financial services, expect additional scrutiny regardless of listing type.
The full review evaluates four things:
Security controls: AWS wants evidence of encryption in transit and at rest, logging and monitoring, patch management, and incident response capability.
Application security testing: AWS requires evidence you have tested your application for vulnerabilities, not just your infrastructure. A cloud configuration scan or network perimeter scan does not satisfy this. AWS expects authenticated testing against your actual application layer.
Data handling practices: Document what data you collect, where it lives, who can access it, and what happens to it when a customer offboards. If your product handles PII or regulated data types, specify the controls applied to each category.
Access control documentation: Demonstrate that access to your systems is governed by defined policies: internal access management, how customer access is scoped and revoked, and MFA enforcement for privileged accounts.
What’s in scope: your application layer, not AWS infrastructure
This is the shared responsibility model applied to the security review, and understanding it will save you time.
AWS is responsible for the security of the cloud. You are responsible for security in the cloud. For the purposes of this review, that means your application and everything it does is in scope. AWS infrastructure, including the underlying compute, managed services like RDS or S3 at the infrastructure level, and AWS’s own network, is out of scope.
Your scope includes the web application itself across all user-facing surfaces, any APIs your application exposes or calls, authentication and session management, how customer data is stored and transmitted, and any third-party integrations that touch customer data
Outside your scope: the physical infrastructure AWS operates, the managed service layer below your application’s configuration choices, and anything on AWS’s side of the shared responsibility line.
What your pentest needs to cover
AWS does not prescribe a specific testing tool, but it does expect coverage across the application layer. Here is what that means in practice.
Web application security across all surfaces
This includes both unauthenticated and authenticated surfaces. Unauthenticated testing covers your login page, public-facing endpoints, and anything accessible before a user signs in. Authenticated testing covers everything a logged-in user can reach, including account settings, data views, administrative functions, and any role-specific features. A test that only covers your public surface misses most of your actual attack surface.
API security
If your application exposes a REST or GraphQL API, every endpoint needs to be in scope. GraphQL surfaces are often undertested because traditional scanners do not handle introspection and query-level authorization checks well. Make sure your testing covers authorization at the API layer, not just the UI.
Authentication flows and session handling
This means testing for weak password policies, broken authentication, session fixation, improper logout, and token handling issues. A gap here typically looks like a session that persists longer than expected after logout, or tokens that are not invalidated server-side.
Data exposure risks
Test for unauthorized access to customer data, insecure direct object references, and any endpoint that returns more data than the requesting user is authorized to see.
Access control across roles and permission levels
Privilege escalation and horizontal access control gaps are among the most common findings in SaaS applications. A gap here looks like a standard user being able to access or modify another user’s records, or a non-admin user being able to reach admin-only functions by manipulating a request.
What documentations AWS expects from your security review
Completing a pen test is not enough on its own. AWS needs documentation that demonstrates the test was real, scoped appropriately, and acted upon.
A submission-ready report should include:
A scope statement : what was tested, which domains and endpoints were in scope, and the testing period.
Testing methodology : how the test was conducted, what tools or approach were used, and whether it included authenticated testing.
Findings with severity classification : each finding should be classified using a recognized framework. CVSS scoring and OWASP categorization are the most commonly accepted references. Findings should include a description, severity rating, and affected component.
Remediation evidence for critical and high findings: AWS expects that critical and high severity findings have been addressed before submission. The report should show either that findings were remediated and retested, or include a documented remediation plan with a timeline for anything not yet resolved.
Tester credentials or platform documentation: AWS needs confidence that the test was conducted by a qualified party. This can be a certified penetration tester, or documentation confirming the test was run on a recognized application security testing platform.
How a Beagle Security report maps to AWS’s requirements
Beagle Security conducts authenticated, agentic AI penetration testing against your web application and APIs, and produces a structured report that maps directly to what AWS Seller Assurance expects.
Here is how each element maps:
OWASP-mapped findings
Every finding is categorized against the OWASP Top 10. This gives AWS reviewers a recognized classification framework to evaluate findings against, rather than a proprietary or undefined categorization system
CVSS scoring and severity classification
Each finding carries a CVSS score and a severity classification across critical, high, medium, and low. This satisfies AWS’s expectation for severity-classified findings and gives you a clear basis for prioritizing what needs to be remediated before submission.
Scope documentation
The report includes a defined scope statement covering the tested domains, endpoints, and testing period. You can use this directly as your scope statement in your AWS submission without reformatting or supplementing it with additional documentation.
Remediation tracking
Finding status is tracked within the platform. If you remediate a critical or high finding and retest before submission, the updated report reflects the resolved status with closure evidence. AWS expects remediation evidence for critical and high findings, and the report provides it in the format reviewers look for.
Compliance report format
Beagle produces reports in branded and white-label formats structured for compliance use cases and third-party submission. The output is formatted as a formal security assessment document, not a raw tool export.
Tester and platform documentation**
The report includes documentation confirming the test was conducted on the Beagle Security platform. This satisfies AWS’s requirement for tester credentials or platform documentation confirming the test was carried out by a recognized party.
Setting up your pen test before the AWS review submission
Confirm your scope as a team before you configure anything
List every domain, subdomain, and API endpoint that is part of your product. This means your main application, any separate admin interfaces, customer-facing APIs, and any endpoints exposed through third-party integrations that your application controls. If a surface exists and authenticated users can reach it, it belongs in scope. Surfaces left out of the test are surfaces AWS may ask about later.
Make sure your test environment reflects production
If you are testing against a staging environment, it needs to match production in terms of features, access control logic, and data handling behavior. A staging environment missing certain user roles, feature flags, or integrations will produce findings that do not accurately represent your real application. If staging diverges significantly from production, test against production with a dedicated test account and test data.
Configure authentication for the test
Create a dedicated test account for each user role your application supports. If your product has admin, standard user, and read-only roles, the test should cover all three. Do not use a real customer account.
Identify all APIs before starting
If you have a GraphQL endpoint, a REST API, or any webhook surface, document these before the test begins. Surfaces that are not in scope at the start may not be picked up automatically.
Build remediation time into your submission timeline
If the test returns critical or high severity findings, AWS expects those to be resolved before you submit. After remediation, retest the affected finding to confirm the fix holds, and make sure your final report shows the finding as resolved with a retest date. A report that lists a critical finding as open, even one you have already fixed, is likely to pause your review.
Submission checklist: what to prepare before your AWS security review
Make sure every item below should is ready and confirmed before your Seller Assurance submission goes in.
| Item | What to confirm | Status |
|---|---|---|
| Completed pen test report | Report covers all domains, subdomains, and API endpoints in scope. Testing period is documented. | |
| Scope statement | Scope names specific surfaces tested, not just the company or product name. AWS infrastructure is noted as excluded per the shared responsibility model. | |
| Testing methodology | Report confirms how the test was conducted and explicitly states that authenticated testing was included. | |
| Severity-classified findings | Every finding carries a severity rating using CVSS or an equivalent recognized framework, mapped to OWASP categories. | |
| Remediation status for critical and high findings | Critical and high findings are marked resolved with retest evidence, or a documented remediation plan with specific dates is included for anything unresolved. | |
| Access control documentation | Covers internal access policies, how customer access is scoped and revoked, and MFA enforcement for privileged accounts. | |
| Data handling and encryption documentation | Covers what customer data is collected, where it is stored, how it is transmitted, and how it is deleted at offboarding. Encryption at rest and in transit is confirmed. | |
| Third-party integration confirmation | Any third-party integrations that touch customer data are identified, and security controls applied to those integrations are documented. | |
| Tester credentials or platform documentation | Report includes certification details for the tester or documentation confirming the test was conducted on a recognized application security testing platform. |
Final thought
The AWS Marketplace security review is not designed to be a barrier. It is designed to confirm that your application has been tested, that findings were acted on, and that you can produce documentation proving both.
Where most teams lose time is not in the testing itself. It is discovered after the fact that their report does not contain what AWS needs, that their scope statement is too vague, or that critical findings were fixed but never retested. Each of those gaps sends the review back to the start.
A pen test that covers your authenticated application layer, produces OWASP and CVSS-mapped findings, tracks remediation status, and outputs a compliance-ready report satisfies the requirement without ambiguity. You do not need weeks of back-and-forth to get a report AWS will accept.
If your listing has a deadline attached, the clock on remediation and retesting is already running. Beagle Security gets you from test to submission-ready report, with the OWASP and CVSS-mapped output AWS expects, without the wait.
Start your 14-day free trial or explore the interactive demo to see it in action.
FAQs
What is the AWS Marketplace security review?
An evaluative process that ensures your product (AMI, container, SaaS, or software) aligns with AWS security best practices, policies, and regulatory requirements before it can be listed on AWS Marketplace.
What happens if I fail the security review?
AWS will provide feedback on failed checks. You must remediate issues (e.g., patch vulnerabilities, fix IAM policies) and resubmit. Repeated failures can delay or block your listing.
How long does the AWS Marketplace security review take?
AWS does not publish a fixed SLA for Seller Assurance reviews. First submissions typically take two to four weeks. Incomplete documentation, open critical findings, or a missing scope statement are the most common reasons reviews take longer. Having everything in order before you submit is the most reliable way to avoid delays.
![Top 10 leading AppSec testing providers[2026]](/blog/images/top-10-leading-appsec-testing-providers-2026-cover.webp "Top 10 leading AppSec testing providers[2026]")
