安全审计清单

OWASP Top 10 检查项与 STRIDE 威胁建模

每条 OWASP 检查项附对应的工具命令或代码 pattern；STRIDE 每个维度给出 2 个具体核查问题。

OWASP Top 10 检查命令

# A01 权限失控 — 检查缺失授权装饰器
semgrep --config=p/owasp-top-ten src/

# A02 加密失效 — 检测弱算法
bandit -r . -t B303,B304,B305,B413

# A03 注入 — SQL 字符串拼接
semgrep --pattern 'db.query("..." + $X)' --lang python src/

# A05 安全配置错误 — 容器镜像漏洞
trivy image --severity HIGH,CRITICAL myapp:latest

# A06 易受攻击组件 — 依赖扫描
trivy fs --security-checks vuln .

# A07 身份验证失败 — 弱密码哈希
bandit -r . -t B303,B324

# A09 日志与监控不足 — 缺失 audit log
grep -rn "except:" src/ | grep -v "log\."

Vulnerable vs Secure 代码对比

// ❌ 危险：直接拼接 SQL（A03 Injection）
const sql = `SELECT * FROM users WHERE id = ${req.params.id}`;
db.query(sql);

// ✅ 安全：参数化查询
db.query('SELECT * FROM users WHERE id = $1', [req.params.id]);

// ❌ 危险：MD5 存储密码（A02 Cryptographic Failures）
const hash = crypto.createHash('md5').update(password).digest('hex');

// ✅ 安全：bcrypt with cost factor ≥ 12
const hash = await bcrypt.hash(password, 12);

STRIDE 威胁建模 — 6 维度核查问题

• Spoofing（身份伪造）：① 服务间调用是否使用 mTLS 或 signed JWT 互认？ ② 重置密码链接是否绑定会话或一次性 token？
• Tampering（篡改）：① 数据库写操作是否验证用户只能修改自己的资源（object ownership）？ ② Webhook 载荷是否用 HMAC-SHA256 验签？
• Repudiation（否认）：① 关键操作（支付/删除）是否有带用户 ID 的不可变审计日志？ ② 审计日志是否防篡改（写后不可删）？
• Information Disclosure（信息泄露）：① 错误响应是否暴露 stack trace 或内部路径？ ② API 列表端点是否限制只返回调用者有权访问的记录？
• Denial of Service（拒绝服务）：① 昂贵查询端点是否有速率限制和超时（query timeout）？ ② 文件上传是否限制大小和类型？
• Elevation of Privilege（权限提升）：① IDOR：用数值 ID 直接访问其他用户资源是否被后端校验？ ② 管理员功能是否在 DB 层面用独立角色隔离，而非前端判断？

发现项严重级别与扫描工具命令

严重级别与是否阻塞发布、SLA 挂钩；同一仓库内应保持定义一致，并在报告中与 OWASP 或内部风险矩阵对齐说明。

# semgrep：自定义规则扫描（可在 CI 中运行）
semgrep --config=p/security-audit \
        --config=p/secrets \
        --json -o report.json src/

# bandit：Python 代码安全扫描
bandit -r src/ -f json -o bandit-report.json \
  -ll  # 只报 medium 及以上

# trivy：容器镜像与文件系统扫描
trivy image --severity HIGH,CRITICAL \
            --format json \
            --output trivy-report.json \
            myapp:$(git rev-parse --short HEAD)

# trivy：依赖漏洞（sbom 模式）
trivy fs --security-checks vuln,secret \
         --format cyclonedx \
         --output sbom.json .

审计执行流程

  [ 确认范围 + 威胁模型入口 ]
        │
        ▼
  ┌─────────────┐     对照清单：鉴权 / 输入 / 数据 / 集成 / 运维
  │  逐项核对    │──── 每条记录：状态、证据（路径/配置/commit）、备注
  └─────────────┘
        │
        ▼
  ┌─────────────┐     映射严重级别；Critical/High 标阻塞与 SLA
  │  汇总发现项  │──── 分配责任域：应用 / 平台 / 合规；关联 Finding ID
  └─────────────┘
        │
        ▼
  ┌─────────────┐     跟踪至关闭；例外登记复审日期
  │  复测与收口  │──── 产出：审计摘要 + 未关闭项列表
  └─────────────┘

审计报告 JSON 模板（Finding 结构）

{
  "finding_id": "VV-SEC-API-0001",
  "severity": "High",
  "title": "GraphQL 端点缺少深度限制，可被 DoS 攻击",
  "cwe": "CWE-400",
  "owasp": "A05:2021-Security Misconfiguration",
  "description": "POST /graphql 接受嵌套深度无限制的查询，攻击者可构造深度 100 层的查询导致 CPU 耗尽。在 src/graphql/server.ts:42 未设置 depthLimit。",
  "reproduction": "curl -X POST /graphql -d '{users{posts{comments{author{posts{...}}}}}}' 触发 100% CPU。",
  "recommendation": "引入 graphql-depth-limit，设置 maxDepth=7；并加 query cost analysis。",
  "evidence": "src/graphql/server.ts:42，压测录屏 ./evidence/gql-dos.mp4",
  "responsible_domain": "application",
  "estimated_effort": "2h",
  "sla_days": 14,
  "status": "open"
}

Finding ID 格式化

统一编号便于在 PR、工单与复测记录间引用。格式为 {前缀}-SEC-{域}-{4 位序号}（前缀与域仅含大写字母与数字）。