用途
Blockchain Purple Team 是一种元安全（meta-security）与结构性缺口分析方法。它适用于以下情形：在已有黑队/红队发现的基础上，需要做结构性缺口分析并进行跨团队覆盖映射。
与其他团队的区分：
- 若需基于历史事件的已知漏洞模式，使用 blockchain-black-team。
- 若需发现新型攻击技术与防御绕过压力测试，使用 blockchain-red-team。
Purple Team 关注的是黑队和红队“看不到”的问题，但不要把暴露面与可利用性混为一谈。结构性盲点适合内部使用；对外漏洞报告应尽量以可利用性为依据。
主要能力（五大分析支柱）
支柱 1：审计失败模式 分析专业审计为何会漏掉关键漏洞，相关模式包括：范围盲区（审计者只关注代码，忽略经济设计）、假设继承（审计者信任外部依赖）、时间盲区（单时点审计与持续演进的协议）、组合盲区（各组件被分开审计）。
支柱 2：防御绕过演化 分析已修复漏洞如何被再次利用，相关模式包括：补丁回归（修复破坏了其他功能）、变体攻击（同一根因、不同向量）、防御衰减（部署时有效、升级后失效）、不完整修复（根因未解决、只修表象）。
支柱 3：系统性组合风险 当单个安全的组件组合成危险配置时的分析框架：
- 映射所有信任边界（链上 ↔ 链下 ↔ 预言机 ↔ 前端），对每个边界问“如果对方说谎会怎样？”
- 映射所有状态依赖（A 读 B，B 读 C），对每条链问“最长陈旧数据路径有多长？”
- 映射所有权限重叠（同一密钥控制多个对象），对每处重叠问“被攻破的影响范围有多大？”
支柱 4：运营安全缺口 代码安全但运营失败。检查清单包括：密钥管理（HSM 还是文件、轮换、备份、访问控制）、部署（CI/CD 安全、二进制校验、升级流程）、监控（监控了什么、没监控什么、告警疲劳、响应时间）、事件响应（是否有剧本、是否演练、谁决策、如何沟通）、依赖管理（锁文件、审计追踪、更新节奏）。
支柱 5：经济系统性风险 跨协议与宏观层面风险分析：抵押品相关性（同时下跌会怎样）、流动性依赖（哪些外部流动性来源是关键）、预言机依赖（单预言机失败是否引发级联）、治理捕获（51% 控制的成本是多少）、传染路径（协议失败会影响哪些其他协议）。
覆盖缺口检测方法
方法一：跨团队矩阵 构建 [攻击向量 × 防御层] 矩阵，例如防御层包括链上、Keeper、预言机、前端、运营；攻击向量包括重入、闪电贷、密钥泄露、治理、级联/脱锚等。空单元格即覆盖缺口，“?”表示部分覆盖，需用新的分析填补缺口。
方法二：假设清单 对协议声称的每一条安全属性：明确陈述该假设；问“谁/什么能违反该假设？”；问“被违反时会发生什么？”；问“是否有检测？是否有恢复？”
使用方式与参考文档
在判断某个发现是真实漏洞还是仅仅是有趣的暴露面之前，先阅读 references/exploitability-gate.md。 在决定某个发现是保留在内部还是足以对外披露时，阅读 references/reporting-thresholds.md。 在为项目团队、安全邮箱、漏洞赏金表单或维护者准备消息时，阅读 references/disclosure-templates.md。 在将 Purple Team 作为从接收到验证再到披露的端到端工作流运行时，阅读 references/purple-team-pipeline.md。 在开启新的测试网项目审查时，阅读 references/project-execution-template.md。 在将黑队、红队和紫队输出合并为一个包时，阅读 references/triad-investigation-template.md。 在追踪已发送发现、确认、修复和复测时，阅读 references/disclosure-tracker-format.md。
报告格式包含：覆盖映射、发现的结构性缺口数量、适用的审计失败模式数量，以及每个缺口的 ID、所属支柱、缺口类型、被哪方遗漏、为何被遗漏、若被利用的风险、建议。
循环协议：Purple Team 在黑队+红队之后运行，并审查蓝队修复：黑队+红队 → 蓝队修复 → 紫队审查 → 蓝队修复 → … → 全覆盖。Purple 验证蓝队修复不会引入新缺口。
适用场景
- 审计后缺口分析（“审计者漏掉了什么？”）
- 跨团队覆盖评估（黑队+红队+蓝队覆盖图）
- 架构级安全审查（不是代码，而是系统设计）
- 运营安全评估（密钥管理、部署、监控）
- 系统性风险建模（相关性、级联、传染）
- 防御有效性验证（补丁是否真的有效？）
限制
结构性盲点适合内部使用；对外漏洞报告应尽量以可利用性为依据。不要混淆暴露面与可利用性。关于具体价格、收费、平台或效果的更多信息，资料暂未提供。