Skip to content
返回质量保障

静态分析（SAST）

不运行而扫源码找安全模式——早抓注入、认证缺陷和加密误用。

为什么

SAST 分析源码（或中间表示）找指示漏洞的模式: 字符串拼接构建的 SQL 查询、MD5 哈希密码、无认证检查的路由 handler、流入 eval 的用户输入。它每个 PR 秒级跑，部署前，所以在最早可能点抓漏洞——开发者仍在上下文中且修复是一行改。相比 DAST（应用运行后找 bug）或渗透测试（部署后找），SAST 是代码级漏洞最便宜最快反馈环。假阳性率是主要挑战，故工具选择和规则调优重要。

何时使用

每个 PR（快规则集，<30s）和全仓每晚（全规则集）。采用前两周调规则集抑制假阳性——未调 SAST 工具一月内被无视。

如何做

1. 选匹配你语言和噪声容忍度的 SAST 工具
   - Semgrep（免费、自定义规则、快、低噪——大多团队最佳）
   - CodeQL（GitHub、语义分析、深但慢）
   - SonarQube（广、质量+安全、自托管或云）
   - 商业: Checkmarx、Veracode、Snyk Code（更深、更贵）

2. 从精选规则集开始，然后调
   - 启用语言标准规则（安全、最佳实践）
   - 跑代码库，收集发现，分类每个: 真阳性或假阳性
   - 用内联注释（// nosemgrep）和文档理由抑制假阳性

3. 接入 CI 每个 PR
   - 仅对变更文件跑快规则集（<30s）（Semgrep --diff）
   - 新发现即 PR 失败（非已存在——分开追踪）
   - 把发现发为 PR 审查评论使开发者上下文中看到

4. 全仓每晚跑全扫描
   - 抓触及多文件重构引入的漏洞
   - 产趋势报告——发现数随时间降还是升？

5. 把 SAST 当指南非门控，对低严重性发现
   - 高/危阻止（SQL 注入、硬编码密钥）——这些是真 bug
   - 中/低警告——让开发者确认并继续，不阻止 PR

示例

# .semgrep.yml — Node.js API 自定义规则
rules:
  - id: no-sql-string-concat
    pattern: db.query(`...${...}...`)
    message: "SQL 查询用字符串插值构建——用参数化查询"
    severity: ERROR
    languages: [typescript]

  - id: no-md5-password
    pattern: crypto.createHash("md5")
    message: "MD5 已破——密码用 bcrypt 或 argon2"
    severity: ERROR

  - id: route-missing-auth
    pattern: app.get($ROUTE, $HANDLER)
    message: "路由可能缺认证中间件——验证"
    severity: WARNING

# CI: .github/workflows/sast.yml
- uses: returntocorp/semgrep-action@v1
  with:
    config: .semgrep.yml
  # ERROR 发现即 PR 失败，WARNING 发为审查评论。

# PR 中样本发现:
#  ❌ src/db/orders.ts:14
#     db.query(`SELECT * FROM orders WHERE id = ${req.params.id}`)
#     → SQL 注入: 用户输入流入查询。修:
#       db.query("SELECT * FROM orders WHERE id = $1", [req.params.id])

常见问题

  • ⚠未调 SAST 工具产数百假阳性，团队全标"忽略"，然后真漏洞也被忽略因信噪比训练所有人无视发现。
  • ⚠仅主分支跑 SAST（非 PR）意味着开发者写代码数天后才得发现，已失上下文且修复不再是一行改。
  • ⚠每个发现包括低严重性风格问题都阻止 PR 挫伤开发者导致工具被禁——高/危阻止，其余警告。
  • ⚠仅用默认规则集不为你代码库定制——通用规则漏你特定模式（自定义认证中间件）并标你上下文中安全的模式（已消毒输入）。

最佳实践

  • ✓前两周调规则集: 分类每个发现、用文档理由抑制假阳性、为你代码库特定模式写自定义规则——调过的 SAST 工具被重视，未调的被无视。
  • ✓PR 中对变更文件跑快规则集（Semgrep --diff）使开发者秒级在上下文中得发现，全仓每晚跑全扫描。
  • ✓把发现带修复建议内联发为 PR 审查评论——开发者在同一视图看问题和解，修复分钟非天。
  • ✓追踪发现数趋势——上升趋势意味新代码引入更多漏洞，这是过程问题（培训、代码审查）非仅工具问题。