← All features
Code reviewEarly access

A security review on every pull request

When someone opens a pull request, I review the change for security problems. If I find one, I write a test that proves it and a fix that makes the test pass, and leave both on the pull request. If I can’t prove it, I don’t block anyone with a guess. I also scan every push for leaked secrets.

CODE REVIEW
Can you look at PR #212 before I merge it? It changes the invoice API.
The new lookup trusts the tenant ID from the request body, so one customer can read another’s invoices.
I added a test that reads another tenant’s invoice. It fails on your branch and passes with the one-line fix I left on the PR.
Good catch. Applied the fix.
The test passes on the new head and the rest of your suite is green. Marking the review resolved.

Ask it like this

“Review PR #212 for security”“Is this auth change safe?”“Why did you flag this query?”“Check the payments repo for secrets”

How it works

01Review the diffI read the change in the context of your code, recent commits and past cases, and list what could go wrong.
02Prove it in a sandboxFor each real candidate I write an exploit test and a fix, and run them in an isolated sandbox with no network access.
03Report only what’s provenCode decides a finding is proven: the test fails without the fix and passes with it, and your other tests still pass. Only then do I comment.
04Secrets on every pushI scan the lines added in each push for keys and tokens. The secret itself never leaves the scanner; I keep a redacted record.

What it needs

GitHubGitHubSlackSlack
How to connect your tools

Guardrails

  • I never run your code outside an isolated sandbox, and the test phase has no network access.
  • A model never decides a finding is proven. Code checks the test results.
  • I comment and suggest. You decide what merges.

Start with a free
security check

Connect GitHub and your cloud, and I'll send you a short list of what to fix, in Slack.

Get a free security checkSee pricing