nuke-on-rails

Nuke on Rails

Rails アプリのプロジェクト全体の健全性を監査します。何をリファクタリングするか、何に脆弱性があるか、どの順番で対処するかを明らかにします。決定論的な3つのエンジンがスキャンし、判断するのはあなたです。出力は影響度順に並べた1つのリストのみで、ツールごとのセクションを継ぎはぎしたものにはなりません。

ユーザーの言語で応答してください。 ステップのアナウンスと最終レポート全体を、ユーザーが使用する言語で記述してください。つまり、すべてのラベルも対象です。重要度（Critical／High／Medium／Low）、セクションの見出し（SCOREBOARD、FIX NOW、FIX NEXT、BIGGEST STRUCTURAL MULTIPLIER、RULED OUT、NOTES）、検出事項のフィールド（Problem／Solution／Files／Technical details）も翻訳してください。この指示とtemplates/_OUTPUT.mdにある英語は、あくまで原文作成時の言語です。英語以外のレポートに英語のラベルを出力してはいけません。固定トークンとしてそのままにするのは、ブランド名NUKE ON RAILS、絵文字、ファイルパス、コード識別子、CVE IDのみです。

この監査は偵察です。数分かかるため、各ステップを簡潔な現場無線風の文でアナウンスし、ユーザーが作業の進行を確認できるようにしてください。設定は次のとおりです。実際の攻撃者が侵入に利用する弱点を探すため、偵察チームとしてコードベース自体の防御を調査します。敵は技術的負債と脆弱性であり、ユーザーではありません。以下の文は英語で作成されています。各ステップにつき短い1行で、ユーザーの言語に翻訳してください。

• ☢️ NUKE ON RAILS — operation underway
• 🔭 Recon — scouting the terrain (Rails? Ruby? git history?)…
• 🎖️ Mobilizing — arming & firing the engines…
• 🎯 Targets — marking where to concentrate fire (churn × complexity)…
• ⚔️ Probing the defenses — triaging N alerts, bringing the arsenal…
• 🧱 Inspecting the walls — reviewing the most battered files…
• 📋 Briefing the command — consolidating the field report…

残りの部分は、表示されるツール呼び出しで補完されます。このキャンペーン調の語り口を使うのは、これらのアナウンスとTL;DRの枠組みのみです。検出事項には決して持ち込まず、淡々と事実を記述してください。

Step 0 — プロジェクトを判定する

• Rails アプリ（config/application.rbが存在する、またはGemfileにrails gemが記載されている）：完全な監査を実行します。
• 通常の Ruby（Gemfileまたはgemspecはあるが、Railsはない）：機能を縮小して実行します。rubycriticとbundler-auditを実行し、Brakemanはスキップします。レポートのヘッダーでその旨を明記してください。
• どちらにも該当しない場合：停止し、このスキルはRuby／Railsプロジェクトを監査するものだとユーザーに伝えてください。

Ruby バージョンの落とし穴。 .ruby-version（またはGemfileで固定されたRubyのバージョン）に、このマシンにインストールされていないバージョンが指定されていることがあります。見慣れないリポジトリやAI生成のリポジトリではよくあり、rubycriticやbrakemanが出力を生成する前に中断する原因になります。これらのエンジンは静的解析を行うため、アプリと完全に同じRubyバージョンを必要としません。固定されたバージョンがない場合は、利用可能なRubyで実行してください（例：一時的な.ruby-versionを設定する、またはrbenv local <installed>／システムのRubyを使う）。エラーとして失敗させてはいけません。代替したことをレポートに記載してください。ロックファイルを満たすためだけに、固定されたRubyをインストールしてはいけません。

Step 1 — エンジンをインストールして実行する

依存関係ゼロの原則：スキルに必要なツールは同梱されています。アプリのGemfileには決して手を加えないでください。

gem list rubycritic -i || gem install rubycritic
gem list brakeman -i || gem install brakeman          # Rails only
gem list bundler-audit -i || gem install bundler-audit
gem list ruby_audit -i || gem install ruby_audit

続いて、すべてのエンジンを実行し、機械可読形式の出力を取得してください（実際のRails 8アプリで検証済みのコマンドです）。

