DEV Community

Agustin De Mozzi
Agustin De Mozzi

Posted on Originally published at Medium on

How to Use AWS Security Agent as a Free Vulnerability Scanner for Your Project

#cybersecurity #amazonwebservices #devsecops #vulnerability


AWS Security Agent

If you’re building a side project or an early-stage startup, security is probably not at the top of your priority list. You’re focused on shipping features, fixing bugs, and getting users. But vulnerabilities don’t care about your roadmap.

The good news is that AWS Security Agent offers code review and custom security requirements at no cost. You get up to 1,000 PR code reviews per month and 20 custom security requirements per account — more than enough for any personal project or small team. The agent automatically scans every pull request against your security rules and posts findings directly as PR comments.

In this tutorial, I’ll walk you through how to set it up and, more importantly, how to write custom security requirements tailored to your specific project. We’ll use a Node.js e-commerce application as an example.

What You’ll Get

  • Automated security scanning on every pull request (up to 1,000/month)
  • Custom security rules that match your project’s specific needs (up to 20 per account)
  • Findings posted directly as comments in your PRs
  • Zero cost for code review capabilities (see FAQ)

Prerequisites

Before we start, make sure you have:

  • An AWS account  — If you don’t have one, create a free AWS account here. You’ll need a valid credit card for verification, but you won’t be charged for the code review features we’ll use in this tutorial.
  • A GitHub or Bitbucket Cloud account with at least one repository you want to scan.
  • Admin access to your GitHub organization (or user account ownership)

Step 1: Create an Agent Space

An Agent Space is a dedicated workspace where AWS Security Agent organizes all security assessments for a specific application. Think of it as a container for your project’s security configuration, reviews, and findings.

  1. Sign in to the AWS Console and navigate to AWS Security Agent.
  2. Go to the Agent Spaces page.
  3. Click Create Agent Space.
  4. Enter a name that identifies your project (e.g., “ecommerce-space”).
  5. Optionally add a description like “Node.js e-commerce application — payment processing and user management”.
  6. Click Create.


Agent space creation

For more details, see the official documentation on creating an Agent Space.

Step 2: Connect Your Repository

Once your Agent Space is ready, connect it to your code repository so the agent can scan your pull requests. In this example we’ll use GitHub, but AWS Security Agent also supports Bitbucket Cloud, GitLab, and GitHub Enterprise Server — see the full integrations documentation for other providers.

  1. In the AWS Security Agent console, navigate to Integrations.
  2. Click Add integration and select GitHub.
  3. Click Open AWS Security Agent in GitHub  — you’ll be redirected to GitHub.
  4. Select the organization or user account where your repository lives.
  5. Choose which repositories AWS Security Agent can access (you can grant access to all repos or select specific ones).
  6. Click Install and authorize in GitHub.
  7. Back in the AWS Console, enter a Registration name (e.g., “ecommerce_repo”), select the account type, and click Connect.

After connecting, navigate to your Agent Space, enable code review for the connected repositories, and you’re set. Every new PR will be automatically scanned.

For the full step-by-step guide, see Connect AWS Security Agent to GitHub repositories.

Step 3: Understand the Managed Security Packs

Before writing custom requirements, it’s worth knowing that AWS Security Agent already comes with managed security requirement packs based on industry standards and best practices. These are enabled with a single click and cover common vulnerabilities out of the box.

You should enable the managed packs that are relevant to your project as a baseline. They’re maintained by AWS and updated automatically.


Managed Security Requirements Packs

The custom requirements we’ll create next are meant to complement these packs with rules that are specific to your business logic — things that a generic security scanner would never catch.

Step 4: Create a Custom Security Requirement

Custom security requirements let you teach AWS Security Agent what matters specifically for your project — the business logic that generic scanners can’t know about. You have 20 slots, so use them wisely.

Before jumping into the console, let’s think about what to write and how to write it well.

How to Think About Custom Requirements

The key question is: what are the security rules that are specific to MY project that a generic scanner wouldn’t know about?

For our Node.js e-commerce example, we need to think about:

  • What sensitive data do we handle? (user info, payment data, order history)
  • What are the critical business flows? (checkout, authentication, inventory)
  • What resources belong to specific users? (orders, carts, addresses, invoices)

The best custom requirements target business logic that a generic scanner would never catch. They also need to provide ongoing value  — not just a one-time check, but something that gets re-evaluated every time new code is introduced.

How to Write a Good Requirement

