The AWS Security Agent is a new, AI-powered "frontier agent" that proactively secures applications throughout the entire development lifecycle, offering automated security reviews, on-demand penetration testing, and continuous vulnerability detection from design to deployment, helping developers find and fix issues faster than traditional methods. Sounds interesting? Let’s test it out!
Security Requirements in AWS Security Agent
A central feature of AWS Security Agent is its support for security requirements - formal definitions of the security controls and policies that your applications must satisfy during design reviews, code reviews, and penetration testing.
Security requirements are defined at the organizational level in the AWS Console and apply across all “Agent Spaces” (i.e., workspaces or projects) in your account.
AWS Security Agent offers two main types of security requirements:
- Managed security requirements - provided and maintained by AWS.
- Custom security requirements - defined and maintained by your organization, tailored to your internal policies or unique risk profile.
Managed Security Requirements
Managed security requirements are pre-defined by AWS based on industry standards and best practices; they are ready to use out-of-the-box.
Key aspects
* Ready-to-use controls: As these are provided by AWS, you don’t need to write any definitions yourself before enabling them. This means teams can start applying a baseline set of security standards immediately.
* Easy activation/deactivation: In the AWS Console under Security requirements --> Managed security requirements, you can select one or more rules and Enable or Disable them. Once enabled, they apply to "all new" design and code reviews. Existing reviews remain unaffected.
* Customizable per organization: If the built-in requirement doesn’t match your internal standards exactly, you can "customize" it: the console will duplicate the managed requirement, letting you edit it — then it becomes a custom requirement you control.
Using managed requirements gives organizations a fast and standardized starting point for security compliance, ensuring that at least a baseline of well-recognized security practices is enforced across projects.
Custom Security Requirements
Custom security requirements give organizations the flexibility to define their own security controls - especially useful when you have internal policies, regulatory compliance needs, or specific application contexts not covered by the default AWS-provided controls.
How it works & what you define
When creating a custom requirement (from scratch or based on duplicating a managed one), you define:
* Security requirement name: A clear, descriptive name of the control (max 80 characters).
* Description: A summary of what the security control enforces, and why it matters (max 500 characters).
* Applicability: Which workloads, systems, or contexts the requirement applies to. You can also specify exceptions or conditions to mark the requirement as "NOT_APPLICABLE" in certain cases (max 10,000 characters).
* Compliance criteria: What constitutes compliance vs non-compliance — with as much technical detail, edge cases, configuration examples or code patterns as needed (max 10,000 characters).
* Remediation guidance (optional but recommended): Instructions and examples on how to fix violations — for instance, configuration steps, code changes, or reference to internal standards (max 10,000 characters).
Once defined, you can enable the custom requirement so that AWS Security Agent enforces it automatically in all future design reviews or code reviews.
You can also edit existing custom requirements: update their definitions, compliance criteria, or remediation guidance — and the new definitions take effect on all future reviews.
When to Use Each Type — and Best Practices
- Use managed requirements when you want fast, standardized enforcement of broadly accepted security practices. This is ideal for baseline security hygiene across many projects, without having to define everything manually.* Use custom requirements when your organization has special compliance requirements, internal policies, or application-specific constraints that the managed set doesn’t fully cover.
Best practices when writing custom requirements (also recommended when customizing managed ones):
- Use clear, descriptive names and explanations so that developers and reviewers immediately understand the control's purpose.
- Define applicability carefully, specifying when a control should or should not apply (workload types, regulatory context, edge cases). This helps avoid false positives or irrelevant compliance checks.
- Write precise compliance criteria — clearly separate what is compliant and what is non-compliant. Use concrete technical indicators and avoid vague language.
- Provide remediation guidance or examples, to help developers or architects quickly fix issues flagged by the agent. This makes findings actionable, not just advisory.
Integrations:
You can configure AWS Security Agent to automatically analyze GitHub (Currently only GitHub integration is supported) pull requests in your connected repositories. When enabled, the service reviews code changes against your organization’s security requirements and common vulnerabilities, and it posts findings as comments on pull requests with actionable remediation guidance.
This procedure walks through connecting repositories to an Agent Space, selecting which repositories will use code review, configuring review settings, and activating the capability.
Prerequisites:
Before enabling code review:
Ensure the AWS Security Agent GitHub App is installed and authorized for your GitHub organization or user account.
(Optional) If you plan to validate code against custom security requirements, at least one custom requirement must already be enabled.
Step 1: Access Code Review Configuration
Open your Agent Space in the AWS Security Agent console.
Choose Enable code review from the capabilities menu.
Step 2: Connect Repositories
Select the registered GitHub organization or user account whose repositories you want to connect.
From the list of available repositories, check those you want to connect.
Select User or Organisation, depends on repositories you added
Click Add repositories to connect them to the Agent Space.
Connected repositories will appear in the Agent Space’s repository list.
Note: Code review is currently available only for private repositories.
Now we are done with prerequisites and the next step is to create the Agent space:
And lets open the Agent Space we just created:
And start our testing from Code Review:
And manage Code Review settings:
That's all, now you can create a merge requests and check github comments. The agent will post findings with specific remediation steps
That's all, easy setup. Now lets check more interesting part:
Penetration testing
Go to Agent space you created, penetration test tab:
You can add or Route53 managed domain, it will create DNS records automatically to validate the domain ownership or custom domain and create DNS records manually.
My domain is hosted on Route53, choosing it from the dropdown menu.
After you create DNS records and wait for a few minutes to validate the domain
Once validated - go to "Start in web app" in the top right corner:
In the web application, you need to set your domain:
And you can enable auto remediation to allow it to create a merge with the security fix:
If your website is internal and available only within VPC - you choose your VPC:
And configure credentials if you have some:
Now, I was thinking about application to test. Find some old vulnerable wordpress with a bunch of old plugins ?
I have a better idea! Install "juice shop" application from https://pwning.owasp-juice.shop/companion-guide/latest/index.html
Being a web application with a vast number of intended security vulnerabilities, the OWASP Juice Shop is supposed to be the opposite of a best practice or template application for web developers: It is an awareness, training, demonstration and exercise tool for security risks in modern web applications. The OWASP Juice Shop is an open-source project hosted by the non-profit Open Worldwide Application Security Project® (OWASP) and is developed and maintained by volunteers. The content of this book was written for v19.1.0 of OWASP Juice Shop.
Installation itself is simple:
- create a new EC2 instance
- install nodejs and npm
- git clone https://github.com/juice-shop/juice-shop.git --depth 1
- $ cd juice-shop
- $ npm install
- $ npm start
And its done now. I ran the test 3 times. By some reason it was failing for me 2 first times, without showing any explicit errors
I like the way how it categories all findings:
And summary about the scan:
It managed to discover all pages:
And shows details about findings:
Did it find all of the vulnerabilities? I don't think so, but it was just released and hopefully will be improved
What I miss from the functionality?
- Scheduled runs for penetration testing.
- Better error handling; it was not clear why the penetration test was failing
- Penetration test scanning result notification