Brakeman + auditdude
Brakeman is the best free thing that ever happened to Rails security. Keep it in CI. It flags the code shapes it has rules for, and it has no idea what your app is supposed to do. That second part is where the expensive bugs live.
No credit card · read-only access · keep Brakeman in CI
def create amount = params[:amount].to_i Stripe::Charge.create(amount: amount, currency: "usd", customer: current_user.stripe_id)end$ bundle exec brakeman
0 warnings · no rule for this
auditdude
High · Business logic — checkout trusts the client's price
Keep using it
Brakeman has been scanning Rails apps since 2010 and knows every classic Rails footgun: string interpolation in queries, html_safe on user input, shell commands built from params. If it isn't in your CI yet, add it today. Nothing on this page says otherwise.
The gap
Every Brakeman warning is a rule someone wrote for a shape of code: dangerous sink, user input, warn. But the worst Rails bugs aren't shaped wrong. A checkout that takes its price from the client looks like perfectly normal Rails. It's wrong in a way you only see by knowing what the app is for.
| Vulnerability | Brakeman | auditdude |
|---|---|---|
| SQL injection via string interpolation | ||
| XSS through html_safe and raw | ||
| Command injection from params | ||
| Missing authorization (IDOR) | ||
| Tenant isolation across accounts | ||
| Business logic: prices, quantities, state | ||
| The JavaScript half of your app | ||
| Findings verified before you see them |
The overlap costs you nothing, Brakeman runs in seconds. The bottom half is what nothing else is watching.
Why it matters
Brakeman reports in confidence levels: high, medium, weak. That's honest of it. A pattern matcher can't check whether the thing it flagged is reachable, already scoped, or mitigated two methods up. So a person reads the warnings, and the brakeman.ignore file grows.
auditdude does that reading for you. Claude follows the data flow through your real code, and anything that doesn't hold up never reaches you.
Brakeman's lane
Rails anti-patterns
Shapes of code known to go wrong, flagged with a confidence score for you to check.
auditdude's lane
What your app is supposed to allow
Who may see what, who may change what, what a request is allowed to cost.
Better together
Brakeman runs in seconds and costs nothing. auditdude takes a few minutes and reads everything. Run both; they'll never argue.
Static rules, instant feedback. Catches the classic Rails mistakes before the commit even leaves CI. Keep it on.
Claude reads your source on every push, follows the auth and the money, and opens the fix as a PR.
Closing the gap
Connect a repo with read-only access. From then on it runs where you already work.
auditdude reads your source with Claude on every push and pull request, not once a year before an audit.
Each verified finding lands as an inline comment on the vulnerable line in your PR, with the severity and the fix.
Review, run your tests, merge. Works on the Rails side and on everything else in the repo.
FAQ
It's a strong baseline and you should run it, but it only flags code shapes it has rules for: interpolated SQL, html_safe on user input, shell commands built from params. It doesn't know which records a user should be able to reach or what a checkout should cost, so authorization and business-logic flaws pass through silently. Those are the bugs that tend to end up in breach write-ups.
No. Brakeman has no model of your users, roles, or tenants, so it can't tell an intentional public endpoint from a forgotten authorization check. Catching an IDOR means understanding what the application is supposed to allow, which takes reading the app, not matching patterns.
Yes. It's free, it runs in seconds, and it catches the classic Rails mistakes right in CI. auditdude covers what Brakeman structurally can't: authorization, tenant isolation, business logic, and every language in your repo that isn't Ruby.
Brakeman tells you how confident it is and leaves the checking to you, which is why brakeman.ignore files grow over time. auditdude verifies each candidate finding against your actual code first: whether it's reachable, whether something upstream already mitigates it. If it doesn't hold up, you never see it.
Get started
Connect a repo and read your first findings ten minutes from now. No credit card, read-only access, revoke anytime.