L6-31：首席安全官审计 —— 像黑客一样审视你系统的每个角落

OWASP Top 10 + STRIDE = 全面安全视图

单一审计方法的问题： → SAST 工具：大量误报，不看上下文 → 手动渗透测试：只覆盖测试者想到的攻击面 → 合规检查：只关注"是否满足标准"而非"是否真的安全"

双模型互补： OWASP Top 10（攻击者视角）： → "外面的人怎么打进来？" → 基于真实世界的攻击数据（OWASP 社区统计） → 覆盖最常见的 10 种攻击向量

STRIDE（设计者视角）： → "系统设计的每个环节有什么威胁？" → 基于微软的威胁建模方法论 → 覆盖 6 种威胁类别： Spoofing（欺诈） Tampering（篡改） Repudiation（否认） Information Disclosure（信息泄露） Denial of Service（拒绝服务） Elevation of Privilege（权限提升）

两者结合 = 攻击者知道怎么打 + 设计者知道哪里有弱点

十大威胁的审查清单

A01: Broken Access Control（访问控制缺陷）

→ IDOR（不安全的直接对象引用）：/api/users/123 → 改成 124 能看别人的？ → 垂直越权：普通用户直接访问 admin 端点 → 水平越权：用户 A 通过改参数访问用户 B 的数据 → CORS 配置过宽：Access-Control-Allow-Origin: * → 检查方法：遍历所有端点，检查是否有 auth middleware

A02: Cryptographic Failures（加密失败）

→ 敏感数据明文传输（HTTP 而非 HTTPS） → 弱加密算法（MD5、SHA1 用于密码存储） → 可预测的随机数（Math.random() 用于 token 生成） → 硬编码的密钥/盐值 → 检查方法：Grep 搜索 crypto、password、secret、key、token、jwt

A03: Injection（注入攻击）

→ SQL 注入：字符串插值拼接 SQL 语句 → XSS：.html_safe / dangerouslySetInnerHTML / innerHTML → 命令注入：shell=True + f-string / os.system() + 用户输入 → LDAP 注入、模板注入（SSTI）、路径遍历 → 检查方法：/[cs]so 的 checklist 与 /review 的 CRITICAL pass 共享

A04: Insecure Design（不安全的设计）

→ 缺失速率限制（用户可以暴力破解） → 缺失输入验证（信任前端传来的所有数据） → 安全决策依赖于客户端（前端隐藏的 isAdmin 字段） → 检查方法：读取架构文档和设计决策记录

A05: Security Misconfiguration（安全配置错误）

→ DEBUG = True 在生产环境 → 详细的错误信息暴露给客户端 → 默认密码未更改（admin/admin） → 不必要的 HTTP 方法开启（PUT/DELETE 未限制） → 过时的依赖（已知 CVE 漏洞）

A06-A10: 其余五大类

→ A06: 脆弱和过时的组件（npm audit / bundle audit） → A07: 认证和识别失败（弱密码策略、session 管理缺陷） → A08: 软件和数据完整性失败（不安全的反序列化、未签名的更新） → A09: 安全日志和监控失败（无审计日志、日志无完整性保护） → A10: SSRF（服务端请求伪造——LLM 生成 URL 的风险）

六大威胁类别的代码级映射

Spoofing（欺诈——伪装成合法身份）

→ JWT 签名验证是否在任何地方都被强制执行？ → session token 是否可预测？ → API key 是否可以被伪造（简单 UUID 不够）？ → 检查：认证中间件的所有绕过路径

Tampering（篡改——修改不应该修改的数据）

→ 数据库记录是否可以被越权修改？ → 日志是否可以被外部修改？ → Webhook payload 是否验签？ → 检查：所有写操作是否有权限检查

🔍 实战案例——Tampering（篡改）：

-- 危险：任何登录用户都能改任意订单
UPDATE orders SET status = 'cancelled' WHERE id = ?

-- 安全：验证订单属于当前用户
UPDATE orders SET status = 'cancelled' WHERE id = ? AND user_id = ?

Repudiation（否认——做了但不承认）

