메뉴
服务上线前的 AI 安全审查，聚焦需要理解代码语义和业务逻辑的安全问题。 覆盖注入防护、认证授权、敏感数据处理、配置安全、业务安全 5 个维度。 适用于 JS/TS 前端、TS/Python 后端项目。 CI/CD 自动化检测（依赖漏洞、敏感信息 grep）不在本 skill 范围内，由流水线承担。 触发词：安全审计、安全检查、上线前检查、有没有漏洞、security audit。 触发场景：release 发版前（强制）、涉及认证/支付/用户数据的改动后（建议）、用户主动要求。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | security-audit |
| version | 1.0.0 |
| last_updated | "2026-04-08T00:00:00.000Z" |
| repository | https://github.com/312362115/claude |
| description | 服务上线前的 AI 安全审查，聚焦需要理解代码语义和业务逻辑的安全问题。 覆盖注入防护、认证授权、敏感数据处理、配置安全、业务安全 5 个维度。 适用于 JS/TS 前端、TS/Python 后端项目。 CI/CD 自动化检测（依赖漏洞、敏感信息 grep）不在本 skill 范围内，由流水线承担。 触发词：安全审计、安全检查、上线前检查、有没有漏洞、security audit。 触发场景：release 发版前（强制）、涉及认证/支付/用户数据的改动后（建议）、用户主动要求。 |
CI/CD 拦确定性问题（依赖漏洞、硬编码密钥），本 skill 审需要理解力的问题（数据流追踪、业务逻辑安全）。 两者互补，不重复。
收到审计请求
│
├─ 快速扫描（单模块 / 局部改动 / 敏感模块修改后）
│ 选 1-2 个最相关的维度检查
│ 产出：终端输出结果，不生成报告
│
└─ 完整审计（release 发版前 / 新服务首次上线 / 重大安全相关改动）
5 个维度全量检查
产出：docs/audits/YYYY-MM-DD-<服务名>-audit.md
AskUserQuestion 确认，不要猜package.json / requirements.txt / pyproject.toml / tsconfig.json按以下 5 个维度逐一检查。每个维度都需要读代码，不是凭印象判断。
审查目标：用户可控的输入是否经过正确处理后才进入危险操作。
检查清单：
| 注入类型 | 关注点 | 安全做法 |
|---|---|---|
| SQL 注入 | 原生 SQL 拼接、ORM 的 raw query | 参数化查询、预编译语句 |
| 命令注入 | exec()、child_process、os.system()、subprocess | 避免拼接用户输入到命令，用参数数组 |
| XSS | innerHTML、dangerouslySetInnerHTML、模板中的未转义输出 | 输出转义、CSP 头、避免直接插入 HTML |
| 路径遍历 | 用户输入拼接文件路径、../ 未过滤 | 路径规范化、白名单校验、path.resolve 后检查前缀 |
| SSRF | 用户输入作为 URL 发起服务端请求 | URL 白名单、禁止内网地址、DNS rebinding 防护 |
| 模板注入 | 用户输入直接进入模板引擎渲染 | 避免动态模板编译、使用沙箱 |
审查方法：
审查目标：确保每个需要保护的资源都有正确的认证和授权检查。
检查清单：
| 检查项 | 关注点 |
|---|---|
| 认证覆盖 | 有没有接口"裸奔"——应该要登录但没加认证中间件？ |
| 授权粒度 | 用户 A 能不能通过改 ID 访问用户 B 的数据？（IDOR） |
| JWT/Session | 密钥强度、过期时间、刷新机制、注销是否真的失效 |
| CORS 策略 | Access-Control-Allow-Origin 是否过于宽松（*）？credentials 模式下的 origin 检查 |
| 密码策略 | 密码是否 bcrypt/argon2 哈希存储、是否有强度要求 |
| 权限绕过 | 前端隐藏 ≠ 后端鉴权，检查是否只在前端做了权限判断 |
审查方法：
审查目标：敏感数据在存储、传输、日志中是否得到正确保护。
检查清单：
| 检查项 | 关注点 |
|---|---|
| 密码存储 | 是否用了 bcrypt/argon2？是否明文或 MD5/SHA1？ |
| 加密算法 | 是否使用了已知弱算法（DES、RC4、MD5 用于加密） |
| 日志脱敏 | 日志里有没有打印密码、token、手机号、身份证号 |
| 错误信息 | 异常响应是否泄露了堆栈、SQL 语句、内部路径 |
| 数据传输 | 敏感 API 是否强制 HTTPS？cookie 是否设置 Secure 和 HttpOnly |
| 前端存储 | token 存 localStorage（可被 XSS 窃取）还是 httpOnly cookie？ |
审查方法：
console.log、logger.、print），检查是否包含敏感字段审查目标：安全相关配置是否合理，生产环境是否加固。
检查清单：
| 检查项 | 关注点 |
|---|---|
| 安全响应头 | X-Content-Type-Options、X-Frame-Options、Strict-Transport-Security、CSP |
| Debug 模式 | 生产环境是否关闭 debug/详细错误输出 |
| 默认凭证 | 是否存在默认密码、测试账号、admin/admin |
| 速率限制 | 登录、注册、验证码等接口是否有 rate limit |
| 文件上传 | 是否限制文件类型、大小？存储路径是否在 web 可访问目录外？ |
| 环境隔离 | 生产配置和开发配置是否分离？环境变量是否正确引用 |
审查目标：识别需要理解业务语义才能发现的安全风险。
检查清单：
| 检查项 | 关注点 |
|---|---|
| 越权访问（IDOR） | 修改请求中的 ID/参数能否访问他人数据 |
| 批量枚举 | 用户名/邮箱是否可被枚举（注册/登录/找回密码的不同返回） |
| 竞态条件 | 余额扣减、库存扣减、优惠券核销是否有并发保护 |
| 逻辑绕过 | 支付金额是否可在前端篡改？流程步骤是否可跳过？ |
| 重放攻击 | 关键操作是否有幂等性保护或 nonce 机制 |
| 信息泄露 | API 响应是否返回了多余字段（如其他用户的信息、内部 ID） |
审查方法：
每个发现按以下标准分级：
| 等级 | 标准 | 处理要求 |
|---|---|---|
| 高危 | 可直接导致数据泄露、未授权访问、代码执行 | 必须修复后才能上线，给出具体修复代码 |
| 中危 | 存在利用条件但风险可控，或防御纵深不足 | 建议修复，给出修复方向 |
| 低危 | 最佳实践缺失，短期内风险较小 | 记录待改进，不阻断上线 |
分级原则：
完整审计时，生成报告到 docs/audits/YYYY-MM-DD-<服务名>-audit.md：
# 安全审计报告：<服务名>
## 审计概览
- 审计日期：YYYY-MM-DD
- 审计范围：<目录/模块列表>
- 技术栈：<自动识别结果>
- 风险摘要：🔴 X 高危 / 🟡 X 中危 / 🟢 X 低危
## 审计结论
**✅ 通过** / **⚠️ 有条件通过（需修复高危后上线）** / **❌ 不通过**
## 详细发现
### 1. 注入防护
（发现 / 无风险）
### 2. 认证与授权
（发现 / 无风险）
### 3. 敏感数据处理
（发现 / 无风险）
### 4. 配置安全
（发现 / 无风险）
### 5. 业务安全
（发现 / 无风险）
## 修复清单
| # | 等级 | 维度 | 问题描述 | 文件位置 | 修复建议 |
|---|------|------|---------|---------|---------|
## 历史审计
- [上次审计](链接)（如有）
每个发现必须包含：
CI/CD 安全流水线（自动化，确定性）
├─ pre-commit: gitleaks 拦截敏感信息
└─ PR Check: 依赖漏洞 + 静态规则扫描
│
↓ 自动化通过后
security-audit（本 skill，AI 审查）
├─ task-finish 提示：涉及敏感模块时建议快速扫描
└─ release 强制：发版前完整审计
│
↓ 审计通过
release — 发版
审计报告目录：docs/audits/，命名格式 YYYY-MM-DD-<服务名>-audit.md
code-walkthrough 或快速阅读理解业务逻辑，再做安全审查。脱离业务的安全审查是低效的通用写作技能：以"内容→组件→组合"的方式产出技术文档、产品文档、汇报材料。 覆盖 spec / plan / PRD / 用户手册 / 项目汇报 / 方案路演 / 调研报告 等所有结构化文档场景。 核心理念：组件驱动，不预设模板。先看内容形态，再挑能装这种形态的组件， 组合自然成文——不强制章节结构、不预设"必备模块"。 组件库（HTML / Markdown / 图示）见 references/components.md， 常见组合范式（spec / plan / PRD 等）见 references/templates/——但模板是参考不是规定。 触发词：写文档、写方案、写计划、写 PRD、写汇报、项目总结、写指南、帮我写、文档、方案设计。 即使用户没有明确说"写"，只要意图是"产出一份结构化的文档/报告/材料"，都应触发此技能。 本 skill 只负责"写"，不负责"调研"（调研由 deep-research 承担）和"调度"（流程由 task-start 承担）。
深度调研技能：对任意命题进行系统性调研并输出专业研究报告。 覆盖技术选型、行业分析、学术研究、竞品分析、概念探索等所有调研场景。 核心方法论：快速扫描→假设驱动研究、内外数据结合（先摸清内部现状再对标外部水位）、 反面证据强制搜索、数据来源三级分类、结论置信度分级、多层次报告输出。 采用 Orchestrator-Subagent 架构（Lead+Sub-agent 并行深挖、压缩回传、Scaling Rules 预算控制）， 对齐 Anthropic 官方 Research 工程实践。 包含信息交叉验证、专业图表生成（Diagram Bridge 统一图表体系）、 数据来源分级标注、分析框架自动选择、报告组件驱动（不预设模板，按内容形态调用组件）、质量自检（6 步工作流）。 触发词：调研、研究、分析报告、对比分析、行业报告、技术选型、竞品分析、 市场调研、深度研究、出一份报告、帮我调研一下、了解一下xxx、 评估、诊断、健康度、差距分析。 即使用户没有明确说"调研"，只要意图是"系统性地了解某个命题并形成结论"，都应触发此技能。
MD 文件浏览器预览：GitHub 风格渲染 + 左侧自动目录。 在完成方案设计（specs）或开发计划（plans）的 MD 文件后触发。 询问用户是否要在浏览器中打开预览，确认后执行。 触发词：方案写完、计划写完、review MD、预览文档。 工作流位置：task-start 方案产出后 / 任意 MD 文档完成后
专业图表生成技能：根据需求自动选择合适的图表类型，生成符合设计规范的 PNG 图表。 覆盖 29 种图表：结构图（流程图、泳道图、时序图、架构图、状态图、ER图、类图、思维导图、甘特图、Kanban、Git Graph 等） 和统计图（柱状图、折线图、饼图、雷达图、热力图、散点图、桑基图、漏斗图、瀑布图、矩形树图、柱线混合图等）。 统一工具：HTML/SVG + 内联 JS 布局计算。ER/类图使用 ELKjs 布局引擎。 所有图表遵循统一的设计规范（配色/字体/组件/间距），风格现代简洁。 支持三种输出：PNG（默认）、HTML（富文档嵌入）、DSL（Mermaid 文本，嵌入 MD 文档）。 触发词：画图、画一个、生成图表、流程图、架构图、时序图、柱状图、对比图、关系图。 即使用户没有说"画图"，只要需求中涉及可视化展示（流程、架构、数据对比、关系），都应触发此技能。 被 deep-research 等其他技能调用时，同样遵循本规范生成图表。
项目知识库引擎：持续维护 docs/ 目录作为活的知识库。 灵感来源：Karpathy LLM Wiki — LLM 不只是写文档，而是持续维护知识库。 五个核心操作：Ingest（摄入新信息）、Query（检索知识）、Lint（健康检查）、Index（索引维护）、Synthesize（聚合全局视图）。 触发词：文档检查、清理文档、文档索引、docs 整理、知识库、文档过期了吗、架构文档、用户手册。 触发场景：task-manager 标 done 时自动触发 Ingest、定期 Lint 健检、用户查询项目历史、 task-finish 提醒后触发 Synthesize 更新 architecture/ 或 user-guide/。 即使用户没有说"文档管理"，只要涉及 docs/ 目录的整理/检查/更新，都应触发此技能。
提交前质量门禁：CR 自检（快速/深度）。在 commit 之前触发。 只负责代码质量自检，不负责复盘——复盘在需求标 done 时由 task-manager 触发。 触发词：提交代码、自检、准备提交。 工作流位置：task-start → task-execute → task-finish（自检）→ task-manager（需求关闭时复盘）