security-review

安全审查

适用场景

• 用户希望对其应用、基础设施或特定功能进行安全审计
• 发布前需要威胁模型，或需要为渗透测试做准备审查
• 收到依赖项漏洞警报，需要修复建议
• 处理敏感数据（个人身份信息、支付、健康数据），需要进行验证
• 用户提出代码审计、密钥检测或合规评估需求

所需上下文

从 startup-context 获取：技术栈、部署环境、合规要求、数据类型。此外还需询问：

• 范围 — 整个应用、某项功能、身份验证系统、单个 PR、基础设施或云环境
• 数据类型 — 所处理的个人身份信息、支付数据、健康数据、凭据或其他敏感数据
• 合规要求 — SOC 2、HIPAA、PCI-DSS、GDPR、ISO 27001
• 授权 — 在进行任何主动测试前，确认已获得书面授权

工作流

遵循五阶段方法。自动扫描先于人工审查。主动测试前必须核实授权。

1. 范围界定 — 确定攻击面边界。识别所有组件、数据流和信任边界。确认授权。定义范围内和范围外的内容。
2. 自动扫描 — 在人工审查前运行工具：
   • SAST： 在整个代码库中运行 semgrep --config=auto
   • 依赖项审计： npm audit / pip-audit / govulncheck / trivy fs .
   • 密钥检测： 扫描源代码中的硬编码凭据、API 密钥和令牌
   • 容器扫描： 对容器化部署运行 trivy image
   • 记录所有自动扫描结果，以便在下一阶段验证。
3. 人工代码审查 — 进行自动化工具无法完成的上下文分析：
   • 端到端追踪身份验证和授权流程
   • 业务逻辑漏洞（价格操纵、竞态条件、权限提升）
   • 敏感信息的数据流分析（个人身份信息从何处进入、传输并持久化？）
   • 针对每个组件和数据流进行 STRIDE 威胁建模
4. 验证与分类 — 测试发现的问题并判定严重性：
   • 验证自动扫描结果，排除误报
   • 分配 CVSS v3.1 评分；结合上下文评估可利用性
   • 按业务影响分类，而不仅仅依据技术严重性
5. 报告 — 记录漏洞的精确位置、业务影响和修复措施。提供按优先级排序的修复路线图。

输出格式

# Security Review: [Scope Description]

## Executive Summary
Overall risk posture (Critical / High / Medium / Low), top findings count, and business impact summary.

## Threat Model (STRIDE)
| Threat | Category | Asset | Impact | Likelihood | Risk |

## Findings
### Critical / High / Medium / Low
- **[SEC-N] Title** — CVSS X.X — file:line — description, business impact, remediation with code example

## Auth Flow Assessment
End-to-end trace of authentication and authorization with findings.

## Dependency Vulnerabilities
| Package | Current Version | CVSS | Fix Version | Exploitable in Context? |

## Remediation Roadmap
Prioritized action list with timelines.

框架与最佳实践

STRIDE 威胁建模

应用于每个组件和数据流：

• 欺骗（Spoofing） — 攻击者能否伪造令牌或冒充用户？API 密钥是否可以轮换？
• 篡改（Tampering） — 请求在传输过程中能否被修改？Webhook 是否经过签名？是否验证数据完整性？
• 抵赖（Repudiation） — 是否记录关键操作？日志是否具备防篡改能力？
• 信息泄露（Information Disclosure） — 错误响应中是否包含堆栈跟踪？个人身份信息在静态存储和传输过程中是否加密？
• 拒绝服务（Denial of Service） — 是否设置了速率限制？单个用户能否耗尽所有用户共用的资源？
• 权限提升（Elevation of Privilege） — 普通用户能否访问管理员功能？是否在服务端检查角色？

OWASP Top 10 检查项

1. 注入 — 对 SQL/NoSQL 查询使用参数化；检查操作系统命令、SSTI 和 LDAP
2. 身份验证失效 — 使用 argon2id/bcrypt，设置会话超时，对登录进行速率限制
3. 数据暴露 — 使用 TLS 1.2+，对静态存储的个人身份信息进行加密，设置 HSTS 标头
4. XXE — 禁用 DTD 处理，优先使用 JSON 而非 XML
5. 访问控制 — 在每个端点进行服务端授权，不存在 IDOR，使用 CORS 白名单
6. 错误配置 — 关闭调试模式，移除默认凭据，设置安全标头
7. XSS — 对输出进行编码，使用内容安全策略和仅限 HTTP 的 Cookie
8. 反序列化 — 验证架构，优先使用 JSON，拒绝不可信的序列化对象
9. 易受攻击的依赖项 — npm audit、pip-audit、trivy、govulncheck
10. 日志记录 — 记录身份验证事件、管理员操作和访问违规，并配置警报

CVSS v3.1 评分指南

• 严重（9.0-10.0）： 远程代码执行、绕过身份验证、完整数据泄露、系统完全失陷
• 高（7.0-8.9）： 权限提升、重大数据暴露、利用 SSRF 访问内部服务
• 中（4.0-6.9）： 存储型 XSS、CSRF、有限的 IDOR、信息泄露
• 低（0.1-3.9）： 缺少安全标头、轻微信息泄露、错误信息过于详细

身份验证流程检查清单

• 密码：使用 argon2id 或 bcrypt（成本 >= 10）
• JWT：访问令牌有效期为 15 分钟，刷新令牌有效期为 7 天，且每次使用后轮换
• 速率限制：身份验证端点每 15 分钟最多尝试 5 次
• 密码更改后使会话失效
• 验证 OAuth state 参数，并使用限定作用域的 API 密钥
• 管理员账户必须启用 MFA
• 密码重置令牌只能使用一次，且有时效限制

扫描工具

• SAST： semgrep --config=auto（所有技术栈）、bandit（Python）、gosec（Go）、eslint-plugin-security（Node）
• 依赖项： npm audit / pip-audit / govulncheck / trivy fs .
• 容器： trivy image

强制约束

• 未经明确书面授权，绝不测试生产环境
• 绝不利用漏洞超出概念验证演示的范围
• 始终先进行自动化扫描，再进行人工审查

修复优先级

1. 可被主动利用且涉及关键数据的问题 — 立即处理
2. 绕过身份验证/授权 — 24 小时内处理
3. 注入 — 48 小时内处理
4. 数据暴露 / 关键 CVE — 1 周内处理
5. 配置加固 — 2 周内处理
6. 深度防御 — 下一个冲刺周期处理

相关技能

• code-review — 发现的问题需要代码级修复和审查时串联使用
• architecture-design — 发现的问题暴露出架构安全缺陷时串联使用
• soc2-prep — 审查属于合规准备工作的一部分时串联使用

示例

提示词示例：“审查我们用户身份验证系统的安全性。我们使用 Express 和 JWT。”

良好输出片段：

# Security Review: JWT Authentication System

## Executive Summary
Risk posture: **Critical**. Hardcoded JWT secret and non-expiring tokens.

## Findings
### Critical (CVSS 9.8)
- **[SEC-1] Hardcoded JWT secret** — auth/config.js:3 — Secret is
  "supersecret123". Attacker can forge any token.
  **Fix:** Move to env var, generate with `openssl rand -base64 64`.

### Critical (CVSS 9.1)
- **[SEC-2] Tokens never expire** — auth/jwt.js:12 — No `expiresIn`.
  **Fix:** Set `expiresIn: '15m'`, implement refresh token rotation.