nuke-on-rails

Nuke on Rails

为 Rails 应用进行全面的项目健康审计：该重构什么、有哪些漏洞，以及按什么顺序处理。由三个确定性引擎执行扫描；你来做判断。输出是一份按影响排序的清单，绝不把各个工具的结果分段拼在一起。

使用用户所用的语言作答。 步骤播报和整份最终报告都使用用户所用的语言——这也意味着所有标签都要翻译：严重程度词语（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 编号。

这次审计是一次侦察行动——只需几分钟，所以要像现场无线电播报一样简短地宣布每个步骤，让用户看到行动不断推进。设定是：你是侦察队，正在勘察代码库自身的防线，找出真正攻击者会利用的突破口；敌人是技术债和漏洞，绝不是用户。以下播报以英文撰写——请翻译成用户所用的语言，每个步骤用一行简短的话：

• ☢️ 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 的措辞）中——绝不能影响问题发现部分；发现内容必须保持客观、直白。

步骤 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 调用），不要因此直接失败——并在报告中注明使用了替代版本。切勿仅为满足 lock 文件而安装指定的 Ruby 版本。

步骤 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，请重新分诊其中每条被屏蔽的警告——在未经审查的代码库中，忽略文件往往意味着“让 CI 通过”，而非“已验证安全”。

对于依赖项和 Ruby 版本相关的 CVE，将 arsenal/cve.md 中的方法应用于 bundler-audit 和 ruby_audit 的输出——其中涵盖去重、严重性先验判断、可触达性分诊、不安全的 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 渲染的大模型输出、泄露给模型 API 的 PII、权限过大的工具调用（如果应用不调用大模型则跳过）
• arsenal/ci-cd.md — .github/workflows/ / .gitlab-ci.yml / Jenkinsfile 中的流水线安全：运行 fork 代码的 pull_request_target、shell 中不可信的 ${{ }}、未固定版本的 actions、长期有效的云密钥（如果仓库没有 CI 配置则跳过）
• arsenal/supply-chain.md — 驻留在仓库或其依赖项中的恶意代码：对获取的载荷执行 eval、npm 安装钩子、混淆代码块、paste-bin 配置端点——植入木马的居家作业评估模式（当仓库来源不可信时尽早应用：一旦确认命中，即为终止性问题）

这些内容涵盖了 Brakeman 无法触及的领域。安全工具集覆盖这些领域，但并不保证这些领域安全。请在报告中明确说明两者的区别。

第 4 步 — 热点质量审查

对第 2 步中的热点文件应用 arsenal/code-quality.md——将热核标准转换为 Rails 惯用方式后的版本。这项检查是此技能的默认质量门槛：关注有分量的结构性问题，而非表面小瑕疵。

然后对 db/migrate/ 中的近期迁移应用 arsenal/migrations.md（结合 db/schema.rb 查看表大小）——这是没有任何引擎负责的可用性武器。若某项迁移会锁定或重写大型、高流量表，或在使用该列的代码上线前删除／重命名列，那就是一场定时停机，而非代码异味：请据此排序。

还要对 app/ 层文件夹和热点应用 arsenal/architecture.md——检查依赖方向和循环，这是 rubycritic 的逐文件评分无法发现的：模型向上依赖 Web 层、两个命名空间相互引用，或 Zeitwerk 名称／路径不一致。

还要对 app/models/ 和查询密集型热点应用 arsenal/activerecord.md——检查 ActiveRecord 调用本身的正确性／完整性（例如在 after_save 中产生副作用并与事务竞争、where(...).first 没有排序、has_many 缺少 dependent:），这些都不是结构分析工具的评判范围。

还要对 app/jobs/ 和入队位置应用 arsenal/jobs.md——检查引擎无法建模的后台任务安全性：重试时会重复副作用的非幂等任务（重复扣款）、任务参数中包含的机密／PII（会持久化在队列存储中，并显示在仪表板上），以及传递记录而非 ID 的情况。

第 5 步 — 报告（输出）

本节规定报告包含什么以及如何评判——语言、语气、排序和结尾总结。**报告的视觉结构——终端原生纯文本，不含 Markdown——定义在 templates/_OUTPUT.md 中；报告必须符合该模板结构。**整份报告使用用户的语言撰写（见本文件开头）。

