Vulnerability Management

Solution providers must implement vulnerability scans at minimum every 30 days, penetration tests yearly, code vulnerability scans prior to release of new code, features, or products, and to ensure they can restore availability and access to personally identifiable information (PII) within hours.

This guide outlines mandatory vulnerability management requirements and implementation guidance such as vulnerability scans, penetration tests, and code vulnerability scans. This guide also explores processes to restore availability and access after a service interruption due to an incident.

Amazon Data Protection Policy (DPP) requirements

The Amazon Data Protection Policy contains two categories related to security requirements:

• Section 1. General Security Requirements, which includes requirements for all solution providers building SP-API applications.
• Section 2. Additional Security Requirements for Personally Identifiable Information (PII), which includes additional requirements for solutions providers performing restricted operations on SP-API that involve personally identifiable information (PII).

To comply with the vulnerability management requirements in the DPP, solutions providers must:

• Create and maintain a plan to detect and resolve vulnerabilities.
• Conduct vulnerability scans every 30 days.
• Conduct penetration tests every 365 days.
• Scan code for vulnerabilities prior to every release.
• Resolve critical-risk vulnerabilities within seven days of discovery.
• Resolve high-risk vulnerabilities within 30 days of discovery.
• Maintain periodic backups, secondary backup sites, backup-and-restore testing documentation, and ensure rapid data restoration capabilities.
• Maintain a geographically separated secondary/backup site.

Vulnerability scans

A vulnerability scan identifies, analyzes, and reports security weaknesses in hosts, networks, and applications.

Solution providers must verify that public facing devices/instances are protected against malicious actors. To identify risks and possible attack vectors within the network, solution providers must run scans with vulnerability scanning tools.

The following is a list of the top ten vulnerabilities, according to the Open Web Application Security Project (OWASP) for 2025 and associated Common Weakness Enumerations (CWE):

For a list of free and paid scanning tools, refer to OWASP – Vulnerability Scanning Tools.

After the scans are complete, solutions providers must prioritize vulnerabilities according to the level of security impact and work to remediate those accordingly.

• External vulnerability scans: External scans are meant to check vulnerabilities in external/public points such as ports, websites, networks, and applications.
• Internal vulnerability scans: Internal scans give visibility on possible security gaps within a private network.
• Intrusive and non-intrusive scans: Non-intrusive scans will scan a specific target, such as network traffic or a database's version, but it does not affect service levels as it only checks the information without taking advantage of the vulnerability. An intrusive scan is meant to exploit the vulnerability at its highest level and provide more insight about the vulnerabilities found, but it also interrupts service levels, so use it in a controlled environment.

Amazon Inspector

Amazon Inspector is a scalable vulnerability management tool which scans workloads and unintended network exposures to verify that there are no vulnerabilities in operating systems running EC2 instances.

Amazon Inspector provides near real-time vulnerability finding reports using updated Common Vulnerabilities and Exposure (CVE) factors and checking different coding languages such as Java, Python, and Node.js. Solutions providers that use Amazon Inspector can use it for compliance validation of programs such as PCI, ISO, and CSA STAR certificates.

Amazon Guard

Amazon’s Security team developed Amazon’s SP-API Guard as an application that runs in AWS instances to check and asses security compliance with Amazon’s DPP. SP-API Guard also provides a recommendation report of any security gap it finds within a day to an S3 bucket. This reduces the effort for manual Data Security Assessments and remediation plan times while providing recommended solutions for vulnerabilities found.

Penetration testing

Penetration testing (pen testing) is a way to check in a simulated/controlled environment for any vulnerabilities in different points of applications or networks. This is done to confirm which vulnerabilities can be exploited by bad actors. Solution providers must conduct penetration testing every 365 days.

Pen testing consists of the following stages:

