One command. Every risk in your Rails app, ranked by impact.
What It Is • Quick Start • What It Catches • How It Works
What it is
Nuke on Rails is an open-source skill for AI coding agents (Claude Code, Cursor, Codex, and more), not a gem you add to your Gemfile. It audits your Rails app the way a principal engineer would: what to refactor, what's vulnerable, and in what order to fix it.
Instead of stapling separate tool reports together, it returns a single list, ranked by impact. An IDOR in your payments controller outranks a fat model; a high-churn fat model outranks a theoretical warning.
Scanners list problems. Nuke on Rails decides the order.
Quick Start
Nuke on Rails ships through the skills CLI. You'll need Node.js.
1. Install the skills CLI:
npm install -g skills
2. Add Nuke on Rails (from your project root):
skills add nuke-on-rails/nuke-on-rails
It works across agents: Claude Code, Cursor, Codex, Gemini CLI, Warp, and more.
3. Run it inside your agent:
/nuke-on-rails
Zero setup beyond that. It installs its own tools, detects Rails vs. plain Ruby, runs everything, and hands you the plan. It never touches your Gemfile.
4. Update when you want the latest checks and fixes:
skills update nuke-on-rails
Why not just ask the agent to "review my code"?
You can, and it'll find something. But "review my Rails app" gives a different, shallower answer every time and skips everything a deterministic scanner catches. The difference:
| Asking an agent to "review my code" | Nuke on Rails | |
|---|---|---|
| Scanning | The model eyeballs whatever files it happens to read | Brakeman parses 100% of the AST; bundler-audit and ruby_audit check every locked gem |
| Reproducible | A different answer every run | Deterministic engines plus a fixed methodology |
| Where it looks | Wherever the model wanders, until context runs out | Churn × complexity picks the hotspots that actually matter |
| CVEs & EOL | Bounded by the training cutoff; can't know yesterday's CVE | Live advisory DB, day-zero web cross-checks, end-of-life detection |
| False positives | Confidently reports plausible-but-wrong issues | Every security finding adversarially verified; unprovable ones flagged "theoretical" |
| Coverage | Whatever it remembers to check that day | A fixed OWASP Top 10 arsenal, every run |
| Output | A wall of prose | One list ranked by impact, with a fix-now plan |
The LLM still does the part it's good at: reading code paths, explaining exploits, judging severity. It just doesn't do it alone, from memory, and unprioritized.
What it catches
Coverage maps to the OWASP Top 10 2025. Each area is a weapon in the arsenal: a plain-markdown check the audit applies on top of the scanners.
Access control & IDOR
- Records loaded by id without ownership scoping (the canonical payments / orders / invoices case)
- Authorization missing where authentication exists (logged-in is not allowed-to)
- Mass assignment:
permit!, role escalation, value/state fields (credits/plan/stripe_customer_id), nested attributes, raw-Hash bypass - Records leaked through form dropdowns and serializers
- Cross-tenant leaks in multi-tenant apps; routes exposing actions that shouldn't be public
ActiveRecord correctness
- Side effects in
after_savethat race the transaction (belongs inafter_commit) where(...).firstwith no order (non-deterministic results)has_manywithoutdependent:, and polymorphic associations with no FK integritycount > 0/present?for boolean checks;all.eachover large tables
AI / LLM integration
- Prompt injection: user input or retrieved (RAG) content fed to the model as if it were instructions
- LLM output rendered with
raw/html_safe(stored XSS the scanners can't see), or piped intoeval/ SQL /system - PII and secrets sent into prompts to third-party model APIs without redaction
- Over-powered tool/function-calling: SSRF, DB, or shell reach with no allowlist or human-in-the-loop
- No rate or cost ceiling on LLM-backed endpoints (DoS and wallet-drain)
API surface
- JSON over-exposure (
render json:leaking token digests, role flags, PII) - Missing pagination (table dump and self-DoS); CORS wildcard with credentials; tokens in query strings
- Exception leakage; unverified webhooks
- GraphQL introspection and unbounded query depth/complexity
- XXE and entity expansion
- OAuth
redirect_uri,state, and scope flaws
Architectural boundaries
- Dependency direction: a model or service reaching up into the web layer (
params,render,*Controller) - Dependency cycles: two namespaces that reference each other and became one unit
- One-shot object ceremony (
Foo.new(x).call) and inconsistent component entry points - Zeitwerk name/path drift (
billing/charge.rbnot definingBilling::Charge)
Authentication & sessions
- Devise misconfig: user enumeration, no lockout, sessions that never expire, weak password policy
- Session fixation and missing cookie flags (
secure/httponly/SameSite) - Timing attacks and type-juggling on token and credential lookups
- Tokens stored in plaintext or without expiry; rate-limit / throttle bypass
- Custom Warden strategy bugs, scope confusion, impersonation gaps; JWT pitfalls (
nonealg, no expiry)
Background jobs
- Non-idempotent jobs that repeat the side effect on retry (double-charge)
- Secrets / PII in job arguments (persisted in the queue store, shown on the dashboard)
- Records passed instead of ids (stale data, deserialization failures)
CI/CD workflow security
pull_request_targetrunning a fork's code with the repo's secrets (RCE / exfiltration)- Untrusted
${{ }}(PR title, branch) interpolated into arun:shell (script injection) - Third-party actions pinned to a moving tag instead of a SHA (supply chain)
- Long-lived cloud keys as CI secrets instead of OIDC; over-broad
GITHUB_TOKENpermissions
Code quality
- Fat models
- Callback-driven workflows
- Rug concerns
- Spaghetti branching
- N+1 queries
- The churn × complexity hotspots
Configuration & hardening
force_ssl/ HSTS off; backing-service traffic (Postgres, Redis) in cleartext- CSP missing or disabled; CSRF skipped on cookie-authenticated actions; host-header injection
- Unauthenticated mounted dashboards (Sidekiq, PgHero, Flipper)
- Debug / console gems shipped to production (a remote-code-execution surface)
- Stack traces to users, unsafe uploads, stored XSS via markdown rendering
- SSRF: a user-supplied URL fetched server-side (cloud metadata, internal services)
Cryptography
- Encryption oracles (one crypto routine reused for trust tokens and user data)
- Hand-rolled crypto instead of Rails primitives; static IVs; unauthenticated cipher modes
- Weak password hashing (MD5/SHA); sensitive columns (CPF, SSN, bank, health) stored in plaintext
Dependencies & versions
- Known CVEs in your gems and in the Ruby version itself
- JavaScript dependency advisories
- Insecure or unpinned gem sources
- End-of-life Ruby or Rails (a critical compliance finding even with zero open CVEs)
Logging & monitoring
- Sensitive data in logs (filter gaps,
puts/ logger dumps, unscrubbed error-tracker breadcrumbs) - PII sent to third-party and LLM calls
- No audit trail on login, payment, privilege, and admin actions
Migration safety
- Schema changes that lock or rewrite large tables (
null: falsewithout default, non-concurrent indexes, type changes, foreign keys validated in one shot) - Data backfills inside DDL migrations
- Deploy-ordering hazards: columns dropped or renamed ahead of the code that uses them (expand/contract)
- Irreversible, non-rollback-safe migrations; missing indexes on foreign keys
Secrets
master.key, credentials keys, or.envcommitted to git (including in history)- Hardcoded API keys (Stripe, AWS, Twilio…) in code and initializers
- Secrets in seeds, fixtures, or
database.yml; secret-as-ENV-fallback
Supply chain & trojaned code
evalof HTTP-fetched payloads (the trojaned take-home-assessment pattern)- npm
preinstall/postinstallhooks that run code the moment anyone installs - Obfuscated blobs: base64/hex strings decoded and executed, minified code with no build step
- Runtime "config" fetched from paste-bin endpoints (a remote kill-switch the author controls)
How it works
Deterministic scanners do the scanning; the LLM is the judge, not the author. On every run the skill:
- Detects the project: full Rails app, plain Ruby (graceful degradation), or neither.
- Runs the scanners and reads their machine-readable output. It brings its own tools and never touches your Gemfile.
- Picks the hotspots by churn × complexity, reading deeply where it matters instead of reviewing everything uniformly.
- Triages: it kills false positives by reading the actual code path, brings the arsenal above, and adversarially verifies every security finding before it reaches the report. Anything it can't justify is downgraded to "theoretical," not sold as confirmed.
- Returns one report, ranked by impact: a plan a principal engineer would sign, not a tool dump.