Here’s a framework you can follow. For the official guidelines, see Best practices for defining security requirements.

  1. Focus on recurring risks  — The best custom requirements catch issues that can be reintroduced with every new feature. Ownership validation, input sanitization at specific boundaries, or business rule enforcement are great candidates because they apply to every new endpoint, not just existing ones.
  2. Cover your business logic  — Generic scanners know about SQL injection and XSS. They don’t know that in YOUR app, orders have owners, prices should never come from the frontend, or that specific workflows require specific validations.
  3. Be specific in compliance criteria  — The more precise you are about what “compliant” and “non-compliant” look like, the better the agent will perform. Include concrete examples, field names, and patterns from your actual codebase.
  4. Keep applicability focused  — Clearly state when the requirement should NOT apply to avoid false positives. If a requirement only applies to route handlers that accept resource IDs, say so.
  5. Let managed packs handle the generic stuff  — Don’t waste your 20 custom requirement slots on things like “validate JWT tokens” or “don’t hardcode secrets.” The managed packs already cover those. Use your custom requirements for what only YOU know about your application.

Example: Enforce Resource Ownership Validation on All User-Scoped Endpoints

Why this matters: In an e-commerce app, resources like orders, carts, and addresses belong to specific users. Every time a new endpoint is created that accesses one of these resources by ID, there’s a risk of introducing an IDOR (Insecure Direct Object Reference) vulnerability — where any authenticated user can access another user’s data simply by guessing or enumerating IDs.

This is not a one-time fix. Every new endpoint that touches a user-owned resource needs this check. It’s the kind of thing that slips through when a developer is in a rush to ship a feature — and that’s exactly why it makes a great custom requirement. The agent will re-evaluate it on every PR that adds or modifies route handlers.


Custom Security Requirements Fields

Loading It Into the Console

Now that we know what we want to enforce, let’s create it in AWS Security Agent:

  1. In the AWS Security Agent console, go to Security requirements.
  2. Select the Custom security requirements packs tab.
  3. Click Create security requirements pack , give it a name (e.g., “ecommerce-packs”) and an optional description, then click Create security requirement pack.
  4. Open the pack you just created. In the Pack security requirements section, click Add requirement manually.
  5. Fill in the fields with the values from the table above: name, description, applicability, compliance criteria, and optionally remediation guidance.
  6. Click save.


Custom Security Requirement

Once created, you’ll see it enabled on the security pack:


Security Requirement Pack

Seeing It in Action

To test this setup, I created a simple Node.js e-commerce API with endpoints for orders, cart, and user profiles. All the existing endpoints correctly validate resource ownership using an authorizeOwnership middleware. Then I opened a PR that adds a new invoice endpoint — but this time, "forgot" to add the ownership check.

Here’s what happened: the Security Agent reviewed the PR and flagged the exact vulnerability within minutes.

The finding clearly explains:

  • What’s wrong: the invoice endpoint loads an order by ID without verifying it belongs to the authenticated user
  • The impact: any logged-in user can access another customer’s order details, including PII like shipping addresses
  • How to fix it: apply the authorizeOwnership middleware or scope the query with the user's ID


Security Agent PR Review


Security Agent PR Review

This is the custom requirement doing its job. A generic scanner might flag this as a general authorization issue, but because we defined the specific pattern our app uses (the authorizeOwnership middleware, the user field on resources), the finding is precise and actionable.

Bonus: What the Managed Packs Found

Here’s the thing — the custom requirement wasn’t the only thing that caught issues. The managed security packs (which require zero configuration) independently found 6 additional vulnerabilities in the same PR:

  • JWT verification without an algorithm allowlist (HIGH)
  • A non-atomic checkout flow vulnerable to race conditions (HIGH)
  • Missing input validation on cart endpoints (MEDIUM)
  • NoSQL query injection via unvalidated ObjectIds (MEDIUM)
  • Unreachable order cancellation logic due to a state machine contradiction (MEDIUM)
  • Cart item deduplication bypass via case-sensitive ID comparison (MEDIUM)


Security Agent PR Review Sumamry

That’s 7 total findings from a single PR review — 1 from your custom requirement and 6 from the managed packs — all without spending a cent.

Wrapping Up

With this setup, you now have an automated security review pipeline that:

  • Scans every pull request against both AWS-managed security standards and your custom rules
  • Catches project-specific vulnerabilities that generic tools would miss
  • Costs nothing for code review features (you only pay if you use penetration testing)
  • Requires no maintenance — the managed packs are updated by AWS, and your custom requirements stay active until you change them

For a solo developer or a small team, this is a significant improvement over having no security review at all. The 1,000 PR reviews per month and 20 custom requirements are more than enough to cover most early-stage projects.

The most valuable part is the custom requirements. Take 30 minutes to think about what’s specific to your project — the data you handle, the services you connect to, the business rules that matter — and translate those into clear requirements. That’s 30 minutes that will save you from shipping vulnerabilities to production.

Useful links:

Top comments (0)