OUT=$(mktemp -d)
rubycritic app --format json --no-browser --path "$OUT/rubycritic"   # --path keeps output files out of the audited repo
brakeman --format json --quiet -o "$OUT/brakeman.json"               # Rails only
bundle-audit update                                                  # update the db in a separate step:
bundle-audit check --format json > "$OUT/bundler-audit.json"         # --update mixed in pollutes the JSON on stdout
(cd "$OUT" && ruby-audit check)                                      # run OUTSIDE the app dir — inside a bundled
                                                                     # project the executable fails to load (Ruby 3.4+);
                                                                     # make sure the app's Ruby version is still active

エンジンが失敗した場合は、機能を縮小して実行してください。スキップしたエンジンとその理由を報告し、残りのエンジンで処理を続けます。

ステップ 2 — コンテキストをどこに割くかを決める（変更頻度 × 複雑さ）

rubycritic の変更頻度 × 複雑さのデータを使って、ホットスポット、つまり複雑でかつ頻繁に変更されるファイルを選びます。重点的に読み込むのは、そうしたファイルです。コードベースを一律にレビューしてはいけません。誰も触れない複雑なファイルより、複雑さは中程度でも毎週変更されるファイルのほうが優先度は高くなります。

変更頻度の算出には git の履歴が必要です。象限を信頼する前に必ず確認してください。 rubycritic は git log から変更頻度を算出するため、浅いクローン（--depth 1）や初期化したばかりのリポジトリでは、すべてのファイルの変更頻度が同じ値（1 または 0）になり、象限の分析結果が気づかないうちに意味のないものになります。これは、このスキルが対象とする、まさに不慣れなリポジトリでよく起こります。モジュール間で変更頻度が一様なら、その旨を伝え、複雑さとコードスメルの密度で順位付けしてください（rubycritic は Reek／Flay／Flog をラップしています。スコアだけでなく、モジュールごとの smells と complexity を使ってください）。可能であれば、まず浅いクローンを解除します（git fetch --unshallow）。

ステップ 3 — セキュリティの検出結果をトリアージする（判断を下すのはスキャナーではなくあなたです）

Brakeman の警告と bundler-audit の CVE をすべて対象に、次の手順を実施します。

1. 実際のコードパスを読みます。 このアプリで検出結果に該当する処理に到達できることを確認するか、誤検知として除外します。
2. 確認できた検出結果について、悪用経路を説明します。 誰が、どこから、どのような影響を伴ってトリガーできるのかを示します。
3. レポートに記載する前に、攻撃者の視点で検証します。 セキュリティの検出結果には、品質に関する検出結果より高い基準を適用します。品質に関する検出結果の根拠が弱ければ無視できますが、誤ったセキュリティ上の主張は信頼を損ないます。悪用経路を説明できない場合は「理論上の問題」に格下げし、確認済みとして提示してはいけません。

Brakeman の信頼度（High／Medium／Weak）は判定ではなく、事前確率として扱います。コードを読んで確認できた Weak の警告は、到達不能なパスに対する High の警告より重視してください。また、config/brakeman.ignore が存在する場合は、無視されている警告をすべて再トリアージしてください。未レビューのコードベースでは、ignore ファイルは「安全性を確認済み」ではなく、「CI を通過させた」という意味であることがよくあります。

依存関係と Ruby のバージョンに関する CVE については、bundler-audit と ruby_audit の出力に arsenal/cve.md を適用してください。重複排除、深刻度の事前確率、到達可能性のトリアージ、安全でない gem ソース、アドバイザリデータベースの遅延や網羅性の不足を補うネットワーク上での相互確認（ゼロデイの確認とセカンドオピニオン）が含まれています。

次に、セキュリティ対策の資料をルートファイル、機密性の高いコントローラーとモデル、本番環境の設定に適用します。

