redink 是一个基于 Claude Code 的渗透测试报告自动化流水线，通过模块化段落组合与多层引用验证机制，帮助安全团队快速生成符合 17+ 合规框架且每个 CWE/CVE/CVSS/EPSS 引用均可追溯的提交级报告。
# redink
**为 17+ 合规框架组合包含 28 个模块化部分的渗透测试报告。**
一个开源的 Claude Code pipeline。放入 PoC 截图，选择你的部分，即可获得一份经过验证且可直接提交的报告。
[](LICENSE)
[](https://code.claude.com)
[]()
[快速开始](#quick-start) · [支持的框架](#supported-frameworks) · [部分](#section-library) · [用户流程](#user-flow) · [免责声明](DISCLAIMER.md) · [安全](SECURITY.md)
## `redink` 能做什么
渗透测试会产生测试发现。每个合规框架都要求将这些发现包装在包含特定部分、特定格式以及经过验证的 CWE/CVE/CVSS/EPSS 引用的报告中。
`redink` 是一个**模块化 pipeline**，允许你从 28 种可复用的部分类型中组合出该报告——精确挑选你的框架（或你的公司）所需的页面。验证器（MITRE 上的 CWE、NVD 上的 CVE、依据 FIRST.org 的 CVSS、实时 EPSS）在每个框架中的运行方式完全相同。只有报告的外壳包装会有所不同。
## 为什么选择 redink
### 时间算术
一份包含 300 个发现的渗透测试报告——这在中型企业审计和大多数国家授权的测试平台中很典型——每个发现大约有如下的**手动工作量**：
| 每个发现的任务 | 手动时间 |
|---|---|
| 在 MITRE 查找 CWE；验证 Usage = ALLOWED / ALLOWED-WITH-REVIEW | ~3 分钟 |
| 在 NVD 查找 CVE；提取准确引用的受影响版本范围 | ~5 分钟 |
| 根据 vector（依据 FIRST.org 规范）计算 CVSS v3.1 base score | ~3 分钟 |
| 在 `api.first.org/data/v1/epss` 查找 EPSS 概率 | ~1 分钟 |
| 编写描述（≤ 80字）、建议、参考 | ~5–10 分钟 |
| 整理到框架模板中——字段、内嵌截图、标题 | ~3–5 分钟 |
| **每个发现总计** | **~20–30 分钟** |
对于**300 个发现，这意味着大约 125 小时**纯单次发现的引用与排版工作。再加上第一部分的叙述 + 人力/标准/工具表格 + 汇总发现表 + QA + 交叉引用修复过程，整个项目你将花费 **~140–160 小时**。
大多数公司会在 5 天的交付期内安排 3–5 名高级审计员来承担这项负荷。到了第二天，疲劳感就会开始出现。到了第四天，引用的拼写错误和错误的版本范围就会开始漏网。
**`redink` 的预期工作量——同样针对 300 个发现的项目：**
| 阶段 | 实际耗时 |
|---|---|
| 一次性设置：填写 `brand-guidelines.md` + `targets.yaml` + `engagement-summary.md` | ~1–2 小时 |
| `/redink-recipe` — 28 个是/否部分问题 | ~5–10 分钟 |
| `/redink-build` — 20 个并发 sub-agents 并行请求 MITRE / NVD / FIRST.org | 处理 300 个发现**~1 小时** |
| 对抗性 QA 过程（`report-reviewer` 独立重新获取每个引用） | ~30–60 分钟 |
| 人工审查组装好的输出（仍由高级审计员签字） | ~3–5 小时 |
| 最终 docx 润色 + 公司模板整合 | ~1–2 小时 |
| **总计** | **~7–10 小时** |
### 渗透测试人员的心理
渗透测试人员和安全审计员拥有一种特定类型的大脑。正是那种富有创造力、善于发散思维、敢于打破常规的思维模式，能够发现权限提升链和意想不到的 IDOR，这正是他们价值的最初来源。
**这种大脑是处理长达数小时的 MITRE 查找、NVD 版本字符串复制粘贴和 Word 表格排版的最糟糕工具。** 这就像让一位主厨洗六个小时的盘子。他们*可以*做到，但是：
- 花在查找上的每一分钟，意味着他们的创造力引擎就有一分钟没有运转
- 经过 4-5 个小时的重复引用工作后，疲劳感开始吞噬准确性
- 在手动任务的重压下，“我应该 pivot 并尝试 X”的直觉会渐渐消失
- 最深层次的漏洞——链式漏洞利用、业务逻辑缺陷、后渗透（post-exploitation）的创造力——正是当分析师精神耗尽时最容易首先流失的东西
`redink` 接管了这些繁琐的工作。渗透测试人员可以将他们的时间花在真正需要动脑的部分：
- 漏洞利用链
- 意想不到的攻击路径
- “如果我把这两个发现结合起来会怎样？”的时刻
- 真正的业务影响分析（而不是套话）
- 下一个项目（因为这份报告在第二天的午餐时间就能完成，而不是等到第五天）
只要合规报告存在，审计公司就一直让他们最优秀的技术人员做文书工作。`redink` 让你得以停止这一切。
### 错误问题（以及为什么在此处自动化会胜出）
手动报告存在可衡量的错误类别——每一位高级审计员都曾在他们团队的报告草稿中见过以下每一种情况：
| 错误类别 | 手动操作时发生的情况 | `redink` 的处理方式 |
|---|---|---|
| **CWE Usage 不匹配** | 当 MITRE 将 `CWE-287` 标记为 DISCOURAGED 时，却引用为 ALLOWED → 协调员拒绝 | `cwe-validator` 在接受前获取 MITRE 信息；已知的不良列表（CWE-200, CWE-269, CWE-284, CWE-285, CWE-287, CWE-693, CWE-1187）会被自动拒绝 |
| **CVE 版本范围错误** | 声称目标版本 1.0.2u 受到已在 1.0.2t 修复的 CVE 影响 → 协调员拒绝 | `cve-validator` 获取 NVD 的精确受影响范围；存储准确引用的摘录以供重新验证 |
| **CVSS 计算错误** | vector 标明为 `AC:H`，但数学计算时却按 `AC:L` 进行 | `cvss-calculator` 展示每个发现的 ISC / Impact / Exploitability / Base 计算 |
| **过时的 EPSS** | 两周前查找过；当前概率已发生实质性变化 | `epss-lookup` 针对每个发现实时获取，并记录查找日期；如果数据超过 7 天，QA 过程要求重新获取 |
| **空白字段** | 在截止日期的压力下留空了单元格 → 被强制执行“不留空”规则的框架自动拒绝（如 CMMC C3PAO 记分卡、PCI DSS ROC、CHECK 报告、CERT-In） | 如果必填字段为空，Assembler 拒绝渲染 docx；如果输入文件中存在 `<...>` 占位符，`/redink-build` 将无法启动 |
| **严重性不一致** | 同一漏洞被一名团队成员评级为 High，另一名评级为 Medium | 对所有发现应用单一确定的基于 CVSS 推导出的严重性标准 |
| **引用捏造**（LLM 时代） | 看似合理但虚构的 CVE 编号或 MITRE 描述 | 每个条目的 `cwe_cve_audit` 字段都会存储来自 MITRE / NVD / FIRST.org 的精确引用摘录；`report-reviewer` 会在提交前独立重新获取并进行字符串比较 |
**规则强制执行分为三层，而不是一层：**
1. **验证器 agents** —— 在写入时拒绝无效引用
2. **Assembler** —— 如果必填字段为空，拒绝渲染 docx
3. **`report-reviewer`** —— 对抗性重新获取过程；标记草稿与提交版本之间的任何偏差
没有哪一层是单一的安全机制。写入后的重新验证正是为了捕获 writer agents 未能注意到的 LLM 幻觉。每个发现上的审计追踪字段允许评估者（或审查时的你）重新获取权威来源并进行独立验证——这也是 CMMC C3PAOs、CHECK Team Leaders、PASSI auditeurs、PCI QSAs、IRAP assessors、BSI auditors 和 CERT-In coordinators 在他们各自的复查中并行运行的工作流。
结果就是：一份**每一个引用的参考资料都可追溯、每一个分数都可展示、每一个必填字段都已填写**的报告，并且没有任何由疲劳导致的拼写错误混入提交版本中。
## redink 的服务对象
`redink` 为每一个生成渗透测试报告的团队而建——无论其驱动力是**监管要求**（CMMC、SOC 2 attestation、ISO 27001、NIS2、DORA、RBI、MAS-TRMG、SAMA CSF、KISA ISMS-P、CERT-In 等）还是**商业信任**（客户尽职调查、M&A 安全 DD、网络保险承保、供应商风险问卷、内部红队演练、漏洞赏金项目汇总）。验证器链和部分组合是完全相同的；每次项目只有框架的外壳包装会改变。
| 细分市场 | 示例（全球范围内的受监管及私有驱动力） | 报告数 / 公司 / 年 | 全球覆盖范围 |
|---|---|---|---|
| **四大 / 全球咨询公司** | Deloitte, EY, KPMG, PwC —— 网络安全与审计部门同时开展受监管业务（CMMC C3PAO 评估、ISO 27001 审计、SOC 2 attestations、CHECK 项目、PCI ROC）以及私有业务（客户 DD、M&A、供应商风险、内部审计），业务遍布各自的 50+ 国家办事处 | 500–2,000 | 4 家公司 × ~50 个国家办事处 = **~200 个网络安全业务单元** |
| **纯实战型网络安全精品公司** | Mandiant (Google Cloud), Bishop Fox, NCC Group, NetSPI, Coalfire, IOActive, Trustwave, Synack, Synopsys SIG, F-Secure / WithSecure, Praetorian, Kudelski Security, Aon Cyber Solutions, GuidePoint Security；SISA, Aujas, Kratikal, Astra Security | 100–500 | 全球 **~1,000+ 家**纯实战型公司 |
| **IT 服务商的网络安全部门** | Accenture Security, Capgemini, Atos, NTT Security, DXC, Cognizant Security, Fujitsu Cyber；TCS Cyber, Infosys, Wipro, HCL CyberSecurity, Tech Mahindra | 200–800 | 拥有完整网络安全服务臂的 **~50 家主要公司** |
| **政府授权的审计公司**（同时也做私有业务——资质是一种凭证，而非范围限制） | NCSC CHECK Green-Light (英国) · Cyber AB 旗下的 C3PAOs (美国) · CREST 会员公司 (国际) · PASSI auditeurs (法国) · BSI auditors (德国) · IRAP assessors (澳大利亚) · KISA 注册 (韩国) · ISMAP 列表 (日本) · CSA 批准 (新加坡) · NESA 认证 (阿联酋) · 通过 Haseen 获得 NCA 许可的 CSPs (沙特) · FSTEC 许可 (俄罗斯)；CERT-In empanelled (印度) | 50–300 | redink 支持的 17 个体系下共计 **~2,500+ 家公司** |
| **受监管实体的内部红队** | 银行（遵循 FFIEC / FCA / BaFin / FINMA / MAS / OSFI / APRA / RBI / SAMA）、保险公司（NAIC / EIOPA / IRDAI）、交易所（SEC / FCA / FINMA / MAS / JFSA / NSE）、遵循 DORA / NIS2 / SOCI / KRITIS / CNI / CIKR / NCIIPC 的关键基础设施运营商 | 50–200 个内部 | 拥有正式红队职能的 **~5,000–10,000 家受监管实体** |
| **私有企业的内部红队**（客户信任 + 内部驱动力，无监管要求） | 超大规模云服务商及 SaaS（Google、Microsoft、AWS、Meta、Apple、Stripe、Cloudflare、Atlassian、Shopify、GitLab、Snowflake、Datadog、MongoDB）· 金融科技（Coinbase、Block、Klarna、Revolut、Wise、N26、Razorpay）· 电信（Vodafone、Orange、Deutsche Telekom、NTT、KDDI、Telstra、AT&T、Verizon）· 国防巨头（Lockheed Martin、Boeing、BAE Systems、Thales、Saab、Mitsubishi Heavy、Hanwha）· 制药（Pfizer、Roche、Novartis、Astraeca、GSK、J&J、Bayer）· 零售（Walmart、Target、Carrefour、Tesco、IKEA、Ahold Delhaize）· 能源（BP、Shell、TotalEnergies、Saudi Aramco、Equinor）—— 推动 SOC 2 + ISO 27001 attestation、客户 DD、M&A 安全、网络保险、内部红队演练 | 30–200 个内部 | 拥有正式红队职能的 **~3,000–5,000 家私有企业** |
| **独立顾问 + 小型咨询公司 + 漏洞赏金从业者** | 独立漏洞赏金猎人（HackerOne / Bugcrowd / Synack / Intigriti / YesWeHack 顶尖排名者）、自由职业渗透测试人员，遍布每个网络安全中心的 2–5 人小店（特拉维夫、伦敦、柏林、班加罗尔、首尔、新加坡、悉尼、圣保罗、东京、多伦多、阿姆斯特丹、迪拜、旧金山、波士顿） | 10–50 | 全球 **~100,000+ 名独立从业者** |
**全球潜在市场：** 每年生成合规/客户信任/内部渗透测试报告的 **~120,000+ 家组织** + 庞大的独立从业者长尾市场。据估计，全球所有细分市场每年合计生成 **3–1000 万份渗透测试报告**。
上表中“受监管”与“私有”之间的划分只是描述性的，而非架构上的区别——大多数团队两者都做。四大的一次网络安全项目可能在某个季度是 SOC 2（私有信任），而在下一个季度是 CMMC C3PAO 评估（监管要求）。Stripe 的内部团队持续运行 SOC 2 + PCI DSS + 内部红队；而一家德国银行的团队则并行运行 BaFin + NIS2 + 客户 DD 渗透测试。**redink 能够服务于他们中的每一个**——相同的验证器链，相同的单次发现严格度，每次项目采用与框架相适应的外壳。
## 支持的框架
17 种框架预设——每一种都是位于 [`frameworks/
/manifest.yaml`](frameworks/) 下的配方。在 [`framework.yaml`](framework.yaml) 中挑选一个。
排序大致依据各市场授权/认可的测试人员库规模——北美和西欧引领着全球网络安全咨询产业，表格的顺序也遵循这一重心。
| # | 框架 | 地区 | 受众 |
|---|---|---|---|
| 1 | **CMMC Level 2/3 FAR** | 🇺🇸 美国 | 由 Cyber AB 旗下 C3PAOs 评估的 DoD 承包商 |
| 2 | **PCI DSS ROC v4.0** | 🌍 全球（卡片行业） | PCI SSC QSAs / ISAs |
| 3 | **NCSC CHECK** | 🇬🇧 英国 | NCSC CHECK 认证的 Green-Light 测试人员（HMG, CNI） |
| 4 | **CREST CDPT** | 🇬🇧 英国 / 🌍 全球 | CREST 认证的会员公司 |
| 5 | **ANSSI PASSI** | 🇫🇷 法国 | ANSSI 认证的 PASSI auditeurs（4 种审计类别） |
| 6 | **BSI IT-Grundschutz** | 🇩🇪 德国 | BSI 认证的审计员（BSIG / KRITIS 运营商） |
| 7 | **Switzerland NCSC / FINMA** | 🇨🇭 瑞士 | 符合 NCSC 标准的测试人员；针对受监管银行的 FINMA |
| 8 | **Israel INCD ICDM 2.0** | 🇮🇱 以色列 | INCD 列出的评估员（银行、电信、医疗保健） |
| 9 | **UAE NESA / SIA IAS** | 🇦🇪 阿联酋 | NESA 认证的评估员 |
| 10 | **Saudi NCA ECC / CCC / OTCC** | 🇸🇦 沙特阿拉伯 | NCA 许可的 Cybersecurity Service Providers |
| 11 | **IRAP** | 🇦🇺 澳大利亚 | ASD 注册的 IRAP 评估员 |
| 12 | **K-ISMS-P (KISA)** | 🇰🇷 韩国 | KISA 注册的评估员（102 项标准） |
| 13 | **Japan ISMAP / NISC** | 🇯🇵 日本 | ISMAP 列出的审计公司 |
| 14 | **Singapore CSA CCoP 2.0** | 🇸🇬 新加坡 | CSA 认证的 CII 评估员 |
| 15 | **Russia FSTEC / FSB** | 🇷🇺 俄罗斯 | FSTEC 许可的评估员（КИИ / FZ-187） |
| 16 | **CERT-In** | 🇮🇳 印度 | CERT-In empanelled 审计员 |
| 17 | **OWASP OPTRS** (JSON) | 🌍 开放标准 | 机器可读的消费者（CI/CD, SOAR） |
每个预设都连接了**相同**的通用验证器（CWE / CVE / CVSS / EPSS 绑定至 MITRE / NVD / FIRST.org）。框架之间的区别仅在于部分列表、每个发现的字段结构、严重性标准以及签名/提交要求——所有这些都被编码在每个 `manifest.yaml` 中。
没有看到你的框架？组合你自己的配方——请参阅[§“构建你自己的配方”](#build-your-own-recipe)。
## 部分库
28 个通用部分位于 [`sections/`](sections/) 下。每一个都是一个自包含的区块，Assembler 可以将其放入任何报告中。
| # | 部分 | 常见于 |
|---|---|---|
| 01 | 封面 | 所有框架 |
| 02 | 文档控制 / 版本历史 | CMMC, NCSC CHECK, PASSI, PCI DSS |
| 03 | 执行摘要 | 所有框架 |
| 04 | 项目范围声明 | 所有框架 |
| 05 | 范围外声明 | CHECK, CREST, PCI DSS, 新加坡 |
| 06 | 测试方法论 | 所有框架 |
| 07 | 采用的标准与框架 | CERT-In, CHECK, PCI DSS, PASSI, BSI |
| 08 | 团队名单 / 技术人力 | CERT-In, CHECK, PASSI, CMMC, PCI DSS |
| 09 | 使用的工具、脚本与框架 | CERT-In, CHECK, CREST, PASSI |
| 10 | 风险评级方法论 | 大多数（除 IRAP 外） |
| 11 | 发现摘要（严重性计数） | 所有框架 |
| 12 | 关键观察与严重风险 | CERT-In, CHECK, PASSI, CREST |
| 13 | 汇总发现表 | CHECK §C-37e, CREST CDPT §10, PASSI, CERT-In |
| 14 | 单项发现详情 | 所有框架 |
| 15 | 控制矩阵 | CMMC, IRAP, PCI DSS, ISO 27001, NESA, NCA ECC, K-ISMS-P, BSI |
| 16 | 补偿性控制登记册 | PCI DSS |
| 17 | POA&M（行动计划与里程碑） | CMMC |
| 18 | 威胁态势 | BSI, INCD, NCA ECC, CMMC |
| 19 | 合规状态声明 | PCI DSS, BSI, K-ISMS-P, NESA, NCA ECC |
| 20 | 修复路线图 / 优先级矩阵 | CMMC, CHECK, CREST, PASSI, K-ISMS-P |
| 21 | 限制与免责声明 | 所有框架 |
| 22 | 参考资料 / 参考书目 | 所有框架 |
| 23 | 附录（原始扫描数据） | CMMC, CHECK, CREST, PASSI, IRAP, PCI DSS |
| 24 | 术语表 | CMMC, PASSI, BSI |
| 25 | 首字母缩写与缩略语 | CMMC, PASSI, BSI |
| 26 | 签字页 | CHECK, PCI DSS, CMMC, PASSI, IRAP |
| 27 | 事件报告对齐 | 瑞士 24 小时、日本 ACDA、欧盟 NIS2 |
| 28 | 持续监控证据 | K-ISMS-P（2026 年第三季度及以后）、INCD ICDM 2.0 |
## 快速开始
```
# 1. Clone
git clone https://github.com/AnshumanAtrey/redink.git
cd redink
# 2. Install as a Claude Code plugin
./install.sh
# 3. Pick your framework
$EDITOR framework.yaml # 17 presets — pick one
# 4. Pick your sections interactively
claude
> /redink-recipe # walks you through all 28 sections, asks Y/N
```
然后放入你的 PoC，填写 `brand-guidelines.md`、`targets.yaml` 和 `engagement-summary.md`，并运行 `/redink-build`。
## 用户流程
### 步骤 1 — 放入 PoC 截图
文件夹的名称将原样成为漏洞标题。拼写错误、空格、大小写混合都会被保留。
```
poc/
├── web/
│ ├── 01_WordPress_Plugin_Unauth_RCE/
│ ├── 02_phpMyAdmin_Default_Credentials/
│ └── 03_Apache_Server_Status_Exposed/
└── server/
├── 01_Tomcat_HTTP_PUT_Method_RCE/
├── 02_FTP_Anonymous_Read_Enabled/
└── 03_Outdated_OpenSSH_7.4/
```
请参阅 [`poc/EXAMPLE.md`](poc/EXAMPLE.md) 了解命名规范。
### 步骤 2 — 填写 brand-guidelines.md
公司名称、团队名单、方法论、工具、联系方式。与具体框架无关。
### 步骤 3 — 填写 targets.yaml
你测试过的主机。
### 步骤 4 — 填写 engagement-summary.md
三个简短的叙述部分：概述 · 发现摘要 · 关键观察与严重风险。这会驱动生成组装报告中执行摘要的部分。
### 步骤 5 — 选择一个框架
```
# framework.yaml
framework: owasp-optrs # one of 17 presets — pick any
```
### 步骤 6 — 选择部分
```
/redink-recipe
```
它会引导你浏览每个部分：“第 01 部分 — 封面。certin 的默认设置：ENABLED。是否包含？[Y/n]”。在回答了 28 个问题后，它会将你的选择保存到 [`report-recipe.yaml`](report-recipe.yaml) 中。
如果你愿意，也可以直接手动编辑 `report-recipe.yaml`。
### 步骤 7 — 运行
```
/redink-build
```
会发生什么：
1. 读取 `framework.yaml` + `report-recipe.yaml` + `brand-guidelines.md` + `targets.yaml` + `engagement-summary.md`
2. 遍历 `poc/web/` 和 `poc/server/`
3. 提出 3–5 个澄清问题
4. 为每个发现生成并行的 sub-agents：
- `cwe-validator` → 获取 MITRE 数据，拒绝 PROHIBITED/DISCOURAGED 的 CWE
- `cve-validator` → 获取 NVD 数据，确认受影响的版本范围
- `cvss-calculator` → 应用 FIRST.org v3.1 规范
- `epss-lookup` → 获取 `api.first.org/data/v1/epss` 数据
- `finding-writer` → 组合生成每个发现的 JSON
5. 对抗性 QA 过程 —— `report-reviewer` 独立重新获取每个引用
6. 组装 —— 在 `report-recipe.yaml` 中启用的部分将渲染为 `output/-report.docx`
### 步骤 8 — 审查
- 打开输出文件。每个发现都包含一个带有精确引用的 MITRE/NVD/EPSS 摘录的来源审计页脚。
- 迭代单个发现：`/redink-rebuild 015`
- 检查状态：`/redink-status`
- 切换框架：编辑 `framework.yaml` 并重新运行
## 性能与架构
`redink` 的存在是为了利用这样一个事实：合规报告的引用工作具有**极高的可并行性**——每个发现的 CWE/CVE/CVSS/EPSS 查找都独立于任何其他发现的查找。顺序查找是人类团队无法逃避的瓶颈；而并行的 agent 生成可以克服这一点。
### Agent 拓扑结构
```
/redink-build
│
┌──────────────┴───────────────────┐
│ │
finding-writer × 5 concurrent report-reviewer (adversarial QA)
│ (one per PoC folder) │
│ (re-fetches every cited
│ CWE/CVE/EPSS independently)
┌────┼────────┬──────────┬─────────┐
│ │ │ │ │
cwe- cve- cvss- epss- finding-writer composes
val. val. calc. lookup the final JSON entry
(MITRE)(NVD) (FIRST.org)(FIRST.org)
```
在高峰期：**5 个 finding-writers × 4 个验证器 = 20 个并发 sub-agents** 同时获取 MITRE、NVD 和 FIRST.org 数据。一个包含 300 个发现的项目将以大约 60 个批次并行运行，而不是大约 300 次顺序查找。
设置 5 个发现的限制是为了避免触发上游数据源的速率限制。如果你能接受 API 风险，则可以使用更高的并发上限；如果你想要更平缓的负载，则可以降低上限。
### 时间复杂度
| 模式 | 复杂度 | n=300 个发现 |
|---|---|---|
| **手动顺序执行** | `O(n × T_v)`，其中 `T_v` ≈ 12 分钟/发现（CWE 3分钟 + CVE 5分钟 + CVSS 3分钟 + EPSS 1分钟） | ~60 小时的纯引用查找工作 |
| **`redink` 并行执行** | `O(⌈n/5⌉ × T_v_parallel)`，其中 `T_v_parallel` ≈ 45 秒（4 个验证器并发运行） | ~60 个批次 × 45 秒 ≈ **~45 分钟** |
这种加速效果会不断累积：你拥有的发现越多，每个发现并行化带来的收益就越大——因为人工团队的协调开销呈线性增长，而并行生成 agent 则不会。
### 持续运行的内容
一旦你运行 `/redink-build`，该 pipeline 就不会停止，直到每个发现写入并且每个引用都被重新验证。在你去泡咖啡的时候：
- Sub-agents 获取 MITRE 数据，解析 Vulnerability Mapping Notes，存储 Usage 值
- Sub-agents 获取 NVD 数据，解析受影响版本字符串，与你的目标版本进行匹配
- Sub-agents 依据 FIRST.org 规范计算 CVSS v3.1 数学计算，展示每个指标的推理过程
- Sub-agents 获取实时 EPSS 概率并存储查找日期
- `finding-writer` 组合生成符合通用 schema 的单次发现 JSON
- `report-reviewer` 运行对抗性的二次检查，在干净的 shell 中独立重新获取所有内容
- Assembler 遍历 `report-recipe.yaml` 中启用的部分，依次渲染封面 → 执行摘要 → 表格 → 单次发现区块 → 参考资料
没有休息时间的妥协。没有“午饭后我再回来看这个发现”。该 pipeline 会一直运行直到完成。
## 通用验证规则
这些规则适用于**每一个**框架。它们由验证器 agents 强制执行。
| 规则 | 来源 |
|---|---|
| CWE 必须为 `ALLOWED` 或 `ALLOWED-WITH-REVIEW` | [cwe.mitre.org](https://cwe.mitre.org) |
| CVE 受影响版本范围必须与目标相符 | [nvd.nist.gov](https://nvd.nist.gov) |
| CVSS v3.1 指标需依据规范计算，并展示计算过程 | [first.org/cvss/v3.1](https://www.first.org/cvss/v3.1/specification-document) |
| 在查找日期根据 CVE 获取的 EPSS 概率 | [api.first.org/data/v1/epss](https://api.first.org/data/v1/epss) |
| 文件夹名称作为发现标题被精确保留 | 由 walker 强制执行 |
已知的 PROHIBITED / DISCOURAGED / Category CWE 列表（提交前在 MITRE 重新验证）：
- **PROHIBITED — 绝不可引用：** `CWE-1187`
- **DISCOURAGED — 替换为具体的子类：** `CWE-200`, `CWE-269`, `CWE-284`, `CWE-285`, `CWE-287`, `CWE-693`
- **Category 页面 — 不用于漏洞映射：** `CWE-254`, `CWE-264`, `CWE-388`
## 将 redink 与其他 AI 编码 agents 结合使用
`redink` 主要作为 Claude Code 插件构建（sub-agent 生成能带来最大的并行化收益）。但内容层——部分、框架 manifests、schemas、Python assembler——是**与具体 agent 无关的**。
要将 redink 与 Codex、Cursor、Gemini CLI、Aider、Kimi 或任何其他可读取 [`AGENTS.md`](AGENTS.md) 的 AI 编码 agent 结合使用：
1. 克隆本代码仓库
2. 该 agent 会自动读取 `AGENTS.md`（大多数现代 AI 编码 agent 都会这样做）
3. 使用独立的 Python 工具代替斜杠命令：
- `python3 scripts/recipe.py` — 交互式部分选择器（替代 `/redink-recipe`）
- `python3 scripts/recipe.py --non-interactive` — 静默接受所有框架默认设置
- `python3 scripts/assemble_docx.py` — 最终组装（在每个 agent 上都相同）
4. 对于单次发现的引用工作（CWE / CVE / CVSS / EPSS 查找），该 agent 会根据 `AGENTS.md` 中的规则直接获取 MITRE / NVD / FIRST.org 数据——与每个 agent 使用的权威来源相同
| 能力 | Claude Code | Codex / Cursor / Gemini / Aider / Kimi |
|---|---|---|
| 读取 CLAUDE.md / AGENTS.md | ✅ 两者皆可 | ✅ AGENTS.md |
| 斜杠命令（`/redink-build`, `/redink-recipe` 等） | ✅ 原生支持 | ❌ 不适用 — 使用 Python 等效替代方案 |
| Sub-agent 扇出（20 个并发验证器） | ✅ 原生支持 | 🟡 串行获取（速度较慢但可用） |
| Python recipe 选择器（`scripts/recipe.py`） | ✅ 也可在此运行 | ✅ |
| Python assembler（`scripts/assemble_docx.py`） | ✅ 也可在此运行 | ✅ |
| 28 个模块化部分 + 17 个框架预设 | ✅ | ✅ |
在 Claude Code 上体验最快（并行的 sub-agent 生成），但其他任何 agent 也可以借助 Python 辅助工具和 AGENTS.md 驱动相同的 pipeline。
## 构建你自己的配方
没有看到你的框架？或者你的公司有定制的报告格式？组合它：
1. 在 `framework.yaml` 中选择任何框架作为起点
2. 运行 `/redink-recipe` 并选择你想要的部分
3.（可选）通过直接编辑 `report-recipe.yaml` 来重新排序
4. 运行 `/redink-build`
如果你想将你的配置作为新的框架预设贡献出来，请提交一个 `frameworks//manifest.yaml` + `README.md` 并发起一个 PR。
## 命令
| 命令 | 作用 |
|---|---|
| `/redink-recipe` | 交互式部分选择器。生成 `report-recipe.yaml`。 |
| `/redink-build` | 完整的 pipeline。读取 recipe，验证发现，组装输出。 |
| `/redink-rebuild ` | 通过 ID 重新运行某一个发现。 |
| `/redink-status` | 显示进度 —— recipe 状态、发现计数、QA 报告。 |
| `/redink-frameworks` | 列出所有支持的框架及当前启用的框架。 |
### Python CLI 等效命令（适用于非 Claude-Code 的 agents）
| Python CLI | 替代 | 备注 |
|---|---|---|
| `python3 scripts/recipe.py` | `/redink-recipe` | 交互式部分选择器；不需要 LLM |
| `python3 scripts/recipe.py --non-interactive` | — | 静默接受框架默认设置 |
| `python3 scripts/assemble_docx.py` | `/redink-build` | 最终组装；单次发现的引用工作需由你的 agent 先完成 |
| `python3 scripts/assemble_docx.py --framework ` | — | 在运行时覆盖 `framework.yaml` 设置 |
| `python3 scripts/assemble_docx.py --only ` | `/redink-rebuild` | 仅包含单个发现重新进行组装 |
## 项目布局
```
redink/
├── .claude-plugin/plugin.json
├── .claude/
│ ├── agents/ (cwe + cve + cvss + epss validators · finding-writer · report-reviewer)
│ └── commands/ (/redink-build · /redink-recipe · /redink-rebuild · /redink-status · /redink-frameworks)
├── sections/ (28 universal report sections, one per folder)
├── frameworks/ (17 framework presets, one per folder with manifest.yaml + README.md)
├── poc/{web,server}/ (← drop your PoC screenshots here)
├── scans/ (← optional: Nessus/Burp/nmap output)
├── jsons/ (generated per-finding entries)
├── output/ (final report .docx or .json)
├── templates/ (drop your firm's docx template here, named .docx)
├── assets/ (firm logo)
├── scripts/
│ ├── assemble_docx.py (recipe-driven assembler, framework-aware)
│ └── recipe.py (standalone interactive section picker, no-LLM)
├── brand-guidelines.md ← firm details (framework-agnostic)
├── targets.yaml ← engagement scope
├── engagement-summary.md ← exec summary narrative
├── framework.yaml ← active framework
├── report-recipe.yaml ← active section selection
├── AGENTS.md ← instructions for Codex/Cursor/Gemini/Aider/Kimi
├── CLAUDE.md · README.md · DISCLAIMER.md · SECURITY.md · LICENSE
└── install.sh · .gitignore
```
## `redink` 不会做什么
- **它不会利用漏洞。** 请自行带来 PoC 截图；这是报告生成层。
- **它不保证合规。** 评估人员会对 PoC 质量、技术深度和写作技巧进行评分——自动化可以验证引用和结构，但无法验证洞察力。
- **它不会绕过你所在框架的规则。** 在使用前请阅读你所在框架的官方文档。
在漏洞利用阶段，请将 `redink` 与 [0xSteph/pentest-ai-agents](https://github.com/0xSteph/pentest-ai-agents) 或你现有的工具包结合使用。
## 贡献
特别欢迎来自任何受支持地区的活跃评估员 / 审计员 / 渗透测试人员的 PR：
- 利用区域性从业者的专业知识完善框架 manifests —— 例如，NCSC CHECK CTL 签名细节、PASSI 双轴严重性特性的怪癖、PCI QSA Customized Approach 的极端情况、IRAP “weakness not risk” 的措辞
- 为以控制为中心的框架提供完整的控制目录（CMMC 的 NIST SP 800-171 / NIST SP 800-172、IRAP 的 ISM、12 项 PCI DSS 要求、BSI IT-Grundschutz 目录、NCA ECC 的 5 大领域 × 29 个子领域、NESA 的 188 项控制、K-ISMS-P 的 102 项标准）—— 放置一个 `frameworks//controls.yaml`
- 本地化的 prompt（PASSI 使用法语、BSI 使用德语、K-ISMS-P 使用韩语、ISMAP 使用日语、NCA ECC / NESA 使用阿拉伯语、FSTEC 使用俄语）
- 每个框架经过润色的 docx 渲染器——目前各个部分都会通过一个通用的渲染器处理
目前，请在提交 PR 之前先开启一个 issue 讨论范围。
## License
MIT — 请参阅 [LICENSE](LICENSE)。
## 鸣谢
受以下项目影响：[0xSteph/pentest-ai-agents](https://github.com/0xSteph/pentest-ai-agents)（安全模型、范围防护）、[pedrohcgs/claude-code-my-workflow](https://github.com/pedrohcgs/claude-code-my-workflow)（多 agent 模板 → 最终交付物）、[Pimzino/claude-code-spec-workflow](https://github.com/Pimzino/claude-code-spec-workflow)（分阶段 pipeline 模式）、[OWASP OPTRS](https://owasp.org/www-project-penetration-test-reporting-standard/)（机器可读标准）。