fable-redteam

Fable RedTeam

执行安全、受限的智能体伦理渗透测试和主动漏洞发现。

用途

提供自动化、可复现的进攻性安全审计引擎，用于验证应用防御能否抵御真实世界的攻击手段。fable-redteam 会在经授权的预发布／本地环境中验证 API 身份验证、授权边界、对象隔离和敏感信息泄露，并立即生成可供实施的修复卡片。

适用场景

• 需要对本地、预发布或经授权的测试目标进行主动安全测试。
• 验证 API 端点是否强制执行身份验证和授权（BOLA/IDOR）。
• 测试 CORS 配置错误、缺失安全标头或 .env 文件泄露。
• 发布前，针对预发布端点模拟攻击者控制的请求。
• 验证先前应用的安全补丁是否确实消除了漏洞。

不适用场景

• 没有实时目标端点时进行纯静态代码审查或威胁建模（请使用 fable-security）。
• 不进行安全探测的功能测试或断言检查（请使用 fable-verify）。
• 未经授权且不在明确配置范围内的公共目标。
• 压力测试或拒绝服务模拟（严格不在适用范围内）。

输入

• target：目标 HTTP/HTTPS URL 或本地仓库路径。
• profile：扫描深度（passive、api-logic、comprehensive、orchestrated、playbook、audit）。
• scopeConfig：可选的自定义范围 JSON（默认使用 .fable/redteam.json 或本地安全默认值）。支持 allowedCidrs、maintenanceWindow，并会自动保护云元数据地址（169.254.169.254）。
• authToken：可选的 Bearer 令牌，用于经过身份验证的 API 探测。
• baseline：可选的先前 .fable/redteam-findings.json 路径，用于差异回归。
• failOnCvss：可选的 CVSS v3.1 数值阈值（例如 7.0）；在 CI/CD 安全违规时以状态码 1 退出。
• suppress：可选的待忽略发现指纹或 ID 列表。

运行模式

• 指导模式： 用于定向安全问题、威胁建模、架构审查或验证特定候选发现。不会写入完整审计产物，也不会运行所有阶段。
• 完整审计模式： 跨所有攻击面执行完整的 6 阶段审计工作流，并写入确定性覆盖台账和经验证的发现项架构。通过 get-fable redteam audit 或 --profile audit 触发。

预期输出

• redteam_findings：经验证的漏洞发现项数组，包含 CWE ID、自动计算的 CVSS v3.1 向量、数值基础分、合规分类标签和复现用 curl 命令。
• docs/security/REDTEAM_REPORT.md：完整的 Markdown 审计报告，包含高管风险评分卡（A-F）、MTTR 估算和发现项分类。
• docs/security/REDTEAM_REPORT.sarif：OASIS SARIF v2.1.0 报告，可供 GitHub Advanced Security 和企业 SIEM/SOAR 摄取。
• findings.json：机器可读的结构化发现项，严格遵循 report-schema.json，并按判定结果分类（confirmed、needs_validation、rejected）。
• coverage-ledger.json：确定性覆盖台账，映射已检查的表面及符合 RFC 3986 规范的百分号编码覆盖 ID。
• architecture.md：基于源码的威胁边界和组件架构图。
• FINDINGS-DETAIL.md：详细的源码跟踪、复现方法和最小有效代码修复方案。
• NEEDS-VALIDATION.md：基于源码、需要未观察到的部署信息才能确认的线索，以及安全验证计划。
• .fable/run-attestation.json：具有防篡改能力的 SHA-256 加密证明记录。
• remediation_cards：可直接写入 .fable/LEDGER.md 的可执行 Fable 工作卡片。

流程

