AWS securityagent documentation change
Summary
Restructured domain verification steps with detailed instructions for Route 53 and external DNS providers, added explicit verification methods (DNS_TXT/HTTP_ROUTE), and emphasized accessible domains for third-party services
Security assessment
Improves documentation of security controls (domain verification) but does not indicate a response to a specific vulnerability. The changes enhance clarity about security best practices for penetration testing setup.
Diff
diff --git a/securityagent/latest/userguide/quickstart.md b/securityagent/latest/userguide/quickstart.md index 5b9f4fca3..33147f1de 100644 --- a//securityagent/latest/userguide/quickstart.md +++ b//securityagent/latest/userguide/quickstart.md @@ -48 +48 @@ In the AWS console, you define the scope of what can be tested. Users then run s - 3. Specify the target domains. The target domain should be live, and host the application you want to penetration test. You will need to verify ownership of the target domains once you complete the pentest setup. + 3. **Step 1 — Configure domain** : Enter the target domain you want to test and select a verification method (**DNS_TXT** or **HTTP_ROUTE**). The domain should be live and host the application you want to penetration test. Choose **Next** to proceed. @@ -50 +50 @@ In the AWS console, you define the scope of what can be tested. Users then run s - * AWS Security Agent can only test validated domains. + 4. **Step 2 — Verify domains** : Verify ownership of each domain in the **Target domains** table: @@ -52 +52 @@ In the AWS console, you define the scope of what can be tested. Users then run s - * Domains registered in Route 53 are validated automatically. + * For Route 53 domains in the same AWS account: select the domain and choose **One-click verification**. AWS Security Agent creates the DNS record and completes verification automatically. @@ -54 +54 @@ In the AWS console, you define the scope of what can be tested. Users then run s - * For domains outside Route 53, manually validate them using a `TXT` record. + * For other DNS providers: copy the verification token, add the TXT record with your DNS registrar, then select the domain and choose **Verify**. @@ -56 +56,3 @@ In the AWS console, you define the scope of what can be tested. Users then run s - 4. Select the default role with the necessary permissions policies. You can also optionally customize the role AWS Security Agent will use to interact with AWS Services. However, AWS Security agent recommends using the default role. + * AWS Security Agent can only run penetration tests against verified domains. + + 5. **Step 3 — Configure additional capabilities (optional)** : Configure optional resources such as VPCs, CloudWatch logs, and credentials. The **Service access** section is pre-configured — AWS Security Agent automatically creates a service role with the required permissions unless you want to use an existing IAM role. @@ -110 +112,5 @@ You can create and run a penetration test only in the AWS Security Agent web app - 2. If your application needs to access URLs that are outside of your target domain, add them to the **Accessible URLs** field. This includes third-party services such as Okta, Auth0, or Stripe that are required for login and navigation during testing. NOTE: AWS Security Agent does NOT penetration test accessible URLs—they are used solely for access purposes. Add all third-party domains that your application depends on to ensure proper testing coverage of your target domain. + 2. If your application needs to access URLs that are outside of your target domain, add them to the **Accessible URLs** field. + +###### Note + +Add accessible domains for third-party services (such as Okta, Auth0, Stripe) that are outside your target domain. This is required so AWS Security Agent can access these URLs for login and navigation during testing. AWS Security Agent does NOT penetration test these domains—they are used solely for access purposes.