# Create a penetration test
Set up automated penetration testing for your web applications by configuring test scope, target domains, and AWS resource access. Penetration tests help identify security vulnerabilities in running applications by simulating real-world attack scenarios against your verified domains.
AWS Security Agent performs comprehensive security testing against your web applications based on configured scope and permissions, providing detailed findings about exploitable vulnerabilities before attackers can discover them.
In this procedure, you’ll create a penetration test by configuring test details, defining the test scope, and setting up required permissions.
## Prerequisites
Before you begin, ensure you have:
+ Access to the AWS Security Agent web application
+ At least one verified domain for testing
+ IAM role with appropriate permissions for AWS Security Agent
+ Understanding of your application’s architecture and critical paths
## Start creating a penetration test
Navigate to the penetration test creation page in the Agent Web App.
1. Log in to the AWS Security Agent web application.
1. Navigate to the **Penetration tests** section.
1. Click **Create a penetration test**.
**Tip**
Only verified domains can be included in penetration tests. Ask your admin to verify the domain in AWS management console. See [Enable an application domain for penetration testing](enable-test-domain.md).
## Name your penetration test
Provide a descriptive name that helps identify the purpose and scope of this penetration test.
1. In the **Penetration test name** field, enter a descriptive name for your penetration test.
**Example**
The name should clearly identify the application, environment, or component being tested. Maximum 100 characters.
## Configure penetration test scope
Define which domains and URL paths will be tested, and configure optional exclusions to control test boundaries.
### Add target domains
Specify the verified domains that will be actively tested for security vulnerabilities.
1. In the **Penetration test scope** section, locate **Target URLs**.
1. Expand the **Verified domains** section to view available domains.
1. Click in the **Target URL** field and enter a target domain URL.
**Important**
Only verified domains can be tested. The URL must match a domain you’ve previously verified in AWS Security Agent.
1. To add multiple target domains:
1. Click **Add domain**.
1. Enter each additional domain URL.
1. To remove a target domain, click **Remove** next to the domain URL.
**Tip**
For best results, include all domains that are part of your application’s user flow, including subdomains for APIs, authentication services, and content delivery.
### Exclude risk types (optional)
Choose specific risk categories to exclude from testing if they’re not applicable to your application.
1. Locate the **Exclude risk types** field.
1. Click the dropdown to view available risk types.
1. Select one or more risk types to exclude from the penetration test.
**Note**
Excluding risk types limits the scope of testing. Only exclude risk types that are not relevant to your application or that you want to test separately.
### Add out-of-scope URL paths (optional)
Specify URL paths that should not be tested during the penetration test.
1. Locate the **Out-of-scope URLs** section.
1. Click in the input field and enter a URL path to exclude (for example, `/admin/delete` or `/api/reset`).
1. To add multiple out-of-scope paths:
1. Click **Add URL**.
1. Enter each additional path.
1. To remove a path, click **Remove** next to the path.
**Warning**
Out-of-scope paths will not be tested for vulnerabilities. Ensure you only exclude paths that should not be accessed during testing, such as destructive operations or sensitive administrative functions.
### Add accessible domains (optional)
Specify domains that are required for the test but are not targets for vulnerability testing.
1. Locate the **Accessible URLs** section.
1. Click in the input field and enter a domain that should be accessible during testing.
**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.
1. To add multiple accessible domains:
1. Click **Add URL**.
1. Enter each additional domain.
1. To remove a domain, click **Remove** next to the domain.
## Configure IAM Role
Select the pre-configured service role for this penetration test. AWS Security Agent uses an Agent Space-based permission model where administrators configure IAM roles when setting up your Agent Space. You’ll select from roles that are already configured and ready to use.
1. In the **Permissions** section, locate the **Service roles** dropdown.
1. Select the IAM role that grants AWS Security Agent access to required AWS resources.
**Important**
The selected IAM role must have permissions to access VPC resources, CloudWatch Logs, and any other AWS services needed for the penetration test. Verify that the role has the correct trust relationship with AWS Security Agent.
1. Locate the **CloudWatch log group** dropdown.
1. Select the log group where penetration test logs will be stored. (optional)
**Note**
The selected CloudWatch log group will store detailed logs of the penetration test execution, including requests made, responses received, and vulnerabilities discovered.
If you don’t select a log group, a new CloudWatch log group will be automatically created with the `/aws/securityagent` prefix to store the penetration test logs.
## Automatic code remediation
Select the **Enable automatic remediation** checkbox.
**Important**
To remediate security findings in your source code repositories, AWS Security Agent may submit pull requests to your repositories. The pull requests may be visible to all users who have read access to the repositories.
## Configure VPC resources (optional)
If your target domains are private and hosted within a VPC, configure the VPC settings where AWS Security Agent should run penetration tests. This step is only necessary for applications that are not publicly accessible.
**Note**
Skip this step if your target domains are publicly accessible. VPC configuration is only required for testing private applications hosted within an Amazon Virtual Private Cloud.
Choose the VPC, subnets, and security groups for the penetration test environment.
1. In the **VPC** section, locate the **VPC ID** dropdown.
1. Select the VPC where your target domains are hosted.
**Important**
The selected VPC must contain the target domains you specified in Step 3. Ensure the VPC has appropriate routing and network configuration to allow AWS Security Agent to access your applications.
1. Locate the **Subnets** dropdown.
1. Select one or more subnets where the penetration test should run.
**Note**
Choose subnets that have network access to your target applications. The penetration test will execute from resources deployed in these subnets.
1. Locate the **Security group** dropdown.
1. Select the security group that controls network access for the penetration test.
**Important**
The selected security group must allow outbound traffic to your target domains and any accessible domains. Ensure the security group rules permit the necessary network access for comprehensive testing.
## Configure authentication credentials (optional)
If your target domains require authentication, provide credentials to allow AWS Security Agent to access protected areas of your application during penetration testing. This step is only necessary for applications that require user authentication.
**Note**
Skip this step if your target domains do not require authentication or if all areas you want tested are publicly accessible. Configure credentials only when you need AWS Security Agent to test authenticated sections of your application.
### Add credentials
Provide authentication credentials that AWS Security Agent will use to access your application.
1. In the **Credential \$11** section, select a credential input method:
+ **Input credentials** - Enter your credentials directly into AWS Security Agent.
+ **Advanced setting** - For sensitive credential information, use advanced options such as AWS Secrets Manager or AWS Lambda functions. See [Provide authentication credentials for penetration testing](provide-testing-credentials.md) for details.
**Tip**
For production environments or sensitive credentials, we recommend using the advanced setting option to securely reference credentials stored in AWS Secrets Manager or Systems Manager Parameter Store.
### Enter credential details
Provide the username and password for the authenticated account.
1. In the **User name** field, enter the username for authentication.
1. In the **Password** field, enter the password for authentication.
**Important**
Ensure the credentials you provide have appropriate access levels for the areas you want tested. The credentials should represent a typical user’s access level rather than administrative privileges.
### Select access domain
Specify which target domain will use these credentials for authentication.
1. In the **Access domain** dropdown, select the domain where these credentials will be used.
**Note**
If you have multiple target domains that require different credentials, you can add additional credential sets by clicking **Add another credential** after completing this credential configuration.
### Configure agent login prompt (optional)
Provide instructions to guide AWS Security Agent through your application’s authentication process.
1. Expand the **Agent login prompt** section if your authentication flow requires specific instructions.
1. Enter detailed instructions describing how to access your application using the provided credentials.
**Note**
The agent login prompt is useful for complex authentication flows, multi-step login processes, or applications with non-standard login procedures. Include step-by-step instructions such as "Navigate to /login, enter username in the 'Email' field, enter password, and click 'Sign In'."
### Add multiple credentials (optional)
If your application requires multiple sets of credentials or different domains need separate authentication, add additional credential sets.
1. After completing the first credential configuration, click **Add another credential**.
1. Repeat the credential configuration steps for each additional credential set.
1. To remove a credential set, click **Remove** next to the credential header.
**Tip**
Configure multiple credentials when testing different user roles, accessing multiple authenticated domains, or verifying role-based access controls in your application.
## Attach additional resources (optional)
Provide supplementary resources to help AWS Security Agent conduct more thorough and accurate penetration testing. Additional resources can include architecture diagrams, API documentation, configuration files, GitHub repositories, or S3-hosted materials that give context about your application.
**Note**
Additional resources are optional but recommended. Providing comprehensive information about your application helps ensure thorough test coverage, reduces false positives, and delivers more actionable results.
### Add resources to the penetration test
Select existing resources or upload new files that will help guide the penetration test.
1. In the **Connected resources** section, you can:
+ Click **Select from available** to choose from resources already connected to AWS Security Agent (such as GitHub repositories or S3 buckets).
+ Click **Upload** to add new files directly from your local system.
**Tip**
Useful resources include API documentation, architecture diagrams, OpenAPI/Swagger specifications, configuration files, authentication flow diagrams, and any other materials that describe your application’s structure and behavior.
### Select from available resources
Choose from resources that are already integrated with AWS Security Agent.
1. Click **Select from existing resources**.
1. Browse the list of available resources from connected sources such as:
+ GitHub repositories, under the **GitHub repositories tab**
+ S3 buckets
+ Previously uploaded files
+ Documentation repositories
1. Select the resources you want to include in the penetration test.
1. Click **Add to penetration test** to attach the selected resources.
**Example**
We recommend selecting and adding relevant GitHub repositories to your pentest, so AWS Security Agent can develop an understanding of your application context, and generate ready-to-implement code fixes through pull requests (when enabled)
**Note**
Resources selected from available sources remain synchronized with their original location. If you update a GitHub repository or S3 file, the penetration test will use the updated version.
### Upload new resources
Upload files directly from your local system or provide plain text content to AWS Security Agent.
1. Click **Upload**.
1. Choose one of the following input methods:
+ **Upload local files** - Select one or more files from your local system.
+ **Paste plain text** - Type or paste text content directly into the input field. Click **Upload**.
1. Then click **Add** to complete uploading.
1. The uploaded resources will appear in the **Connected resources** table.
**Tip**
Use the plain text option when you want to quickly provide API endpoint lists, URL patterns, test instructions, or other text-based information without creating a separate file.
**Important**
Ensure uploaded files and pasted content do not contain sensitive information such as production credentials, private keys, or personally identifiable information (PII). Use sanitized versions of configuration files and documentation.
### Connect existing resources
Existing resources can be from what you’ve previously uploaded to AWS Security Agent, from your S3 bucket, and your integrated GitHub repositories. Click **Select from existing resources** to select them.
### Manage connected resources
Review, organize, and remove resources attached to the penetration test.
The **Connected resources** table displays all resources included in the penetration test with the following information:
+ **Name** - The filename or resource identifier
+ **Type** - The resource category (Uploaded files, S3 resources, GitHub repositories, etc.)
To manage resources:
1. Select one or more resources using the checkboxes.
1. Click **Remove from penetration test** to detach selected resources.
**Note**
You can sort the table by Name or Type by clicking the column headers. This helps organize resources when working with many files.
## Create the penetration test
Finalize and launch your penetration test configuration.
After configuring all settings, you’re ready to create the penetration test.
1. Review all configuration sections to ensure accuracy.
1. Choose one of the following options:
+ Click **Create penetration** to save the configuration without running it immediately.
+ Click **Create and execute** to save the configuration and immediately start the penetration test.
+ Click **Cancel** to discard the penetration test configuration.
**Important**
Before running a penetration test, verify that:
All target domains are correctly verified and accessible
IAM roles have appropriate permissions
Out-of-scope paths are properly configured to prevent testing destructive operations
You have authorization to perform security testing on all target domains
**Note**
After the penetration test starts, you can monitor its progress from the **Penetration test runs** section. The test may take several hours depending on the scope and complexity of your application.
# Review findings from a penetration test
Monitor pentest execution in real time on the Penetration Test Logs page after AWS Security Agent starts a pentest. AWS Security Agent logs every action during the pentest. After completion, review the pentest summary, which includes application overview, coverage with identified endpoints, and risk assessment of security findings.
Evaluate security findings to address application vulnerabilities. Each finding contains impact assessment, severity rating, supporting evidence and remediation pull request details (when automatic code remediation is enabled).
## Prerequisites
Before you begin, ensure you have:
+ A completed or in-progress penetration test run
+ Access to the AWS Security Agent web application
## Step 1: Access the penetration test run
Navigate to your penetration test run to view overview, logs and findings pages.
1. Log in to the AWS Security Agent web application.
1. Navigate to the **Penetration tests** section.
1. Select the penetration test run you want to examine from the list.
**Tip**
The penetration test details page displays a summary of test status, completion date, and the number of findings identified.
## Step 2: Monitor test progress
Track the progress of your penetration test run using the step indicator at the top of the page.
1. Locate the horizontal step indicator below the page header.
1. Review the status of each testing phase:
+ **Preflight** – Initial setup and connectivity checks
+ **Static analysis** – Code and configuration analysis
+ **Pentests** – Runtime testing and vulnerability scanning
+ **Finalizing** – Final validation and report generation
**Note**
Each step displays a status indicator (Complete, In progress, or Pending). Findings are discovered and validated throughout the testing process, with new vulnerabilities appearing as each phase completes.
## Step 3: Navigate to the penetration test run overview tab
1. Run Summary section provides test status, duration and other high level details. It also provides a dashboard of security findings categorized by severity level and risk-types
1. Application overview by AWS Security Agent provides a summary of the penetration test run
1. Discovered endpoints by AWS Security Agent provides a list of all endpoints discovered and tested by the AWS Security agent during the pentest run
## Step 4: Navigate to the penetration test logs tab
Access detailed logs of all actions AWS Security Agent executed during the pentest.
1. The actions are categorized by action type and risk-types.
1. Click on a specific action to view detailed logs:
+ **Testing Summary** – High-level summary of the agent actions and results
+ **Penetration test logs** – Detailed logs of all testing activities
**Note**
Validator actions provide logs that validate findings in each category
**Note**
The Findings tab displays a split view with the findings list on the left and selected finding details on the right.
## Step 5: Navigate to the findings
Each finding in the list displays key information to help you quickly assess its importance.
**Note**
Findings with Low agent confidence and False Positives are hidden by default. You can view them by disabling the toggle **Hide False Positives**.
Review the information displayed on each finding card:
+ **Finding name** – The title and identifier for the vulnerability
+ **Confidence badge** – Indicates the agent’s confidence level in the finding (High, Medium, or Low)
+ **Severity badge** – Shows the risk level with color coding:
+ **Critical** (red) – Requires immediate action; exploitation could lead to system compromise
+ **High** (red) – Requires prompt attention; exploitation could result in significant security impact
+ **Medium** (orange) – Should be addressed in a reasonable timeframe; contributes to overall security risk
+ **Low** (yellow) – Can be addressed as part of regular maintenance; minimal immediate risk
+ **Informational** (blue) – For informational purposes; minimal to no immediate risk
+ **Last update timestamp** – Shows when the finding was last modified or validated
+ **Description preview** – Brief summary of the vulnerability
**Important**
Prioritize findings with **Critical** or **High** severity badges and **High** confidence levels, as these represent validated vulnerabilities requiring immediate remediation.
## Step 6: Review finding details
Select individual findings to view comprehensive information about each vulnerability.
1. Click on a finding name in the left panel to display its details in the right panel.
1. Review the validation status at the top of the details panel:
**Note**
If a finding displays the Unknown "This finding is not validated by AWS Security Agent yet," it means the vulnerability detection is still being confirmed. These findings may require manual verification.
1. Review the key attributes displayed at the top:
+ **Agent confidence** – The confidence level AWS Security Agent has in this finding
+ **Severity** – The risk level with a color-coded badge
+ **Finding logs** – Click "Trace actions & logs" to view detailed execution logs and evidence
+ **Risk type** – The category or type of security risk (e.g., Authentication Bypass, SQL Injection)
1. Expand the **Description** section to read:
+ A detailed explanation of the vulnerability
+ How the vulnerability works
+ Why it represents a security risk
+ The potential impact on your application
1. Expand the **Risk Reasoning** section to understand the severity calculation:
+ CVSS (Common Vulnerability Scoring System) metrics breakdown
+ Attack Vector (AV) – How the vulnerability can be exploited
+ Attack Complexity (AC) – How difficult the exploit is
+ Privileges Required (PR) – What access level is needed
+ User Interaction (UI) – Whether user action is required
+ Scope (S) – Whether the vulnerability affects other components
+ Confidentiality, Integrity, and Availability impacts
1. Expand the **Steps to reproduce** section to view:
+ Detailed technical steps to recreate the vulnerability
+ Request and response examples
+ Specific parameters or conditions that trigger the issue
**Tip**
Use the "Trace actions & logs" link to access the complete evidence package, including HTTP requests, responses, and exploitation attempts that demonstrate the vulnerability.
## Step 7: Interpret CVSS metrics
Understanding CVSS metrics helps you assess the true severity and prioritize remediation efforts.
When reviewing the **Reasoning** section, pay attention to these key metrics:
+ **Attack Vector (Network/Adjacent/Local/Physical)** – Indicates how remotely the attack can be executed
+ **Attack Complexity (Low/High)** – Shows whether specialized conditions are required to exploit
+ **Privileges Required (None/Low/High)** – Identifies what access level an attacker needs
+ **User Interaction (None/Required)** – Determines if the exploit needs user involvement
+ **Confidentiality/Integrity/Availability Impact (None/Low/High)** – Measures the impact on your system’s security
**Important**
Findings with Network attack vector, Low complexity, and High confidentiality/integrity impact represent the most dangerous vulnerabilities requiring immediate attention.
## Step 8: Prioritize and address findings
Take action on findings to remediate vulnerabilities and improve your application’s security posture.
For **Critical** and **High** severity findings with **High** confidence:
1. Review the Description and Steps to reproduce sections thoroughly.
1. Access the detailed logs via the "Trace actions & logs" link to gather complete evidence.
1. Access ready-to-implement code fixes through one of these methods:
+ For automatic remediation: Use the pull request link in the remediation section
+ For manual requests: Click 'Remediation Code' on the findings page to request a pull request **Prerequisites:**
+ Admin must enable code remediation for GitHub repositories in the AWS Security Agent console
+ Repositories must be included in your pentest configuration
1. Plan for a follow-up penetration test to verify the fix is effective.
For **Medium** and **Low** severity findings:
1. Prioritize based on your risk tolerance and business context.
1. Include remediation tasks in your regular development sprint planning.
1. Consider whether multiple low-severity findings together create higher risk.
1. Document any accepted risks with appropriate justification.
**Important**
Do not ignore low-severity findings. Multiple low-severity vulnerabilities can often be chained together to create more serious exploits, especially when combined with social engineering or physical access.
## Step 9: Track remediation progress
Use the findings interface to track which vulnerabilities have been addressed and which require further action.
1. As you work on remediation, refer back to the Steps to reproduce section to verify your fixes.
1. Document your remediation approach for each finding for future reference and compliance audits.
**Tip**
Maintain a remediation log that maps each finding to its resolution, including the code changes, configuration updates, or architectural decisions made to address the vulnerability.
## Next steps
After reviewing your penetration test findings:
+ Prioritize critical and high-severity findings with high confidence for immediate remediation
+ Create tracking tickets in your issue management system with links to finding details and evidence
+ Implement fixes and security controls to address identified vulnerabilities
+ Monitor the penetration test run progress indicator for newly discovered vulnerabilities
+ Schedule a follow-up penetration test to verify that vulnerabilities have been properly remediated
+ Update your application security testing process and threat model based on findings
+ Review CVSS metrics to understand your application’s overall security posture
For more information about performing penetration tests, see [Create a penetration test](perform-penetration-test.md).
For more information about understanding the Security Agent lifecycle, see [Understand the resource hierarchy and lifecycle](understand-lifecycle.md).
# Provide authentication credentials for penetration testing
Provide credentials to enable AWS Security Agent to test authenticated areas of your web applications. Without credentials, the agent can only test publicly accessible pages and APIs.
## Configure authentication credentials
1. In the penetration test creation workflow, locate the **Authentication credentials - Optional** section.
1. In the **Credential \$11** section, choose your credential input method:
+ **Input credentials** - Enter credentials directly. Best for development and testing environments.
+ **Advanced setting** - Use AWS-native credential management. Recommended for production environments and sensitive credentials.
### Advanced options
If you select **Advanced setting**, you can choose from three credential strategies:
+ **IAM role assumption** - For applications using AWS Cognito or IAM authentication
+ **AWS Secrets Manager** - For secure credential storage with encryption and rotation
+ **Lambda function** - For dynamic credential generation or complex authentication flows
## Input credentials directly
1. Select **Input credentials**.
1. Enter the **User name** and **Password**.
1. In the **Access URL** dropdown, select the URL where these credentials will be used. This must be selected from the list of target endpoints.
1. (Optional) In the **2FA - optional** field, provide a TOTP secret for applications that require two-factor authentication. You can either:
+ Enter the TOTP secret directly (for example, `JBSWY3DPEHPK3PXP`), or enter the full `otpauth://totp/` URI (for example, `otpauth://totp/Example:user@example.com?secret=JBSWY3DPEHPK3PXP&issuer=Example`).
+ Click the upload icon to upload a QR code image from your authenticator app setup page. The QR code is scanned locally and the TOTP URI is extracted automatically.
When a TOTP secret is provided, the agent automatically generates fresh one-time codes and enters them when a 2FA prompt is detected during login.
1. (Optional) Expand **Agent Space login prompt** to provide specific login instructions if your application has a complex authentication flow.
**Important**
Use test accounts with representative access rather than personal or administrative accounts.
## Use advanced setting
1. Select **Advanced setting**.
1. In the **User access strategy** dropdown, choose one of the following:
### Select available IAM role for agent to assume
Use this option for applications using AWS Cognito, API Gateway with IAM authentication, or other AWS-native authentication systems. The IAM role must have a trust relationship allowing AWS Security Agent to assume it and permissions to access your application’s authentication system.
### Select static credential from connected AWS Secrets Manager
Use this option to retrieve credentials securely from AWS Secrets Manager with encryption, rotation, and access auditing.
The IAM role must have `secretsmanager:GetSecretValue` and `secretsmanager:DescribeSecret` permissions.
Use the **Agent Space login prompt** to provide detailed instructions on how to interpret and use the credentials stored in the secret. You may use any format to store your secret, as the agent will dynamically interpret the format using these instructions.
For example, if the agent is to submit a username/password login form at https://example.com/login, you may format your secret as JSON with `username` and `password` fields. If the application requires TOTP-based 2FA, include a `totpSecret` field with either the TOTP secret directly or a full `otpauth://totp/` URI:
```
{
"username": "test-user",
"password": "secure-password-here",
"totpSecret": "JBSWY3DPEHPK3PXP"
}
```
Then, configure the authentication instructions: . Set **Access URL** to `https://example.com` (or any other URL selected from the list of target endpoints). . Enter the following into **Agent Space login prompt**: "Navigate to https://example.com/login and enter the provided username and password into the form."
As another example, if you instead have an API key to be provided in an HTTP header, you may store it as plaintext:
```
"api-key-here"
```
Then, configure the authentication instructions: . Enter the following into **Agent Space login prompt**: "Set the X-API-Key header to the provided API key for all requests."
**Important**
Only TOTP-based 2FA is supported. SMS, email, push notifications, hardware keys, and OAuth authentication are not supported.
### Select available Lambda function to retrieve credentials dynamically
Use this option for complex authentication systems, dynamic credential generation, or integration with external identity providers.
The IAM role must have `lambda:InvokeFunction` permissions and the function must complete within 30 seconds.
Like with Secrets Manager, the agent will dynamically interpret your Lambda function’s output using any login instructions provided in the **Agent Space login prompt**. Refer to [Select static credential from connected AWS Secrets Manager](#provide-testing-credentials-secrets-manager) for examples of how to format the output of your Lambda function and supported authentication types.
## Configure multiple credentials
To test different user roles or authentication systems:
1. Click **Add another credential**.
1. Configure the additional credential using either input method.
1. To remove a credential, click **Remove** in the credential section.
# Remediate a penetration test finding
When viewing the findings for a penetration test, you can request AWS Security Agent attempt to remediate a finding. For private GitHub repositories, AWS Security Agent opens a pull request with the proposed fix. For public repositories, the remediation is available as a downloadable diff file that you can apply locally.
You must enable finding remediation in the AWS Management Console. (See [Enable users to start remediation of penetration test findings](enable-remediate-findings.md).) Users can start remediation for a specific finding from the AWS Security Agent Web App.
## Prerequisites
Before you begin, ensure you have:
+ A completed or in-progress penetration test run
+ Access to the AWS Security Agent web application
+ Familiarity with your application’s architecture and security requirements
## Step 1: Enable or disable automatic remediation
You can configure code remediation options when you create or modify a penetration test. If you enable automatic remediation, AWS Security Agent will automatically attempt to remediate the associated GitHub repositories if the Agent confirms a finding during the pentest. You can also manually start code remediation. . In the view to edit **Penetration test details**, in the **Automatic code remediation** section, enable or disable code remediation.
## Step 2: Select repositories for code remediation
1. Click **Next** all the way to the last step **Additional learning resources**.
1. Choose **Select from resources**.
1. Choose **GitHub repositories**.
1. Select the repositories that you want for code remediation.
1. Save the penetration test.
1. You can see the successfully associated repositories under the **Penetration test learning resources** tab.
## Step 3: Start a penetration test and view findings
Run the penetration test to detect findings. For more information, see [Review findings from a penetration test](review-penetration-findings.md).
## Step 4: Start and view code remediation
1. Navigate to the finding.
1. If you’ve enabled automatic code remediation, a code remediation will be started once AWS Security Agent confirms a finding.
1. If you want to manually start a code remediation, click the **Remediate code** button.
1. In the **Code Remediation** section of the finding, you can view the code remediation status and links to the pull requests. If the GitHub repository is public, the code remediation is available as a downloadable file instead of a pull request. You can run `git apply /path/to/code_remediation_changes.diff` to apply the change to your repository locally.