Sample: Vulnerable App for Security and DevOps Agents (intentionally vulnerable sandbox)

The demo application in this repo is a fictional app called "Nimbus AI Sales Portal." It exists only to give the agents something realistic to work on.

⚠️ Intentionally vulnerable. Sandbox account only, us-east-1. Tear down after. Do not run in a shared or production account. Use a throwaway GitHub repo.

This is a sample for education and demonstration. It is not for production use. See SECURITY.md for the full list of intentional vulnerabilities.

The story

Every team ships software carrying two quiet worries: is the code actually safe, and what happens when production breaks at 2am. Security reviews tend to be slow and manual, and incident response usually rides on whoever still remembers how the system is wired together. AWS now has two agents aimed straight at those problems. The Security Agent reviews code and runs penetration tests against a live app. The DevOps Agent watches a running system, maps its topology, and investigates incidents on its own.

This project is the smallest realistic thing that exercises both at once. It is a single, deliberately vulnerable notes app (Nimbus) deployed the way real apps run on AWS: an Application Load Balancer in front of an ECS Fargate service backed by DynamoDB, with logs and alarms flowing into CloudWatch. The planted flaws give the Security Agent something real to find and fix. The live traffic plus a one-command "break it" switch give the DevOps Agent a real incident to chase.

The whole point is to watch both agents work the same system in about half an hour. The Security Agent opens a remediation pull request for a vulnerability it discovered, and the DevOps Agent produces a mitigation plan for an outage it diagnosed. Nothing changes automatically: each agent proposes, and a human approves. Everything below is the build. Deploy the app, point the agents at it, then watch them go.

A single small app that feeds both agents:

• Security Agent: connect the GitHub repo (code review + remediation PR) and run a pentest against the public URL.
• DevOps Agent: maps the topology, then you trigger an incident and watch it investigate.

Architecture

Rendered with the Python diagrams library (official AWS icons), the same engine the aws-diagram MCP server uses. Source: architecture_diagram.py. Regenerate with python architecture_diagram.py.

Flow: the Security Agent reviews the GitHub repo (and opens a remediation PR) and pentests the live app over HTTP. End-user traffic hits the ALB, into the ECS Fargate Flask app, which reads/writes DynamoDB and emits CloudWatch logs and metrics. When the injected fault trips the 5xx alarm, the DevOps Agent reads that telemetry, builds the topology, and investigates.

Prerequisites

• Credentials for a sandbox AWS account, default region us-east-1
• finch or Docker running locally (deploy uses finch by default)
• AWS CLI v2
• A throwaway GitHub repo (for Security Agent code review)

1. Deploy the app (~10-15 min incl. image build)

Run from the repository root (the script builds the image in app/ and deploys the CloudFormation template in infra/):

chmod +x *.sh
./deploy.sh                              # uses finch by default
# for Docker instead:  CONTAINER_CLI=docker ./deploy.sh

Outputs the App URL (your pentest target). Wait ~1-2 min for the task to go healthy, then:

• http://<alb>/: notes UI (reflected XSS via ?q=)
• http://<alb>/health: health check (always 200)
• http://<alb>/admin/debug: unauthenticated env dump
• http://<alb>/diagnostics?host=127.0.0.1: command-injection endpoint

2. Push the code to GitHub (for Security Agent code review)

cd app
git init && git add . && git commit -m "nimbus demo app"
git branch -M main
git remote add origin git@github.com:<you>/nimbus-demo-app.git
git push -u origin main

3. Configure AWS Security Agent (us-east-1)

1. Console > AWS Security Agent > create your first Agent Space (name it nimbus-demo); choose access (IAM Identity Center SSO or IAM-only).
2. Code review: connect your GitHub repo, then run a full repository review (and/or enable PR comments). It should flag the planted vulns and can open a remediation PR.
3. Pen test: create a pentest, scope = the App URL from step 1, provide any auth details (none needed here), set network access. Kick it off early. It takes time.
4. In the demo: show the findings dashboard (CVSS scores, reproduction steps) and the remediation PR.

4. Configure AWS DevOps Agent (us-east-1)

1. Console > AWS DevOps Agent > create an Agent Space; let the console auto-create the IAM roles; enable the web (operator) app.
2. Associate this account as the monitoring account. Let it build the topology (give it a little time).
3. Open the web app, then browse Topology (you should see ALB to ECS to DynamoDB).

