It started as the system that secures Yembo

Before Robochicken had a name, it was how my team at Yembo closed findings inside our audit windows. Here’s how it works there, and what its output looks like.

Yembo needed every finding closed on a deadline, with proof

Yembo runs AI over video of the inside of people’s homes. That’s about as sensitive as customer data gets, and it’s why we hold ourselves to ISO 27001, SOC 2 Type II, and GDPR at the same time.

Each of those frameworks asks the same question about a vulnerability. When did you find it, when did you fix it, and how do you know the fix worked? Answering it for every finding, every audit cycle, was eating engineering time we wanted on the product.

So I built the part that was missing.

Findings from our scanners now go to Robochicken instead of a backlog. It writes the patch, runs our tests, opens the pull request, and asks the scanner to re-test after we deploy. An engineer still reviews every change. What they no longer do is start from a blank editor and a vulnerability description.

Most of the volume is the supply chain. Robochicken monitors hundreds of CVEs a week across Yembo’s dependencies and opens a pull request only for the ones that apply to our code. A CVE that doesn’t apply never becomes a pull request, so the ones that arrive are worth a reviewer’s time.

And when the auditor asks, the answer is already attached to the pull request: the finding, the fix, the passing tests, and the clean re-scan, with timestamps.

We built it for ourselves. Most teams need it more than we did.

Zach presenting on an outdoor stage beside a large digital screen displaying the slide 'Who Yembo is' with key company facts.
The slide reads SOC 2 Type II, ISO 27001, GDPR. Robochicken is part of how that line stays true.

Here’s what a fix looks like when it lands

These three are worked examples of Robochicken’s output on common finding types. The code is illustrative and not taken from Yembo or any other company’s repository.

Breaking the tape on a merged fix.

Worked example 1 of 3, TypeScript

A SQL injection in a TypeScript API becomes a parameterized query

The finding
The scanner sent a quote character into the order search box and got a database error back, then pulled rows from another table. Critical, with a working payload.
The fix
The query was built by pasting the search text into a string. Robochicken switched it to the ORM’s tagged template, which sends the values separately from the SQL. The endpoint, its response, and every caller stay the same.
 export async function searchOrders(req: AuthedRequest) {   const q = String(req.query.q ?? '');-  const rows = await db.$queryRawUnsafe(-    `SELECT * FROM orders WHERE customer_id = '${req.user.id}' AND note LIKE '%${q}%'`,-  );+  const rows = await db.$queryRaw`+    SELECT * FROM orders+    WHERE customer_id = ${req.user.id} AND note LIKE ${`%${q}%`}+  `;   return Response.json(rows); }

How it was verified: The pre-flight run passed the existing order search tests. After deploy, the re-scan replayed the original payload and got an empty result instead of a leaked table.

Worked example 2 of 3, Python

An IDOR in a Python service gets an ownership check

The finding
Logged in as one tenant, the AI pentest changed an invoice ID in the URL and read another tenant’s invoice. High severity, verified with two session tokens.
The fix
The handler looked the invoice up by ID alone. Robochicken added the tenant to the query, so another tenant’s invoice is indistinguishable from one that doesn’t exist, and the response stays a 404 rather than a 403 that confirms the ID is real.
 @router.get("/invoices/{invoice_id}") def get_invoice(invoice_id: int, user: User = Depends(current_user), db: Session = Depends(get_db)):-    invoice = db.get(Invoice, invoice_id)+    invoice = db.scalar(+        select(Invoice).where(Invoice.id == invoice_id, Invoice.tenant_id == user.tenant_id)+    )     if invoice is None:         raise HTTPException(status_code=404)     return invoice

How it was verified: Robochicken added a test that requests another tenant’s invoice and expects a 404. The pentest agent then re-ran the original cross-tenant request and was refused.

Worked example 3 of 3, Terraform

A public S3 bucket is closed in the Terraform that opened it

The finding
A cloud posture check found a bucket of customer exports readable by anyone with the URL. Someone had made it public to share a file and never changed it back.
The fix
Fixing it in the console would last until the next terraform apply put it back. Robochicken removed the public ACL from the infrastructure code and added a public access block, so the fix survives the next deploy.
 resource "aws_s3_bucket" "exports" {   bucket = "example-customer-exports" } -resource "aws_s3_bucket_acl" "exports" {-  bucket = aws_s3_bucket.exports.id-  acl    = "public-read"-}+resource "aws_s3_bucket_public_access_block" "exports" {+  bucket                  = aws_s3_bucket.exports.id+  block_public_acls       = true+  block_public_policy     = true+  ignore_public_acls      = true+  restrict_public_buckets = true+}

How it was verified: The pre-flight run ran terraform validate and a plan against the target account. After apply, the next posture check reported the bucket as private.

Your company could be the next case study

I’m taking on a small cohort of design partners: teams that already run a DAST scanner or AI pentest and have a backlog to show for it. These are the numbers we’re holding ourselves to with you. They’re targets, and we’ll publish the real results either way.

This frame is reserved for the next case study. Robochicken is holding your spot.
70%
of pull requests merged without a developer editing them
< 24h
from a validated finding to a tested fix in review
100%
of merged fixes confirmed by a re-scan

The 10 design partners get Robochicken through December 31, 2027 for half of retail. Applications close December 15, 2026 — apply now.

Apply to be a design partner

Tell me which scanner you run, what stack the findings land in, and how old your oldest open critical is.