Scryer — Scryer is an all-in-one security auditing and static analysis gem for Ruby on Rails applications.

An all-in-one security auditing and static analysis tool for Ruby on Rails applications — tells you what to fix first, across security, performance, dependencies, and code quality.

gem install scryer MIT licensed zero runtime deps

Scryer scans Ruby and Rails source for security vulnerabilities, performance problems, dependency risk, and code-quality issues, then ranks everything it finds by severity across those categories — so a scan ends with one answer to "what's most worth fixing first," not four separate tool outputs to reconcile by hand. Built on Ruby's own stdlib Ripper parser, so the static scan needs no Rails or Bundler to run at all.

gem install scryer
scryer

Scryer Audit — 236 files scanned
────────────────────────────────

Security Score: 10/100 (F)
Checks: 23/36 rules clean (63.9%)

Security               27 findings
Performance            10 findings
Code Quality          248 findings
Dependencies           24 findings
────────────────────────────────
Total                 309 findings

Top priorities:
  1. [critical] security — mass_assignment (app/helpers/api/v1/create_order_helper.rb:14)
  2. [critical] security — mass_assignment (app/helpers/api/v1/create_order_helper.rb:45)
  3. [critical] security — mass_assignment (app/helpers/api/v1/checkout/checkout_helper.rb:92)
  4. [critical] security — sql_injection (app/controllers/concerns/billing_helper.rb:12)
  5. [critical] security — mass_assignment (app/controllers/api/v1/orders_controller.rb:8)

JSON report: tmp/scryer_report.json
HTML report: tmp/scryer_report.html

That's real output from a scan of a live 236-file Rails app ("acme-app" here — file/controller names anonymized since we don't publish that app's source; counts, severities, and line numbers are exactly as scanned), not a mockup — the harsh grade included. "Top priorities" is the same severity ranking applied across all categories, not just within each one; it's the first thing in the Findings section of the HTML report, which also leads with a security score badge and severity chart.

What it detects

• Security — 31 rules: SQL injection, mass assignment, command injection, hardcoded secrets (including a hardcoded secret_key_base), unsafe deserialization, XSS-prone HTML, CSRF gaps, weak crypto, open redirects, SSRF, path traversal, IDOR (least precise check in the gem — see comparison table), missing authorization/policy scoping, authentication filters explicitly skipped, Rails security configuration (HTTPS enforcement, session cookie flags, cookie serializer, default security headers, Action Cable forgery protection, production-only config audit), Active Storage content-type/disposition checks, CORS misconfiguration, insecure JWT usage, background jobs passed raw params, and GraphQL schemas missing query depth/complexity limits. Every finding also carries a CWE ID, an OWASP Top 10 (2021) category, and a confidence level (own best-effort tagging, not OWASP-audited), rolled up into an OWASP coverage scorecard. Fixes can be AI-rewritten and automatically re-scanned to confirm they actually work (scryer verify).
• Performance — N+1 queries, missing pagination, inefficient per-record saves, unbounded full-table iteration.
• Code quality — near-duplicate code across methods (token-normalized similarity), plus one narrow style check: a missing frozen_string_literal magic comment.
• Dependencies — known-vulnerable gem versions (live OSV.dev query), insecure Gemfile.lock sources, Ruby version end-of-life, and a committed/un-gitignored config/master.key — all on by default.
• Runtime — an opt-in ActiveRecord query watcher for N+1s and unused eager loading as they actually happen.

Reports: JSON, self-contained HTML, CSV, and SARIF 2.1.0 — SARIF feeds GitHub Code Scanning and similar CI dashboards directly for inline PR annotations, tagged with CWE and a combined severity+confidence rank. A bundled GitHub Action wraps install + scan + SARIF upload in one step.

How it compares

Brakeman is the deeper, more mature tool for the security categories it's spent years on — real taint/data-flow analysis, not heuristic pattern-matching (see †). RuboCop owns style/lint conventions. Scryer isn't trying to out-analyze either at their own specialty — it looks at security, performance, dependency, and code-quality findings together and ranks the result, which is a different question than any one of these tools is built to answer.

Capability	Scryer	RuboCop	Brakeman	bundler-audit
Style/lint conventions	Partial*	✅	❌	❌
Rails security scanning	✅†	❌	✅	❌
Performance heuristics	✅	Partial	❌	❌
Duplicate code detection	✅	Partial	❌	❌
Dependency vulnerabilities	✅	❌	❌	✅
Runtime query analysis	✅	❌	❌	❌
SARIF report (GitHub Code Scanning)	✅	❌	✅	❌
Cross-category risk ranking ("fix this first")	✅‡	❌	❌	❌
Single command, all of the above	✅	❌	❌	❌

* One narrow check only (a missing frozen_string_literal magic comment) — everything else in RuboCop's domain is intentionally out of scope.
† Heuristic pattern-matching, not taint/data-flow analysis — Brakeman traces whether user input can actually reach a sink; Scryer checks whether a dangerous call shape and a params reference appear together. Real precision gap on the harder checks, idor especially — every finding says "review this," never "this is definitely a bug."
‡ Each tool ranks findings within its own domain at best (e.g. Brakeman's confidence levels). None of them combine security, performance, dependency, and code-quality findings into one ranked list — that's what Scryer's "Top priorities" (shown above) does. Full breakdown with footnotes in the README.

Guides

• What is a Rails security scanner? — SAST for Rails explained, what a scanner actually checks, and where Scryer sits among Brakeman, RuboCop, and bundler-audit.
• Taint analysis vs. heuristic pattern matching — the honest engineering tradeoff behind Scryer's approach, with real Ruby examples of where each one is right and wrong.
• Dependency security for Rails applications — what a Gemfile.lock audit actually needs to check, and why Scryer queries OSV.dev live instead of shipping a bundled advisory database.
• Security code review checklist for Rails — a concrete, usable PR checklist, split by what a static analyzer can catch versus what still needs a human.

Links