• Planning Stage: The team sets goals and the scope for the testers' pen tests. All parties must be aware of the upcoming tests.
• Scan/Discovery Stage: Pen testers initiate the process of network recognition and code inspection.
• Penetration Stage: The pen tester attempts to gain access to the network/instances using different types of attacks such as SQL injection, cross-site scripting, and back doors to exploit vulnerabilities.
• Analysis/Report Stage: The pen tester creates a report with detailed information about actions taken to penetrate network security and the vulnerabilities found. The pen tester must include a recommended actions section in the report.
• Remediation/Clean up Stage: The responsible team takes the lead and starts work on remediating vulnerabilities reported after the pen tests are completed.

After the remediation stage, solutions providers must run a second pen test to validate that all identified vulnerabilities have been completely remediated.

To learn more about how to apply pen tests at an application level and for network components such as firewalls and ports, refer to the OWASP ZAP penetration test guide.

Code vulnerability scans

Mandatory code vulnerability scanning requirements help mitigate security risks when a new feature or product is being released. To ensure that there are no errors, technical issues, or security gaps when code is deployed, solution providers must conduct code vulnerability scans prior to every release.

The following is a list of code scanning tools:

• Static Application Security Test (SAST): Review of the code without having to run the code. SAST checks how the code is written to point out any security issues in it.
• Dynamic Application Security Test (DAST): In contrast to SAST, DAST checks the code in a running application by simulating attacks with malicious payload injections. DAST helps solutions providers to identify vulnerabilities within a running application.
• Interactive Application Test (IAST): IAST checks application functionalities across testing environments. This facilitates implementation and scalability as it helps to reduce possible downtime or service interruptions by tackling vulnerabilities prior to release.

These tools must follow the standards given by OWASP to check the application security against the top ten security risks. Solutions providers must scan code prior to release to identify, classify, and prioritize any security flaws that could affect or interrupt service.

Disaster recovery plan

To ensure that application users are not affected by incidents (technical or physical), solutions providers must develop remediation procedures on how to restore availability and access to PII data. These procedures must take into consideration Recovery Time Objective (RTO) and Recovery Point Objective (RPO). For more guidance, refer to Establishing RTO and RPO Targets for Cloud Applications.

The following are definitions of RTO and RPO:

• Recovery Time Objective (RTO): The time it takes the solutions providers to restore normal service levels to application users. This can be accomplished by having redundancy within network instances/services that are critical for the application's functionality.
• Recovery Point Objective (RPO): The point in time where solutions providers can restore the data, in other words, the maximum acceptable data loss threshold during and after an incident. A fundamental aspect of this objective is to have one or more backups of the data in different locations, and perform those backups twice a week if possible.

Solutions providers are expected to use recovery strategies and test them to meet objectives (RTO and RPO). AWS Resilience Hub is an AWS service that helps to establish RTO and RPO targets, and it analyzes applications against those targets.

Key takeaways and next steps

• Implement vulnerability scans every 30 days, annual penetration tests, and code scans before each release to meet DPP compliance requirements.
• Address critical-risk vulnerabilities within 7 days and high-risk vulnerabilities within 30 days of discovery to minimize security exposure.
• Leverage Amazon security tools, such as Amazon Inspector and Amazon Guard.
• Create and test procedures to restore PII access within hours, including maintaining geographically separated backup sites for business continuity.
• Take the Amazon Data Protection Policy (DPP) Compliance Self-Check Assessment to evaluate your compliance status.
• Keep detailed records of all vulnerability assessments, remediation actions, and security incidents to demonstrate ongoing DPP compliance during audits.

Notices

Amazon sellers and Solution providers are responsible for making their own independent assessment of the information in this document. This document: (a) is for informational purposes only, (b) represents current practices, which are subject to change without notice, and (c) does not create any commitments or assurances from Amazon.com Services LLC (Amazon) and its affiliates, suppliers, or licensors. Amazon Selling Partner API (Amazon SP-API) products or services are provided "as is" without warranties, representations, or conditions of any kind, whether express or implied. The responsibilities and liabilities of Amazon regarding SP-API are controlled by Amazon's SP-API agreements (including the Amazon Selling Partner API Developer Agreement or the Amazon Selling Partner API License Agreement), and this document is not part of, nor does it modify, any agreement between Amazon and any party.