• arsenal/authorization.md — IDOR、認可の欠如、攻撃対象領域
• arsenal/authentication.md — 認証スタック、Devise の設定、カスタム戦略、セッション
• arsenal/secrets.md — コミット済みのキーとハードコードされた認証情報
• arsenal/hardening.md — TLS、CSP、CSRF の設定、マウントされたダッシュボード、アップロード
• arsenal/api.md — JSON の過剰な公開、CORS、レート制限、Webhook（アプリに JSON エンドポイントがない場合はスキップ）
• arsenal/cryptography.md — 暗号化オラクル、自作暗号、脆弱なハッシュ化、機密情報が平文で保存されたカラム
• arsenal/logging.md — ログ内の機密データ、セキュリティ上重要なイベントの監査証跡の欠如
• arsenal/ai.md — プロンプトインジェクション、XSS としてレンダリングされる LLM の出力、モデル API への PII 漏えい、過剰な権限を持つツール使用（アプリが LLM を呼び出さない場合はスキップ）
• arsenal/ci-cd.md — .github/workflows/／.gitlab-ci.yml／Jenkinsfile におけるパイプラインセキュリティ：フォークのコードを実行する pull_request_target、シェル内の信頼できない ${{ }}、固定されていないアクション、長期間有効なクラウドキー（リポジトリに CI 設定がない場合はスキップ）
• arsenal/supply-chain.md — リポジトリまたは依存関係に潜む悪意あるコード：取得したペイロードの eval、npm install フック、難読化されたデータ、Pastebin の設定エンドポイントなど、トロイの木馬を仕込んだ持ち帰り課題の手口（信頼できないソースから取得したリポジトリでは早い段階で適用してください。該当が確認された場合はそこで終了します）

これらの資料は、Brakeman では検出できない領域を扱います。資料はそれらの領域を網羅するものですが、安全性を保証するものではありません。レポートでは、この違いを明確にしてください。

ステップ 4 — ホットスポットの品質レビュー

arsenal/code-quality.md を適用します。Rails の流儀に合わせて翻訳された、熱核級の基準です。対象はステップ 2 で特定したホットスポットのファイルです。このチェックが、このスキルにおける標準の品質基準です。重視するのは、野心的な構造上の指摘であり、見た目だけの細かな指摘ではありません。

次に、db/migrate/ の最近のマイグレーションに arsenal/migrations.md を適用します。テーブルサイズは db/schema.rb を参照してください。これは、どのエンジンも所有していない可用性の兵器です。大量のトラフィックがある大規模テーブルをロックまたは書き換えるマイグレーションや、使用するコードより先にカラムを削除または名前変更するマイグレーションは、コードの臭いではなく、予定されたサービス停止です。それに応じた順位を付けてください。

さらに、app/ レイヤーのフォルダーとホットスポットに arsenal/architecture.md を適用します。rubycritic のファイル単位のスコアでは見落とされる、依存関係の方向と循環を調べます。たとえば、Web レイヤーに依存するモデル、互いを参照する 2 つの名前空間、Zeitwerk の名前とパスのずれなどです。

また、app/models/ とクエリ負荷の高いホットスポットに arsenal/activerecord.md を適用します。構造分析の各種兵器では判定できない、ActiveRecord 呼び出し自体の正確性と整合性を調べます。たとえば、トランザクションとの競合が発生する after_save 内の副作用、順序指定のない where(...).first、dependent: のない has_many などです。

さらに、app/jobs/ とジョブのエンキュー箇所に arsenal/jobs.md を適用します。エンジンではモデル化できないバックグラウンドジョブの安全性を調べます。たとえば、再試行時に副作用が繰り返される非冪等ジョブ（二重請求）、ジョブの引数に含まれるシークレットや PII（キューストアに保存され、ダッシュボードにも表示されます）、ID ではなくレコードを渡す処理などです。

ステップ 5 — レポート（出力）

このセクションでは、レポートに何を含めるか、そしてどのように評価するかを定めます。言語、口調、順位付け、最後の要約が対象です。レポートの表示形式である、ターミナル向けのプレーンテキスト（Markdown なし）は templates/_OUTPUT.md にあります。レポートはその骨格に合わせてください。 レポート全体をユーザーの言語で書いてください（このファイルの冒頭を参照）。

短い状況バナーで始めてください。「状況バナー」というラベルは付けず、そのまま記述します。プロジェクトの種類と Rails／Ruby のバージョン（異なる Ruby で実行した場合など、置き換えがあれば明記）、Git 履歴から変更頻度の象限を信頼できるかどうか、実行したエンジンとその主な件数、そして網羅性についての率直な一文を数行で示します（兵器は対象をカバーしますが、完全性を保証するものではありません）。TL;DR は、偵察作戦の口調に合わせ、指揮部への淡々とした現地報告として始めてください。口調の参考用に英語の例を示します（訳文として使わないでください）。「現地報告：陣地は炎上していません。ただし、裏口の鍵が開いており、そこから侵入されます。」ユーザーの言語で自然に書いてください。例を文字どおりに訳してはいけません。作戦の口調はバナーと TL;DR の枠組みに限ります。各指摘はすべて、冷静かつ正確に記述してください。