5. Trigger the incident (for the DevOps Agent investigation)

./break-it.sh
# then generate some 5xx traffic:
for i in {1..20}; do curl -s -o /dev/null -w '%{http_code}\n' http://<alb>/ ; done

The nimbus-demo-target-5xx CloudWatch alarm trips within ~1-2 min. Watch DevOps Agent investigate, correlate the recent deployment, and produce a mitigation plan (it won't change anything, read-only).

Revert when done:

./fix-it.sh

6. Tear down (stop the cost)

./teardown.sh

Planted vulnerabilities (what Security Agent should find)

#	Vulnerability	Where	Demo value
1	Hardcoded credentials/secret (CWE-798)	top of app.py	Code review finding + PR
2	Reflected XSS (CWE-79)	/ via ?q=	Code review + pentest
3	OS command injection (CWE-78)	/diagnostics?host=	Pentest (high severity)
4	Missing auth + info disclosure (CWE-306)	/admin/debug	Pentest + code review

What the agents do on this app

Both agents work the same running system from different angles. The Security Agent looks at the code and the live surface. The DevOps Agent looks at the running infrastructure and its telemetry. Neither one makes changes by itself. Each one proposes, a human approves.

AWS Security Agent (make it secure)

Pointed at the GitHub repo and the App URL, the Security Agent gives you three things on this sample:

1. A design review of design/architecture-design.md that flags the deliberate gaps: plain HTTP on the ALB, an unauthenticated admin endpoint, secrets in source and env vars, a single shared DynamoDB table with no tenant isolation, 0.0.0.0/0 ingress, and an over-broad ECS task role.
2. A code review of app/app.py that finds the planted CWEs (hardcoded credentials, reflected XSS on /, OS command injection on /diagnostics, missing auth on /admin/debug) with CVSS scoring, reproduction steps, and file/line references. Where a mechanical fix exists, it opens a remediation pull request your dev can review and merge.
3. A live pentest against the ALB URL that reproduces the runtime findings. It actually injects a script tag through ?q=, chains a command through /diagnostics?host=, and pulls the env dump from /admin/debug, so you see evidence, not just static warnings.

One agent covers three layers (design, code, and live app) and turns findings into a pull request you can merge.

AWS DevOps Agent (debug and troubleshoot)

Pointed at the same account, the DevOps Agent gives you three things on this sample:

1. An automatic topology of the running service (ALB, target group, ECS service and task, DynamoDB table, CloudWatch log group and alarms), so on-call has a live map instead of a stale diagram.

2. A tabbed investigation (Timeline, Root cause, Mitigation plan) that kicks off automatically when the nimbus-demo-target-5xx alarm trips after you run ./break-it.sh. The agent walks the topology to the failing ECS task, diffs task definition revisions to spot the injected BREAK_APP=true env change, pulls the deployer identity out of CloudTrail, extracts the exact error line from the container logs (an AccessDeniedException on a DynamoDB Scan), and renders inline CloudWatch charts (request count, 5xx count, 2xx count, healthy host count, target response time) right in the timeline. Each observation is cited back to the log lines and metrics it came from.

3. A mitigation plan grounded in that investigation: a proposed rollback to the previous task definition (or a targeted env-var fix), with links to the log lines, metric charts, and CloudTrail events, plus the sequence of AWS operations it would run. It stays read-only, so your team executes.

Instead of paging a human to reconstruct the system at 2am, the DevOps Agent has already mapped it, watched it, isolated the fault, framed the fix, and shown its work.

Humans stay in the loop

Both agents are proposal engines. The Security Agent proposes a code fix; a developer reviews and merges the PR. The DevOps Agent proposes a mitigation; an operator runs it. Nothing on this stack changes automatically, which is exactly what makes it safe to show live.

Security

This sample is intentionally vulnerable for demonstration purposes. See SECURITY.md for the full list of planted vulnerabilities and how to report a real (non-intentional) issue. Do not deploy outside a disposable sandbox account.

License

This library is licensed under the MIT-0 License. See the LICENSE file. Third-party dependency attributions are in THIRD-PARTY-LICENSES.