以简短的状态横幅开头——直接撰写，不要打印“状态横幅”标签。简要说明项目类型及 Rails／Ruby 版本（注明任何替代方案，例如在不同 Ruby 版本下运行）、Git 历史是否足以可靠判定变更象限、已运行的引擎及其概要计数，并用一句诚实的话说明覆盖范围（分析工具能覆盖哪些内容，但不能保证什么）。以对指挥部的简短现场报告开启 TL;DR，保持与步骤公告相符的侦察行动语气（仅供把握语气的英文示例：“现场报告：阵地没有着火——但后门没锁，这正是他们入侵的入口。”）。用用户的语言自然地撰写，让内容真正有感染力；绝不要逐字翻译示例。行动语气仅用于横幅／TL;DR 的框架；每条发现都必须保持严谨、准确。

横幅之后，正文立即以严重性计分板开头——在同一行内列出分类后的计数，计数置于标签前（绝不要使用 Markdown 表格；见 templates/_OUTPUT.md）：

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

依赖风险总数及任何生命周期终止标记都留在开头的横幅中——不要在此处重复。

然后按影响程度列出发现：

1. 已确认可利用的安全问题（支付控制器中的 IDOR 优先级最高）。
2. 应用实际使用路径中可触达的 CVE。
3. 高变更频率 × 高复杂度的质量热点（每周都在变更的臃肿模型，优先于理论性警告）。
4. 经过分诊但缺乏已证实利用路径的理论性安全警告。
5. 其余质量问题，按严重程度从高到低排列。 让每条发现都简洁易读，用朴实的语言表达。 问题和解决方案要让非专业相关方和疲惫的资深工程师都看得懂——用日常词语，不要提方法名或行号。开头用一句标题概括：严重程度 + 问题是什么，使用通俗语言（不要写发现编号或工作量估算）。接着用通俗语言描述问题，并给出具体的修复办法。把技术细节——方法名、行号、可利用的攻击路径，以及变更量／复杂度指标——放进可选的 Technical details 字段（参见 templates/_OUTPUT.md）；没有具体证据可列的发现就省略此字段。只有在几行代码比文字更快说明问题时才展示代码。不要写多段式的攻击利用长篇说明：资深工程师应该能在几秒内看懂每条发现，并知道下一步该做什么。问题反复出现时，引用最有代表性的 2–5 个 file:line 位置，并注明“另有约 N 处类似问题”，不要列出所有实例。按 Rails 的风格写——友好、直接、不讲排场。不要输出模板标签（“状态横幅”“发现”）；让报告自然展开。

最后给出计划，让读者知道下一步该做什么（开头的概览已经在正文顶部铺垫了重点）：

1. 立即修复——按杠杆效应排序：以最小的改动消除最大的风险或技术债，而不只是看影响大小。已确认的严重问题，以及影响重大且容易快速修复的问题（例如升级版本、修改一行配置）都应列在这里；范围广、风险高的结构性改动即使影响重大，也应放到接下来修复。不要估算时间——修复所需时间取决于团队和工具；用文字描述范围和影响面。排序时依次考虑：能为其他工作扫清障碍的事项（建立验证基线、编写特征测试）优先；高置信度的安全问题优先于杠杆效应相当的非安全问题；优先选择有明确验证方式的修复。每项用一行简洁表述，格式为“对象 + 行动”——列出“如果只做其他事情都不做，也要做这些”的事项。
2. 接下来修复——简洁归纳其余高／中优先级问题。
3. 最大的结构性增益——用一行点明一次性消除最多风险或技术债的那项重构。

如果扫描器报告了你排除的问题，要说明——但只在接近末尾处用一行简洁列出（写出问题名称，并为每项标注一个原因：误报／无法触达／仅开发环境／目标错误），不要另设冗长章节。让读者知道你检查并排除了误报，而不是漏掉了它们。

报告内容敏感。 报告列出了仍然存在且已确认的漏洞及其攻击路径——它应交给有权限修复应用的人，而不是公开的问题跟踪器或开放频道。如果要在共享或公开的地方发布发现，先删去安全细节（攻击路径、凭据位置）。

整份报告应像首席工程师交付的行动计划，而不是工具输出。