5.3 SDLC 与合规要求

5.3 SDLC 与合规要求

本节摘要：SOURCE 6.1/6.3：安全必须嵌入 SDLC——需求威胁建模、设计评审、SAST/DAST 门禁、发版签名、运营事件响应；GDPR、CCPA、个人信息保护法对移动 App 收集位置/通讯录提出明示同意与删除权要求。

上手前先明确

1. 画出移动安全 SDLC 各阶段活动
2. 说明 GDPR 下数据主体删除请求如何处理
3. 制定发版前安全 Checklist（10 项内）

一、移动安全 SDLC

安全 SDLC 闭环

安全 SDLC 闭环

二、发版 Checklist（精简）

1. debuggable=false
2. 无硬编码 secret（MobSF PASS）
3. HTTPS + Pinning 配置正确
4. Token 加密存储
5. 权限最小化
6. 第三方 SDK 清单更新
7. 隐私政策版本与 UI 一致
8. 渗透 Critical/High 已关闭
9. 签名与 Play/App Store 一致
10. 最低 OS 版本安全补丁说明

三、法规要点

GDPR：合法 basis、数据最小化、删除权（Right to Erasure）、72h breach 通知。

个保法：告知同意、单独同意敏感个人信息、境内存储要求（关键信息基础设施）。

PCI DSS（支付 App）：不得存储 CVV；移动端符合 SAQ A 或 D 取决于架构。

四、事件响应

1. Contain — 吊销 Token、关闭接口
2. Eradicate — 补丁发版
3. Recover — 监控异常登录
4. Learn — postmortem 更新威胁模型

⚠️ 常见坑：隐私政策写「不收集位置」，SDK 却在后台要 GPS — 合规与实现不一致。

💡 关键直觉：合规是可证明的流程 — 日志、同意记录、删除 API 都要能审计。

核心回顾

• SDLC 每阶段有安全交付物，不是末尾 pentest 一次
• 发版 Checklist 可机器化（CI + 人工签字）
• GDPR/个保法要求删除权与同意可追溯
• 事件响应含强制升级老客户端

教程完结 — 建议结合 MobSF 对自有 App 跑一遍全链路验收。

深化：合规从文档走向可审计

合规不是「写一页隐私政策」，而是「可证明的流程」：数据清单、同意记录、删除接口、日志留存都要能查、能验、能恢复。个保法要求告知同意与单独同意敏感个人信息；GDPR 的删除权意味着必须有「删除账户」API 并能真正删除数据。把合规动作写进 SDLC 的每个阶段，发布时一次审计全过。

# 合规可审计清单（示例）
[ ] 数据清单：收集项+用途+保存期 已登记
[ ] 同意记录：弹窗版本+时间戳 可查
[ ] 删除API：调用后可验证数据消失
[ ] 跨境评估：数据不出境 or 已评估
[ ] 隐私政策：与产品行为一致 已抽查
​

事件响应要演练：Contain（吊销 Token、关接口）、Eradicate（补丁发版）、Recover（监控异常登录）、Learn（更新威胁模型）。强制升级是移动特有的收尾手段——服务端修复挡不住老版本客户端继续泄露。发版前 Checklist 可机器化，人工签字兜底。

合规审计的常见证据

合规审计要能拿出证据，常见清单包括：数据清单与分类记录、隐私政策版本与用户同意时间戳、删除账户的 API 调用与数据删除验证、第三方 SDK 清单与数据流说明、安全测试报告与修复记录、事件响应演练记录。每一份证据都要能对应到具体实现——审计时「说我们有」不如「看这里能查到」。把证据沉淀成目录并随版本更新，年度审计就能从「翻箱倒柜」变成「对表拿证」。

# 证据目录（示例）
compliance/
  data-inventory.json      # 数据清单
  consent-log/             # 同意记录
  deletion-api/            # 删除接口与验证
  sdk-list.json            # 第三方 SDK 台账
  pentest/2026-q2/         # 渗透报告与修复记录
​

事件响应的演练频率

事件响应预案要演练而不是存档。建议每季度做一次桌面演练：给定一个虚构泄露场景，走一遍 Contain、Eradicate、Recover、Learn 四步，记录每一步的实际耗时与卡点。演练的目的不是追求「无瑕疵」，而是暴露流程中的断点——例如「吊销 Token 需要等运维手动执行」这类在预案里没写清的问题。演练记录同时是合规审计的证据之一。