Brakeman is a static analysis scanner for Rails applications. It reads your source without running it and reports warning types such as SQL injection, cross site scripting, mass assignment and unsafe redirects. It cannot see runtime configuration, business logic flaws, or vulnerable gems the way a dependency audit does.
What it reports
The Brakeman documentation lists the warning types it can detect. They include attribute restriction, authentication, command injection, cross site request forgery, cross site scripting, dangerous evaluation, dangerous send, default routes, denial of service, dynamic render paths, file access, format validation, information disclosure, mass assignment, path traversal, remote code execution, session settings, SQL injection, unsafe deserialization, unscoped find, unsafe redirects, weak hash and unmaintained dependencies.
Each warning carries a confidence level, so you can triage the likely real problems first. The docs also cover configuration files and ignoring false positives, so teams can record decisions instead of deleting findings.
A map of coverage
| Risk | Brakeman | Another check needed |
|---|---|---|
| Interpolated SQL in queries | Yes, reads code | Review of raw SQL in gems |
| Mass assignment | Yes | Code review for new models |
| Unsafe redirect or file access | Yes | Tests of the live behaviour |
| Missing authorization on a record | Partly (unscoped find) | Manual and integration tests |
| Vulnerable gem version | Limited | Dependency audit of Gemfile.lock |
| Production settings | No | Config review, hosts, SSL |
| Secrets in the repository | No | Dedicated secret checks |
The pattern is simple. A static scanner finds code shaped like a known bug. It does not know what your app is supposed to do.
Steps to use it well
- Run it locally first, so developers see results before CI does.
- Add it to CI and block on high confidence warnings for new code.
- Save the first report as a baseline. Triage it once, then ignore only what you have explained.
- Review ignores on a schedule, since code changes can make an old false positive real.
- Pair it with a dependency audit. Our post on bundler-audit in CI shows how.
- Add tests for authorization, because no scanner knows who should see what.
Keep expectations realistic
A clean report is not proof that the app is safe. Static tools can miss flaws that depend on data flow they cannot follow, and they flag patterns that are harmless in context. Treat the tool as one signal among several. Our post on why a clean scan does not mean safe software goes further.
Try it yourself
Open the code scan walkthrough to see how a finding links back to a line of source. Click a result and note how confidence and location are presented.
Click through it at your own pace, or open it full screen.
Quick check
Does Brakeman run my app?
No. It analyses the source code statically.
Can I ignore a warning?
Yes. The docs describe ignoring false positives. Record a reason so the decision can be reviewed.
Safeguard offers dependency scanning, reachability analysis and pull request policy gates that sit alongside code scanners. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
