4.1 静态应用安全测试
4.1 静态应用安全测试 (SAST)
本节摘要：SAST 在不运行 App 的情况下分析 APK/IPA 或源码，发现硬编码密钥、危险 API、错误权限配置。SOURCE 1.7 将 SAST 列为生命周期早期门禁；本节以 MobSF 工作流为主。
本节目标
- 用 MobSF 上传 APK 并解读 Critical/High 项
- 配置 CI 中 Semgrep 规则扫描 Kotlin/Swift
- 区分「需人工确认」与「可自动 fail」的发现
一、SAST 查什么
| 类别 | 示例规则 | 对应 OWASP |
|---|---|---|
| 硬编码 secret | API_KEY = "sk-..." |
M5/M7 |
| 不安全存储 | MODE_WORLD_READABLE |
M1 |
| 通信 | usesCleartextTraffic=true |
M2 |
| 导出组件 | 导出 Activity 无权限 | M4/M9 |
| 调试 | android:debuggable=true |
M8 |
# MobSF Docker 本地扫描（自有应用） docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf # Web UI 上传 app-release.apk
二、CI 集成思路
# GitHub Actions 片段 - name: Semgrep mobile run: semgrep --config p/owasp-mobile --error
失败策略：Critical 阻断合并；High 需 ticket；Medium 进 backlog。
SAST 门禁流程
SAST 门禁流程
三、误报与人工复核
- `「相关地址请参见官方文档」 非 cleartext 业务流量
- 混淆后字符串误报 API Key — 结合 entropy 与上下文
- 导出 Service 若仅
android:permission保护可能为设计
复核记录模板：发现 ID、是否误报、证据截图、责任人。
四、与源码审计配合
SAST 看不到业务逻辑 IDOR — 需对照 API 文档做威胁建模。最佳实践：SAST（每 PR）+ 季度人工代码审计（支付/登录模块）。
⚠️ 常见坑：只扫 release 包不扫 debug 变体 — debug 常含测试后门。
💡 关键直觉：SAST 价值在早与频 — 修复成本随发版指数上升。
重点提炼
- MobSF/Semgrep 覆盖 M1/M2/M5/M8 大部分静态模式
- CI 门禁需分级，避免噪声淹没 Critical
- 静态扫描不能替代动态与逻辑审计
- 每 finding 映射 OWASP M 编号便于排期
下一节 DAST：运行起来用 Burp/Frida 打。
深化：MobSF 报告解读与 CI 落地
MobSF 静态扫描报告按 M 编号归类，常见 Critical 项：硬编码密钥、可导出组件未加权限、明文流量配置、可调试标志未关。解读报告的第一步不是「修」，而是先人工确认每一条：它是不是误报、攻击路径是否真实存在。例如「找到字符串 password」可能是提示文案而非密钥，结合上下文与熵值判断。
# CI 门禁示意：Critical 阻断，High 进 ticket - name: SAST gate run: | semgrep --config p/owasp-mobile --json > report.json # 解析 report.json：Critical 数 >0 则 exit 1
SAST 的盲区要心里有数：它看不到运行时逻辑、业务越权、第三方 SDK 的真实行为。所以 CI 里 SAST 做高频门槛，季度人工审计覆盖支付与登录模块。扫描目标要包含 release 与 debug 两个变体——debug 包常带测试后门。
| 报告项 | 判定思路 | 处置 |
|---|---|---|
| 硬编码密钥 | 上下文+熵值 | Critical 立即改 |
| 明文流量 | 配置审计 | Critical 禁止 |
| 导出组件 | 权限声明 | 视设计 |
| 日志泄露 | 敏感字段 | Medium |
SAST 结果的处置流程
SAST 报告到手后按四步处置。第一步去重：同一条规则在多个文件命中合并；第二步分诊：逐条判断真漏洞、需人工确认、误报三类；第三步排期：Critical 阻断合并，High 建 ticket，Medium 进 backlog；第四步复扫：修复后重跑确认清零。分诊是最关键的一步，误报不处理会让团队对报告失去信任，真漏洞被漏掉则让门禁形同虚设。建议把误报判据沉淀成文档，例如「字符串 password 出现在 UI 文案且非密钥上下文」的判定标准。
# 处置流程 扫描 -> 去重 -> 分诊(真/人工/误报) -> 排期 -> 修复 -> 复扫清零
| 步骤 | 动作 | 产出 |
|---|---|---|
| 去重 | 合并同规则命中 | 唯一列表 |
| 分诊 | 三分类 | 判定记录 |
| 排期 | 按严重度 | 负责人 |
| 复扫 | 重跑确认 | 清零证明 |
把扫描纳入日常开发
SAST 的最大价值是「早与频」，所以要把扫描纳入日常而非发版前。建议在 CI 上对每个 PR 跑增量扫描，对 release 包跑全量扫描；本地开发也提供扫描命令，开发者提交前自检。规则库要维护：新增自定义规则（如本项目的禁止模式）、剔除误报高的规则。扫描结果与工单联动，Critical 自动建高优先级工单。坚持下来，漏洞从「发版前集中爆发」变成「开发中零散消灭」。
误报治理
误报不治理，SAST 会迅速失去团队信任。治理三步：建立误报判据文档，把「UI 文案里的 password 字符串」这类常见误报写进判据；规则支持豁免并记录理由与日期，定期复查豁免是否仍然成立；每次复扫对比增量，新出现的真漏洞不会被旧报告淹没。误报治理是 SAST 能长期运转的前提，投入产出比很高。
规则库的长期维护
规则库是 SAST 效果的上限。维护动作包括：新漏洞出现后沉淀为自定义规则、误报高的规则降级或加条件、业务特有的禁止模式（如「密码不得进日志」）固化为规则。规则库要有负责人与评审流程，避免个人偏好主导。定期对照真实漏洞样本评估规则命中率，规则库才不会脱离实际威胁。