windshock/oh-my-secuaudit
GitHub: windshock/oh-my-secuaudit
一个面向 Claude/Codex 的安全技能集合，解决安全评估证据的结构化、标准化工序问题。
Stars: 2 | Forks: 0
# oh-my-secuaudit
Claude Code 和 Codex 工作流程的安全技能集合。
## 布局
- `skills/static/sec-audit-static`：静态安全审计工作流（SAST/SCA/密钥/报告）
- `skills/static/sec-cluster`：安全代码聚类工作流（基于 v4 数据流）
- `skills/runtime/sec-audit-dast`：运行时/API 评估工作流（DAST/ASM）
- `skills/external/external-software-analysis`：第三方软件/二进制分析工作流
- `skills/architect/security-architecture-review`：安全架构评审工作流
- `skills/methodology/security-testing-as-code`：评估即项目工作流（PoC、证据、交接）
## 能力矩阵
| 技能 | 核心问题 | 典型输入 | 主要输出 | 消费者 |
|---|---|---|---|---|
| `sec-audit-static` | 源代码和依赖项中存在哪些漏洞？ | 源代码仓库 | 发现的 JSON、任务/最终报告 JSON、Markdown 报告、`reporting_summary` | `security-architecture-review` |
| `sec-cluster` | 哪些代码路径共享相同的安全评审策略？ | 源代码仓库 + 静态分析结果 | CLUSTERS.md、Semgrep 规则、REVIEW_CHECKLIST.md | `sec-audit-static`、`security-architecture-review` |
| `sec-audit-dast` | 运行时或暴露面存在哪些可利用项？ | 域名/IP/端点/ASM 导出 | SARIF/CSV 发现、发现 JSON、`reporting_summary` | `security-architecture-review` |
| `external-software-analysis` | 第三方二进制/包存在哪些风险？ | JAR/AAR/SO/外部包 | Markdown 报告、发现 JSON、架构交接 Markdown、`reporting_summary` | `security-architecture-review` |
| `security-architecture-review` | 所有发现如何影响信任边界和关键流程？ | 静态/DAST/外部输出 + 仓库证据 | `security-architecture-review.md` + `security-product-requirements.md`（跟踪型待办事项与生命周期差异） | 最终制品 |
| `security-testing-as-code` | 如何使评估结果可复现且可继承？ | 评估发现 + PoC 代码 | 项目结构（artifacts/poc/、artifacts/runtime/、handoff-plan.md） | 任意生产技能 |
## 端到端关系图谱
```
flowchart LR
subgraph L0["Layer 0: Threat Context (Manual, Non-Automated)"]
T["External threat research (advisories, KEV/CVE trends, abuse intel)"]
end
subgraph L1["Layer 1: Producer Runs"]
S["sec-audit-static"]
CL["sec-cluster"]
D["sec-audit-dast"]
E["external-software-analysis"]
end
subgraph LM["Layer M: Methodology"]
STAC["security-testing-as-code"]
end
subgraph L2["Layer 2: Contract Normalization"]
N["Normalize findings: finding_id, severity, provenance, impacted_flow"]
end
subgraph L3["Layer 3: Architecture Synthesis"]
R["security-architecture-review"]
end
subgraph L4["Layer 4: Outputs and Lifecycle"]
O["security-architecture-review.md"]
P["security-product-requirements.md (SPR backlog + delta)"]
FB["Feedback scope: missing evidence, boundary gaps, flow-specific follow-up"]
end
S -->|required| N
CL -.->|clustering context| S
CL -.->|cluster-to-scenario mapping| R
D -->|required| N
E -->|required| N
E -.->|optional enrichment| EH["external-analysis-architecture-handoff.md"]
T -.->|manual threat context| R
STAC -.->|project structure & PoC packaging| S
STAC -.->|project structure & evidence packaging| D
N -->|required| R
EH -.->|optional enrichment| R
R -->|required| O
R <--> |continuous requirement lifecycle| P
O -->|gap-based follow-up| FB
P -->|SPR-driven priorities| FB
FB -.->|targeted re-scan| S
FB -.->|targeted re-scan| D
FB -.->|targeted re-analysis| E
FB -.->|new threat questions| T
classDef static fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20;
classDef runtime fill:#fff3e0,stroke:#ef6c00,color:#e65100;
classDef external fill:#e3f2fd,stroke:#1565c0,color:#0d47a1;
classDef threat fill:#ffebee,stroke:#c62828,color:#b71c1c;
classDef review fill:#fff8e1,stroke:#f9a825,color:#e65100;
classDef contract fill:#eceff1,stroke:#455a64,color:#263238;
classDef artifact fill:#f5f5f5,stroke:#616161,color:#212121;
classDef feedback fill:#e0f2f1,stroke:#00695c,color:#004d40;
classDef cluster fill:#f3e5f5,stroke:#7b1fa2,color:#4a148c;
classDef methodology fill:#e8eaf6,stroke:#283593,color:#1a237e;
class T threat;
class S static;
class CL cluster;
class D runtime;
class E,EH external;
class N contract;
class R review;
class O,P artifact;
class FB feedback;
class STAC methodology;
```
图例：
- 绿色：静态生产者流程
- 紫色：聚类（代码模式分组）
- 橙色：运行时生产者流程
- 蓝色：外部生产者流程
- 红色：外部威胁上下文（手动/非自动输入）
- 蓝靛色：方法论（评估即代码）
- 黄色：架构综合
- 灰色：合同标准化与制品
- 青色：反馈闭环至生产者
- 实线箭头：必需交接
- 虚线箭头：可选增强或迭代反馈
- 双箭头：持续生命周期同步
## 交接契约（为何重要）
- `security-architecture-review` 不是另一个扫描器。
- 它是综合层，负责合并异构证据并做出判定：
- 哪些风险已由架构确认
- 哪些仅属于外部/运行时
- 哪些仍为 `not-confirmed`
- 跨技能标准化依赖以下字段：
- `finding_id`（或 `id`）
- `severity`
- `provenance`（`binary-confirmed|source-confirmed|runtime-confirmed|not-confirmed`）
- `impacted_flow`（例如 `F1`、`F2`）
## 架构评审的最小制品集
| 源技能 | 合成所需 | 推荐补充 |
|---|---|---|
| `sec-audit-static` | 包含必需字段的发现 JSON、`reporting_summary` | Markdown 报告与污点/源-汇注释 |
| `sec-audit-dast` | 包含必需字段的发现 JSON 或标准化运行时发现、`reporting_summary` | SARIF 与可复现探测元数据 |
| `external-software-analysis` | 包含必需字段的发现 JSON | `external-analysis-architecture-handoff.md` |
| 外部威胁研究（手动） | 非必需 | 来自安全公告/情报的威胁主题映射到攻击场景 |
## 架构到产品的桥梁
- `security-architecture-review` 将高/危急风险与未解决的缺口转化为 `SPR-*` 需求。
- 每个 `SPR-*` 必须包含负责人、目标里程碑、状态与可测试的验收标准。
- 需求状态在每次架构评审时更新并附带差异：
- `added`、`updated`、`closed`、`deferred`、`accepted-risk`
## 应运行哪些技能
| 场景 | 运行顺序 |
|---|---|
| 源代码仓库审计 | `sec-audit-static` -> `security-architecture-review` |
| 外部端点/运行时评估 | `sec-audit-dast` -> `security-architecture-review` |
| 第三方二进制/包风险 | `external-software-analysis` -> `security-architecture-review` |
| 完整融合评估 | `sec-audit-static` + `sec-audit-dast` + `external-software-analysis` -> `security-architecture-review` |
## 推荐编排
1. 在可能的情况下并行运行生产技能（静态、运行时、外部）。
2. 使用通用合同（`finding_id`、`severity`、`provenance`、`impacted_flow`）标准化发现。
3. 添加手动外部威胁研究主题并映射到候选攻击场景。
4. 运行 `security-architecture-review` 将发现映射到 DFD 节点、信任边界与攻击场景。
5. 生成来自架构缺口的反馈计划（缺失证据、未解决的边界、不确定流程、新威胁问题）。
6. 针对反馈计划中的范围重新运行生产技能，随后重新运行架构评审。
7. 仅在存在新直接证据时升级 `provenance`。
## 闭环模型（生产者 <-> 架构）
1. 生产者发现候选项并进行初始确认。
2. 架构评审综合系统级风险并识别确认缺口。
3. 缺口转化为有针对性的生产者操作（新规则、新探测、更深入的源码/二进制追踪）。
4. 生产者返回精炼后的证据。
5. 架构评审更新 DFD/攻击流程与置信度。
6. 重复直至主要缺口关闭。
## 最终报告前的质量门禁
1. 每个导入的发现都必须包含 `provenance` 和 `impacted_flow`。
2. 外部运行时跃点组件（例如 RP 中继、移动 SDK）必须在 DFD 节点/边/边界映射中显式出现。
3. 攻击流程场景需回溯到场景 ID 与导入的发现 ID。
4. `Confidence & Gaps` 需清晰列出未解决的确认项。
## 开发者工作流
- 本地验证运行：`just check`（或 `python3 scripts/validate_skills_repo.py`）
- CI 在 `push`/`pull_request` 到 `main` 时执行相同的合同验证。
- 快速工作树检查：`just status`
发布流程：
- 请参阅 [`.github/RELEASE_GUIDE.md`](.github/RELEASE_GUIDE.md) 获取版本控制/打标签步骤。
## 项目文档
- 发行说明：`RELEASE_NOTES.md`
- 后续计划：`ROADMAP.md`
## 环境搭建
### Claude Code
每个技能的 `SKILL.md` 可直接作为 Claude Code 指令文件使用。要使用某项技能：
1. **直接引用**：请 Claude Code 读取并遵循特定 `SKILL.md`：
读取 skills/static/sec-audit-static/SKILL.md 并运行该静态审计剧本。
2. **项目命令**：将技能目录符号链接或复制到项目的 `.claude/commands/` 以便通过斜杠命令访问：
```bash
mkdir -p .claude/commands
ln -s "$(pwd)/skills/static/sec-audit-static/SKILL.md" .claude/commands/sec-audit-static.md
```
3. **CLAUDE.md 集成**：从项目的 `CLAUDE.md` 引用技能：
要进行安全审计，请参考 /path/to/oh-my-secuaudit/skills/static/sec-audit-static/SKILL.md 中的工作流。
### Codex
每个技能目录均包含 `agents/openai`，供 Codex 原生发现使用。将技能目录复制或符号链接到 `~/.codex/skills/local/`。
## 相关阅读
来自 [Code Before Breach](https://windshock.github.io/en/) 的博客文章：
| 技能 | 文章 | 相关性 |
|---|---|---|
| `security-testing-as-code` | [Security Diagnostics Reports Die Upon Publication](https://windshock.github.io/en/post/2026-03-17-security-testing-as-code/) | 直接来源——评估即项目的核心论述 |
| `sec-cluster` | [Structure Builders Will Outlast Vulnerability Finders](https://windshock.github.io/en/post/2026-04-02-security-from-sense-to-structure/) | 以系统化结构取代零散发现 |
## 附注
- 每个技能目录均包含其自身的 `SKILL.md`、引用、模式与脚本。
- 技能按领域划分，位于 `skills/static`、`skills/runtime`、`skills/external`、`skills/architect` 与 `skills/methodology` 下。
标签：Claude Code, Codex, DAST, SAST, SEO: 代码安全, SEO: 安全审计工具, SEO: 评估即代码, SOC工具, 二进制分析, 云安全运维, 代码分析, 代码聚类, 信任边界, 凭证管理, 动态应用安全测试, 安全工作流, 安全技能集合, 恶意软件分析, 持续安全, 架构审查, 漏洞发现, 盲注攻击, 秘密检测, 系统运维工具, 评估即代码, 静态应用安全测试