→ 关键操作是否有审计日志？ → 日志是否包含：谁、什么时候、做了什么、结果如何？ → 日志是否防篡改（append-only）？ → 检查：敏感操作（支付、删除、权限变更）的日志覆盖

Information Disclosure（信息泄露）

→ 错误消息是否暴露内部实现？ → API 响应是否返回过多数据（用户密码 hash 在响应中）？ → Git 仓库中是否有 .env 文件？ → 检查：所有 error response 和 API 响应 schema

🔍 实战案例——Information Disclosure（信息泄露）：

// 危险：API 返回了不该暴露的字段
app.get('/api/users/:id', (req, res) => {
  const user = db.users.findById(req.params.id)
  res.json(user)  // 返回了 password_hash, ssn, email 等全部字段
})

// 安全：只返回必要字段
res.json({ id: user.id, name: user.name, avatar: user.avatar })

Denial of Service（拒绝服务）

→ 是否有无限制的循环/递归被用户输入触发？ → 是否有未受保护的大查询（SELECT * 无 LIMIT）？ → 文件上传是否有大小限制？ → 检查：所有资源密集型操作的保护措施

Elevation of Privilege（权限提升）

→ 是否有"run as admin"的路径不验证当前用户？ → 角色变更是否需要更高权限？ → 检查：所有权限边界和角色变更路径

三层发现结构

CRITICAL（P0——立即修复）

→ 可远程利用的漏洞（无需认证） → 数据泄露风险（可读取任意用户数据） → 权限提升（普通用户变 admin） → 示例：SQL 注入在公开端点、未验证的 JWT、开放的 admin 端点

HIGH（P1——本周内修复）

→ 需要认证才能利用的漏洞 → 潜在的注入但输入源受限 → 信息泄露但影响范围有限 → 示例：已登录用户的 IDOR、XSS 在后台页面

MEDIUM（P2——sprint 内修复）

→ 配置问题（DEBUG mode、详细错误） → 弱加密但有其他保护层 → 日志不完整 → 示例：生产环境显示 stack trace、缺少速率限制

LOW（P3——改进建议）

→ 安全加固建议（不是漏洞，是改进） → 最佳实践偏离 → 示例：使用 bcrypt 而非 argon2、虽然有 HTTPS 但 HSTS 未配置

每条发现包含

→ 威胁类别（OWASP A01-A10 或 STRIDE S/T/R/I/D/E） → 文件位置 + 行号 → 攻击场景描述（攻击者如何利用） → CVSS 评分（如有充分信息） → 修复建议（具体代码示例） → 验证方法（如何确认修复有效）

/review 集成

→ /review 的 Security 专家调用 cso 的清单 → cso 是 Security 专家的"知识库" → Security 专家的输出补充 cso 的发现

/investigate 集成

→ cso 发现的安全漏洞 → /investigate 验证可复现性 → 确认后可利用性后升级严重度

/ship 集成

→ /ship 的审查就绪检查包括安全审查 → 发现 CRITICAL 安全漏洞 → 阻止 /ship

GBrain 集成

→ cso 的发现反馈给 GBrain 的 Security Smells 维度 → 持续追踪安全态势

Skill 结构模板：双模型安全审计

核心特征

• 管理对象: 代码库全量安全漏洞（非单次 PR 级）
• 核心原则: OWASP Top 10（攻击者视角）+ STRIDE（设计者视角）双模型互补，不依赖单一分析框架
• 关键设计:
  • 三层发现结构（CRITICAL/HIGH/MEDIUM/LOW），每条发现包含攻击场景 + CVSS + 修复建议 + 验证方法
  • 与 /review、/investigate、/ship 深度集成，CRITICAL 漏洞可阻止部署
  • 审计报告包含 OWASP/STRIDE 覆盖度统计

通用结构

• 输入层: 代码库路径 + 审计范围（scope）+ 技术栈信息（framework, db）
• 分析层:
  • OWASP Top 10 遍历（A01 访问控制 → A10 SSRF）
  • STRIDE 六大威胁类别映射（Spoofing → Elevation of Privilege）
• 输出层: 分严重度的发现列表 → 审计报告摘要 → 修复优先级建议
• 集成层: 发现反馈给 /review Security 专家、/investigate 验证可复现性、/ship 审查就绪检查