AppSecNews
SAST Commercial, free tier Established

Brakeman

by Brakeman

A Rails-aware static analyzer that models controllers, routes and views to find injection, mass assignment and unsafe redirect flaws in Ruby code.

Visit brakemanscanner.org (leaves AppSecNews, opens in a new tab) Leaves AppSecNews for the vendor's own site.

No endorsements yet

Run Brakeman in production? A named recommendation helps the next team shortlisting it.

Recommend this tool

Endorsers verify their identity through LinkedIn. Titles and companies are self declared, shown as they were when each person signed, and reviewed by an editor before anything is published. Endorsements are never paid for.

What we still need to verify : 1 point in this profile is not yet confirmed against vendor documentation.
  • Current licensing terms and any restrictions on commercial use: confirm with the project

Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.

What it does

Brakeman parses Ruby source with a Ruby parser and then does something most generic scanners do not: it builds a model of the Rails application. It reads routes.rb to learn which controller actions are reachable, associates each action with the templates it renders, tracks instance variables from controller to view, and understands that params and cookies are attacker-controlled. From there it runs taint propagation toward known dangerous sinks: raw SQL fragments passed to ActiveRecord, render with a user-supplied path, redirect_to with an unvalidated target, html_safe on tainted strings, constantize and send on user input.

Because it works from source, it never needs the application to boot and it reaches code paths no crawler would find. Each warning carries a confidence level (high, medium, weak) reflecting how certain the engine is that the tainted value truly reaches the sink. Results can be written to JSON, SARIF, HTML or a terminal table, and a checksum-based ignore file lets teams triage a warning once and keep it suppressed until the surrounding code changes.

Where it fits

Brakeman runs as a CLI, typically wired into CI to fail on new high confidence warnings, and often on the developer's machine before a push. The usual pattern is to generate an ignore baseline on first adoption and then gate only on warnings that were not in the baseline. Developers own it in practice. It requires nothing beyond a conventional Rails layout, and the further a codebase drifts from Rails conventions, the less the app model holds together.

Strengths

  • Framework awareness produces far more precise results on Rails than a language-generic scanner, because it knows what is reachable and what is user-controlled.
  • Confidence levels are meaningful and make a sensible gating axis: fail on high, report the rest.
  • No build or dependency install required, so scans are quick and reproducible.
  • The ignore file keyed on code fingerprints means suppressions re-open when the relevant code actually changes.

Limitations

  • Rails only. Sinatra, Hanami, Grape and plain Ruby services get little to no useful coverage.
  • Metaprogramming, dynamic dispatch and heavy DSL use defeat the analysis, and Rails codebases tend to have plenty of all three.
  • Medium and weak confidence warnings carry a real triage cost, and teams that gate on everything usually end up ignoring the tool.

Who it suits

If you run Rails in production, this is close to table stakes and belongs in your pipeline. It suits teams who can absorb an initial triage pass to build a baseline. It is not a general Ruby security tool and not a substitute for dependency scanning, secret detection or dynamic testing.

Used Brakeman? Recommend it under your own name and title.

Recommend this tool