安全评审收尾时把已确认漏洞和利用链汇总为面向干系人的…

在 Mantis 安全评审周期末尾，基于 findings 和 archive 状态生成按 pass 与快照标记的可读安全报告。

适用场景

解决思路

1. 通过 `/mantis-report` 命令执行报告阶段，生成包含 confirmed findings 和 exploit chains 的人类可读安全评审包。
2. Reporter 作为 FINDINGS-ONLY 阶段运行：跳过 locator resolution 的步骤 2–6，不要求或解析 CODE_ROOT，不因 code root 或 sentinel 未设置而停止。
3. 仍从 `workspace/.mantis_state.json` 读取 `active_snapshot`（`root`、`snapshot_id`、`snapshot_pinned`）和 `vcs_info`，用于构建报告头、顶部 banner 和输出文件名。
4. Reporter 接触的每个路径（`workspace/findings/*.json`、`workspace/.mantis_state.json`、`workspace/report/*`、`workspace/archive/*`）都是 STATE-RELATIVE，绝不加 CODE_ROOT 前缀。
5. 加载 findings：本 pass 全量 + carried-forward open findings，使用 newest-first fold，不用脚本；按 finding identity 构建 working set，每个 finding 只保留最近状态一次。
6. 应用 SAME-BUG PREDICATE：两个 finding 只有在 EITHER (i) 完全相同 `id` UUID；OR (ii) 三者同时满足——共享非空 `lineage_id`、共享非空 `signature`、至少一个 `code_paths` 条目带尾随 `:line` 且完全一致时，才视为同一 bug；否则视为不同并都渲染。
7. 绝不可只凭 `lineage_id` 单独或 `signature` 单独判定同一 bug。
8. 理解 re-anchoring vs fold：`mantis-plan` 的 re-anchoring 仅提供 line hint 来引导 RE-DISCOVER，不重写 carried finding 的 `code_paths`；重发现会出现在当前快照的新行，因 fold 要求 line-inclusive `code_paths` 匹配，不会与 ancestor fold；这是安全 over-reporting，两者都渲染；未来可放宽为 path-only 当两者同 `signature` 和 `lineage_id` 且 ancestor 行确认不存在，但当前保守使用 line-inclusive 防止静默丢失。
9. 读取所有 active `workspace/findings/*.json`，把每个 active finding 按 `id` UUID 加入 working set；保留所有 remediation status，使本 pass 的 `VERIFIED_SECURE`/`MITIGATION_PROPOSED` 修复仍能在 Category 1/2 带补丁渲染；绝不合并两个 active findings，即使共享 `lineage_id` 或 `signature`。
10. 扫描 `workspace/archive/findings_pass_<N>/`（以及 legacy `loop<N>_findings/`），按 pass 降序；仅当 archived finding 仍 OPEN（按 open predicate）、且 working set 中没有 finding 与它 SAME BUG、且没有更早（更高 pass）同 bug 副本已加入时，才加入；第一个遇到的是最新状态；忽略更低目录中 later same-bug copies。
11. Supersession fold (Phase 3)：当 archived finding 与 current finding 是 SAME BUG（predicate ii）时，current supersedes，只显示 current 最近状态；当 predicate 不满足（不同 `signature`，如文件重命名，或 `lineage_id` 缺失）时，两者作为分开条目渲染，安全 over-reporting，绝不隐藏。
12. Under-reporting safeguard：如果 current（superseding）finding 未通过 actionable predicate，但 archived ancestor 通过（例如 ancestor 是 `reproduced` 且 OPEN，但 current pass 的 reproduce 因新快照上的临时 build/env 失败变为 `not_attempted`），不要让临时降级压制 confirmed-open bug；保留 ancestor 最后确认状态可见，标注 `Open — repro pending on new snapshot`；current 的新 metadata（如更新后的 `code_paths` 行号）可作为 annotation 附加，但 verdict/status 必须显示 ancestor 最后确认状态，绝不显示临时降级。
13. Actionable/quality predicate（适用于 active 和 archived）：仅包含 exploit chain（存在 `constituent_findings`，或 title/history 含 `Exploit Chain`）或 `repro_status` 为 `reproduced`，或 `repro_status` 为 `statically_confirmed` 且带 empirical execution evidence（外部 stack trace、sanitizer trace（ASan/UBSan/MSan/TSan）或 crash log）。
14. 不包含 false positives、`NON_VIABLE`、`DUPLICATE`、`failed_to_reproduce`，或缺少 empirical traces 的普通 `statically_confirmed` findings。
15. Open predicate（仅用于 step 2 的 archived carry-forward）：archived finding 仍 open 当它满足 actionable predicate 且 `patch_status` 不是 `VERIFIED_SECURE`/`MITIGATION_PROPOSED` 且 `status` 不是 `FALSE_POSITIVE`/`DUPLICATE` 且 `production_viability` 不是 `NON_VIABLE`。
16. Active findings 无论 `patch_status` 都加载，以便本 pass 修复仍出现；archived fixed findings 不每 pass 重列——使用可选 `Resolved this campaign` rollup 提供累计 fixed 视图。
17. 报告是 campaign-wide 视图：报告本次及任何 prior pass 发现的每个 unresolved finding 的当前状态，按每个 finding 最新状态去重；confirmed-but-unfixed 且 plan 停止携带的 finding（例如达到 2-attempt retry cap）不会消失，而以其最近 archived 状态出现。
18. Scale：一次处理一个目录，newest-first；绝不一次加载整个 archive。
19. Severity Filtering：从主报告正文排除 priority 为 `LOW` 的 findings；必须把它们放到报告最后单独的 `Appendix: Low Priority Findings` 节，保持主体聚焦高风险。
20. 对每个 reproduced finding 提取 Key Artifacts：Header Metadata：Title、ID（UUID）、Inferred Exposure、Final Risk Score、Qualitative Priority。
21. Campaign Provenance：对每个 open finding 标注首次发现 pass vs 当前 pass（例如 `discovered pass 2 · still open as of pass 7`）；First-seen = finding 的 `history` 条目中最低 `pass_number`（或包含它的最低编号 archive dir）；current state = 上述 fold 保留的副本。
22. Duplicate Advisory：如果 finding 有 `possible_duplicate_of` 字段（由 `mantis-dedupe` 在 cross-pass candidate NOT_MATCHED 时设置），发出 advisory：`Possibly related to finding <UUID> (cross-pass candidate; snapshots differ — not confirmed duplicate).`
23. Discovery Snapshot：输出 `Discovery Snapshot: <discovery_commit>`；如果 `discovery_commit` 缺失或空，输出 `Discovery Snapshot: (legacy — not recorded)`；绝不因该字段缺失而省略或丢弃 finding。
24. Vulnerability Description & Impact：清晰解释 bug 及对系统的具体影响。
25. Reproduction Evidence：PoC 脚本路径（`repro_file_path`）和执行命令（`run_command`）；展示 stdout/stderr 干净片段，显示成功 exploit trigger（`repro_output`）。
26. Reproduction Evidence 的 Evidence base：用收集证据的快照标注：`Evidence base: <repro_snapshot_id>`；如果 `repro_snapshot_id` 缺失或空，写 `Evidence base: (not recorded)`；不要假设它等于 header/pass snapshot。
27. Risk Rationale：独立验证推理（`reasoning`）、生产可行性推理（`critic_reasoning`）、outrage factor 分析（`outrage_commentary`）。
28. Remediation & Patch：推荐 mitigation strategy；verified patch diff（`patch_diff`）和 re-attack status 以证明修复 resilient。
29. Remediation & Patch 的 Apply against：用补丁适用快照标注：`Apply against: <patch_base_snapshot>`；如果缺失或空，写 `Apply against: (not recorded)`；如果 `patch_base_snapshot` 存在且不同于 finding 的 `discovery_commit`，加一行 caution：diff 是针对不同快照生成的，可能不能干净应用到 discovery snapshot。
30. PII & Secrets Redaction：写任何 finding 数据（包括 description、PoC script/command、reproducer logs）到报告前，必须扫描并 redact 硬编码 API keys、tokens、credentials、PII（姓名、邮箱、电话）、内部 hostnames/domain names、过度 weaponized payload parameters，替换为 `<REDACTED_SECRET>`、`<REDACTED_PII>`、`<REDACTED_INTERNAL_HOST>`、`<REDACTED_PAYLOAD>` 等标准占位符，确保报告可安全广泛分发。
31. Generate Review Packet 的 Report Header & Disclaimer：在报告最顶部（Executive Summary 之前）添加。
32. Snapshot provenance banners：在 item 1 之前、报告最顶部，每个作为独立 blockquote，按 a、b、c 顺序输出。
33. a. Non-authoritative / HALT banner（3-state rule）：从 `workspace/.mantis_state.json` 读取 `active_snapshot`。如果 `active_snapshot` 缺失（MODE-OFF——未请求 `--sync`，当前默认）：不输出此 banner；运行与现有行为一致，`VERIFIED_SECURE` 等 verdict 有效；此处输出 NON-AUTHORITATIVE 会与同一运行 verdict 矛盾。如果 `active_snapshot` 存在但 `snapshot_pinned` 为 `false`（HALT mode）：作为报告第一行输出警告“目标未能固定到不可变快照...（HALT mode: tree raced 或 too big/live/copy-failed）。Findings 可能不对应稳定可复现树，报告中没有 findings 不代表目标安全。所有结果视为 provisional。” 当 `active_snapshot` 缺失（MODE-OFF）或 `snapshot_pinned` 为 `true`（PINNED）时省略。
34. b. Dirty working tree warning：如果 `vcs_info.dirty` 为 `true`，输出警告“目标在被扫描时有未提交本地修改。结果反映该确切 working tree（由 content hash 捕获），不是干净提交 revision。仅记录 commit 不能复现该状态。”
35. c. Mixed-snapshot banner：令 `HEADER_SID` = `active_snapshot.snapshot_id`。如果 `HEADER_SID` 存在且非空，且任何 INCLUDED finding 的 `discovery_commit` 缺失、空、或与 `HEADER_SID` 字符串不完全相等，输出警告“此报告合并了在不同代码快照上发现的 findings（例如从早期 pass 重试的 findings）。pass snapshot 是 <HEADER_SID>。行动前查看每个 finding 的 Discovery Snapshot；行号和代码上下文可能因快照不同。” 仅精确字符串比较 snapshot ID——不要 fuzzy 或 prefix match。
36. 显示从 `workspace/.mantis_state.json` 的 `vcs_info` 读取的 target codebase version：如果 `vcs_type` 是 `git`，显示 `Target Version: Git branch [branch] at commit [commit_hash] [(dirty) if dirty is true]`；`hg` 显示 `Target Version: Mercurial branch [branch] at revision [commit_hash] [(dirty) if dirty is true]`；`multi-vcs` 显示 `Target Version: Multi-VCS (repo) manifest [revision] [(dirty) if dirty is true]`；`none` 显示 `Target Version: None (No version control detected)`；`unknown` 或 `vcs_info` 缺失显示 `Target Version: Unknown (VCS detection failed/error)`。
37. 在 `Target Version:` 行后追加 pass snapshot identity 第二行：如果 `active_snapshot.snapshot_id` 存在且非空，写 `Snapshot ID: [snapshot_id] (pinned: [snapshot_pinned])`；如果 `active_snapshot` 缺失或 `snapshot_id` 空，写 `Snapshot ID: (legacy — snapshot not recorded)`；这仅展示 provenance，不 gate 或丢弃任何 finding。
38. 包含醒目 disclaimer：说明“本报告由 Mantis AI 自动生成。所有 findings 和 patches 均为 AI 生成，部署或披露前必须由安全或领域专家人工验证。”
39. Grouping by Patch Status（Exclusivity）：Executive Summary table 和报告主体按 grouping findings。Exploit chains 必须从这些主组排除，只在专用 `Exploit Chains (Not End-to-End Reproduced)` 节报告。标准非链 findings 按 remediation status 分三互斥类别：Category 1: Patch Independently Verified：`patch_status` 为 `VERIFIED_SECURE`。Category 2: Patch Proposed / Mitigation Identified：`patch_status` 在 `[MITIGATION_PROPOSED, VERIFICATION_INCOMPLETE]` 或（`patch_diff` 存在且 `patch_status` 未设置/空）。Category 3: Unpatched / Verification Failed：`patch_status` 在 `[VERIFICATION_FAILED, ERROR]` 或（`patch_diff` 不存在且 `patch_status` 未设置/空）。
40. Dedicated Exploit Chains Section：创建标题为 `Exploit Chains (Not End-to-End Reproduced)` 的专用节，仅用于 exploit chains；记录每个 chain 的 title、qualitative priority、risk score，并详述其 constituent findings（IDs 和 individual status）；不要与 Categories 1、2、3 混。
41. Pass-Numbered Output：不要每次执行覆盖同一个 `review_packet.md`。确定当前 run/pass number `N`：从 `workspace/.mantis_state.json` 中 `pass_number` 解析；如果缺失或无效，扫描 `workspace/archive/` 匹配 `findings_pass_N` 或 `loopN_findings` 的文件夹，解析 `N` 为 `max_found + 1`，若不存在 archive 则默认 1。
42. 从 `active_snapshot.snapshot_id` 派生 `<snapshot_tag>`：取 snapshot ID 原样，替换每个不在 `[A-Za-z0-9.-]` 的字符为单个下划线 `_`；不要截断（结果远低于任何文件名长度限制）。
43. 当 `active_snapshot.snapshot_id` 存在且非空，写报告到 `workspace/report/review_packet_pass_<N>_<snapshot_tag>.md`（例如 `review_packet_pass_1_content_9f86d081884c...md`）；`<snapshot_tag>` 后缀保证重用的 pass number 在不同 snapshot 上写不同文件，不能覆盖早期 packet。
44. 当 `active_snapshot` 缺失或 `snapshot_id` 空，写报告到 `workspace/report/review_packet_pass_<N>.md`（无后缀，完全 legacy 名），保持向后兼容行为。
45. Latest Copy/Symlink：写完上述 pass-numbered 报告后，更新 symlink 或写一份该确切文件（无论是否带 `<snapshot_tag>` 后缀）的副本到 `workspace/report/review_packet-latest.md`，使最新版本始终可达；`review_packet-latest.md` 名称不变，仍是下游消费者的稳定入口。
46. 使用干净、专业 Markdown 格式：清晰 headers、metadata tables、logs 和 diffs 的 syntax-highlighted code blocks。
47. 在顶部包含高层 Executive Summary table，列出所有 included findings、priority 和 risk scores。
48. Optional sections（推荐）：Resolved this campaign：使用同一 fold 的短 rollup，但过滤 `patch_status` 为 `VERIFIED_SECURE` 或 `MITIGATION_PROPOSED`；给 stakeholder 一个可见的 what got fixed 视图，与 open findings 并列。
49. Optional sections（推荐）：Unresolved — retry cap reached：callout 列出 open findings 的 reproduction attempt count 达到 cap。count 不是 finding JSON 字段；在 cache file `state_root/workspace/archive/.repro_attempts.json`，按每个 finding 的 `signature`（如果 `signature` 缺失，按 computed `stable_key` = `normalized_title + “@” + primary_file_path`——与 `mantis-reproduce` 相同 key selection）为 key。对 working set 中每个 open finding，在 cache 中查其 `signature`（或 `stable_key` fallback）；如果 cached value 达到 retry cap，则包含在 callout。按 schema value-shape 读取：裸整数 V 表示 `{count: V, last_snapshot: UNKNOWN}`；object 表示 `{count: V.count, last_snapshot: V.last_snapshot or UNKNOWN}`。如果 cache 文件缺失或 finding 的 key 缺失，count 视为 0（不列在此处）。这些是 planner 停止携带的 items。
50. De-dup caveat NOTE：de-dup 按 finding identity，按 stage 顶部 SAME-BUG PREDICATE：两个 findings 仅当 EITHER (i) 完全相同 `id`（UUID），OR (ii) 三者都满足——共享非空 `lineage_id`、共享非空 `signature`、至少一个 line-inclusive `code_paths` match，才 fold。绝不可只凭 `lineage_id` 或只凭 `signature` fold；basename-derived lineage 可连接两个不同同名文件，`signature` 去掉行号会在同文件不同 bug 间碰撞，单独折叠可能静默丢真 finding。一个用新 UUID 重发现但不满足 predicate ii 的 bug——回归、文件重命名导致行偏移、非确定性 re-find——作为与其 archived ancestor 分开的条目列出：over-reporting（安全），绝不隐藏。With stable finding signatures and lineage tracking landed（Phase 3），重发现 finding 仅当 predicate ii 完全满足才 fold 到 ancestor 单条目；UUID-only match 仍是 legacy/un-upgraded findings 的安全分支。
51. `review_packet-latest.md` is authoritative：注意 `review_packet-latest.md` 现在是整个 campaign 的权威当前 open state（不只是最新 pass）。每 pass `review_packet_pass_<N>_<snapshot_tag>.md` 文件保留原样供历史参考。

适用边界 · 注意事项

• 不用于审计代码或直接验证补丁。
• 不适用于没有校准并复现的 findings 存在的情况（`workspace/findings/` 或 `workspace/archive/`），此时报告没有可靠输入。
• 不适用于把 AI 生成报告当作最终结论；所有 findings 和 patches 必须由安全/领域专家人工验证后才能部署或披露。