Automated vulnerability remediation
A proven finding in. A tested, re-scanned fix out.
Nothing reaches your reviewers until your own tests pass
Each stage hands the next one something verified. That’s why a pull request from Robochicken is worth your reviewer’s time.
-
Stage 1: Ingest the finding
Pull the validated finding from your scanner, with its evidence.
Robochicken reads findings through your scanner’s API: severity, CVSS vector, EPSS score, the affected target, and the HTTP request and response that proved it. When the finding came from a white-box AI pentest, it also takes the repository, file, and line the scanner pointed at.
-
Stage 2: Find the code that owns it
A syntax tree of the affected files maps the finding to the code behind it.
Robochicken clones the branch that matches the tested environment and builds an abstract syntax tree of the affected files. That maps the flagged endpoint to its controller, data access layer, and middleware, and it finds the utilities you already use, like your ORM’s parameter binding or your validation schemas, so the fix reads like your code.
-
Stage 3: Write the patch
A specialized agent per class of problem.
Application logic flaws get parameterized queries, context-aware output encoding, or ownership checks. Cloud misconfigurations get Terraform, CloudFormation, or Dockerfile changes. Perimeter and header findings get declarative config for NGINX, Caddy, or your edge rules.
-
Stage 4: Run your tests first
Every patch runs your own test suite in a throwaway container.
Before you see anything, the patch builds and runs your existing suite, whether that’s bun test, pytest, or go test, in an isolated container. If a test fails, the compiler output and failure log go back to the agent for another attempt, up to three. A patch that still fails is reported as a failure, not shipped as a guess.
-
Stage 5: Open a pull request
A signed branch and a PR your auditor can read.
The PR carries a plain-language summary for compliance, the scanner’s finding ID, a cURL reproduction of the original exposure, the diff, and the passing test run. It goes through your normal review. Robochicken never merges its own work.
-
Stage 6: Prove it’s closed
Re-scan after deploy, then close the ticket with evidence attached.
When the merge deploys, Robochicken asks your scanner to re-test the target. Once the scanner confirms the exploit no longer works, the finding is marked resolved and the Jira or GitHub issue closes with the audit evidence attached.
The pull request explains itself to your auditor
Your engineer reads the diff. Your compliance lead reads the summary. Your auditor reads the finding ID, the reproduction, and the test run.
All of it is in one place, attached to the change that fixed the problem, with a timestamp. That’s the evidence a remediation SLA asks for, and nobody had to write it up.
Fix SQL injection in GET /api/orders
robochicken wants to merge 1 commit into
main
from
robochicken/scan-48213
What was wrong. The search box text was joined into the SQL string, so anyone could read any table.
What changed. The query uses the ORM’s parameter binding. Finding SCAN-48213, critical, CVSS 9.8.
Reproduce the original exposure
curl -s "https://staging.example.com/api/orders?q=1'%20OR%20'1'='1"
-
Pre-flight tests , passed 412 passed in 38s
-
Build , passed Compiled on commit 9f3c2e1
-
Scope , passed 1 file changed, 4 additions, 3 deletions
-
Re-scan , pending Runs after deploy to staging
Waiting on review from a code owner
Merge is yours to pressAn example pull request. The finding, URL, and commit are illustrative.
It works with the stack you already run
- Languages
- TypeScript, JavaScript, Python, Go, Java, and PHP
- Infrastructure as code
- Terraform, AWS CloudFormation, and Dockerfiles
- Edge and proxy config
- NGINX, Caddy, and Cloudflare Rules
- Source control
- GitHub and GitLab
- Ticketing
- Jira and GitHub Issues
- Scanners
- Any DAST scanner or AI pentest that exposes findings and re-scans through an API
Guardrails come before speed
-
It never merges its own work.
Robochicken opens a pull request and stops. Your reviewers and your branch protection decide what ships.
-
It gives up after three tries.
If a patch can’t pass your tests in three attempts, you get a report explaining why, not a pull request that breaks the build.
-
It runs in a container that is thrown away.
Each pre-flight run gets a fresh, isolated workspace that is destroyed when the run ends.
-
It only touches what the finding points at.
Patches are scoped to the code and config the finding implicates. A header fix doesn’t refactor your router.
How Robochicken behaves in your repository
- Who built Robochicken?
- Robochicken was built by Zach Rattner, CTO and co-founder of Yembo, as the remediation system for Yembo’s own platform. Yembo holds ISO 27001, SOC 2 Type II, and GDPR obligations, documented in its public trust center, and Robochicken is how its findings get closed inside those audit windows. Robochicken is sold by Worthwhile Adventures LLC, Zach Rattner’s company.
- Does Robochicken replace my scanner?
- No. Robochicken runs no scans of its own. It takes the findings an existing scanner has already validated, fixes them, and uses that same scanner to confirm each fix worked.
- Does Robochicken merge code on its own?
- No. Robochicken opens a pull request and stops. Every change goes through the team’s normal code review, and a person decides whether it merges.
Point it at your oldest open finding
Your first three pull requests are free. 10 design partners get Robochicken through December 31, 2027 for half of retail, at a most-favored price. Applications close December 15.