バナーの直後に、重大度のスコアボードを置いて本文を始めます。トリアージ後の件数を、1 行にまとめて記載してください。件数をラベルより先に書きます（Markdown の表は使わないでください。templates/_OUTPUT.md を参照）。

🔴 1 Critical   🟠 4 High   🟡 6 Medium   🟢 5 Low

依存関係リスクの合計とサポート終了のフラグは冒頭のバナーに記載し、ここでは繰り返さないでください。

続いて、影響度の高い順に指摘を 1 つのリストとして並べます。

1. 悪用が確認されたセキュリティ上の問題（決済コントローラーの IDOR は、他のすべての指摘より上位です）。
2. アプリケーションの実際の利用状況で到達可能な CVE。
3. 変更頻度が高く、複雑度も高い品質上のホットスポット（毎週変更される肥大化したモデルは、理論上の警告より上位です）。
4. トリアージを通過したものの、実証された悪用経路がない理論上のセキュリティ警告。
5. 残りの品質上の指摘。重大なものから順に並べてください。 各指摘は簡潔で、ひと目で把握できる平易な言葉でまとめてください。 Problem と Solution は、専門知識のない関係者にも、疲れ切ったシニアエンジニアにも伝わるように、日常的な言葉で書きます。メソッド名や行番号は使いません。まず、深刻度と内容を平易な言葉で示す1行の見出しを置きます（指摘番号や工数の見積もりは含めません）。続けて、問題を平易に説明し、具体的な修正策を示します。メソッド名、行番号、実際に到達可能な悪用経路、変更量や複雑さの指標といった技術的な詳細は、任意の Technical details フィールドに記載します（templates/_OUTPUT.md を参照）。具体的な根拠が何もない指摘には、このフィールドを設けません。数行のコードで説明が早くなる場合に限り、コードを示します。悪用方法を何段落もかけて説明してはいけません。シニアエンジニアが数秒で各指摘を把握し、次の対応を判断できるようにします。同じ問題が繰り返される場合は、代表的な file:line の場所を2～5か所示し、「+ 類似の問題が約N件」と記載します。すべての発生箇所を列挙する必要はありません。Rails の文体にならい、親しみやすく、率直に書き、堅苦しい言い回しは避けます。「Status banner」や「Findings」などの足場となるラベルは表示せず、レポートが自然に流れるようにします。

最後は計画で締めくくり、読者が次の行動に移れるようにします（冒頭のスコアボードで、本文はすでに始まっています）。

1. 今すぐ修正 — レバレッジの高い順に並べます。つまり、変更量が最小で、最も多くのリスクや負債を取り除けるものを優先します。影響の大きさだけで順位を決めるわけではありません。確認済みのクリティカルな問題と、影響が大きく手軽に対応できる改善（バージョン更新や設定1行の変更など）は、どちらもここに含めます。影響が大きくても、広範囲でリスクの高い構造変更は「次に修正」に回します。修正にかかる時間はチームやツールによって異なるため、所要時間は見積もらず、変更範囲と影響範囲を言葉で説明します。順位が同じ場合は、他の作業を可能にするもの（検証の基準となる状態や、振る舞いを明らかにするテストなど）を上位にします。確度の高いセキュリティ上の指摘は、レバレッジが同程度の非セキュリティ上の指摘より優先します。検証方法が明確な修正を優先します。各項目は、対象を先に示してから対応内容を続ける、簡潔で並列的な1行にまとめます。「ほかに何もしないとしても」実行すべき項目の一覧です。
2. 次に修正 — 残りの高・中程度の指摘を簡潔にまとめます。
3. 最大の構造的レバレッジ — 最も多くのリスクや負債を一度に取り除く、単一のリファクタリングを1行で示します。

スキャナーが検出したものの、対象外と判断した項目があれば、その理由を末尾近くの簡潔な1行で示します。項目名と理由をそれぞれ1語（誤検知／到達不能／開発環境のみ／対象違い）で記し、長いセクションにはしません。読者に、見落としではなく確認済みだと伝えます。

このレポートは機密情報です。 実際に存在する脆弱性とその悪用経路が記載されています。公開のイシュートラッカーやオープンなチャンネルではなく、アプリを修正できる人たちと共有してください。指摘を共有の場や公開の場に掲載する場合は、まずセキュリティ上の詳細（悪用経路や認証情報の保管場所）を伏せてください。

全体を、ツールの出力ではなく、プリンシパルエンジニアが手渡す実行計画のようにまとめます。