1. 范围预检： 根据允许的主机模式、CIDR 子网和排除路径验证目标 URL。强制执行云元数据防护（169.254.169.254）和有效的维护窗口。如果目标超出范围，立即失败关闭。
2. 阶段 1 — 侦察与威胁建模： 将架构、低信任主体、授权边界、入口面和执行汇点映射到 architecture.md，并初始化 coverage-ledger.json。
3. 阶段 2 — 覆盖率驱动的狩猎： 针对各攻击类别（Auth、IDOR、Injection、SSRF、Memory Safety、LLM、Supply Chain）迭代台账单元，并执行隔离的狩猎检查。
4. 阶段 3 — 对抗性候选验证： 让独立验证器逐一审查每个候选项并尝试证伪。严格将发现分类为：
   • confirmed：完整的源码追踪，并展示有界的观测结果。
   • needs_validation：有源码依据的线索，但受未观测到的部署事实阻碍；附带安全的本地和部署计划。
   • rejected：已证伪的候选项，并明确说明反驳理由。
5. 阶段 4 — 结构化输出与架构验证： 按指纹排序写入 findings.json，并使用零依赖验证器 validateFindings() 对照 report-schema.json 进行验证。使用 validateCoverageLedger() 验证覆盖率台账。
6. 阶段 5 — 独立记录验证： 验证最终源码声明、文件行号引用和稳定指纹，且不混合证据。
7. 阶段 6 — 目标中立的报告与修复： 生成 REPORT.md、FINDINGS-DETAIL.md 和 NEEDS-VALIDATION.md。将已验证的发现转化为 .fable/LEDGER.md 中可执行的修复工作卡和自动化回归测试。

决策规则

• 如果目标主机与 allowedHosts、allowedCidrs 或默认环回地址不匹配，立即拒绝执行，不进行网络调用。
• 如果目标解析到云实例元数据地址（169.254.169.254），立即中止。
• 如果 safe-mode 已启用，绝不执行会删除数据库的 SQL 负载或无界模糊测试循环。
• 如果断路器切换到 OPEN 状态，优雅地中止探测操作并报告部分发现。
• 如果设置了 --fail-on-cvss，且任何未抑制的发现达到或超过阈值，则以非零失败状态退出，供 CI/CD 门禁使用。
• 解决所有发现后，切换到 fable-verify 或 fable-release。

工具策略

• 使用原生 TS HTTP 探测器（src/core/redteam/probe.ts），以零依赖方式探测任意主机。
• 使用原生 Cloudflare Audit Adapter（src/core/redteam/adapters/cloudflare.ts）和 Audit Engine（src/core/redteam/audit/engine.ts）进行覆盖率驱动的 6 阶段审计，并确保符合 report-schema.json。
• 参考 skills/fable-redteam/references/cloudflare/ 中的 14 份专用攻击类别领域指南（AI-AND-LLM.md、WEB-PROTOCOL-AND-AUTH.md、CLIENT-SIDE.md 等）。
• 可选的外部工具（Nuclei、Nmap、FFuf、Akto、HexStrike、CyberStrike、PentAGI、PentestAgent）在可用时可通过适配器编排。
• 绝不将凭据或敏感数据写入 Git 跟踪的文件或公开日志。

证据要求

• 发现必须包含确切的目标 URL、HTTP 状态码、CVSS v3.1 向量/评分、合规标签和可复现的 curl 命令。
• 已修复漏洞必须通过阴性重新扫描证明攻击向量现在返回 401/403/404。
• 加密运行证明用于验证发现的完整性。

故障处理

• 遇到网络连接错误或目标超时时，将故障记录为未解决的端点，而非误报为阴性结果。
• 遇到速率限制时，降低请求频率或通过退避暂停执行。
• 目标服务器反复出错时，触发断路器，以防止级联拒绝服务。

完成标准

• 完整执行所选扫描或审计配置。
• 在 docs/security/REDTEAM_REPORT.md 生成 Markdown 报告，并在 docs/security/REDTEAM_REPORT.sarif 生成 SARIF 文件。
• 在审计模式下，生成的 findings.json、coverage-ledger.json 和 architecture.md 通过架构验证。
• 在 .fable/run-attestation.json 生成运行证明。
• 补救工作卡采用适用于 .fable/LEDGER.md 的格式。