概念

"左移"：把安全工作提前到软件开发生命周期（SDLC）的早期阶段。

在流程图上，开发流程通常从左（需求、设计、编码）到右（测试、部署、运维）——"左移"就是把安全活动往左边挪。

核心思想：在开发早期发现并修复问题，成本远低于在生产环境中修复。

为什么

修复成本随阶段递增（这是软件工程中被反复验证的经验）：

  • 设计阶段：改一个架构决策，成本低；
  • 编码阶段：改几行代码；
  • 测试阶段：要修改、重新测试、可能要回归；
  • 生产阶段：紧急修复、可能的停机、数据泄露损失、声誉损失、合规罚款。

安全问题的代价尤其陡峭——因为生产环境的安全漏洞可能直接造成损失（数据泄露、勒索、服务中断），而不只是"功能不好用"。

左移的具体实践

一、需求与设计阶段：威胁建模（Threat Modeling）

在写代码之前，先想清楚：可能受到什么攻击？

常用方法：

  • STRIDE：Spoofing（假冒）、Tampering（篡改）、Repudiation（否认）、Information Disclosure（信息泄露）、Denial of Service（拒绝服务）、Elevation of Privilege（权限提升）；
  • 数据流图（DFD）+ 信任边界：画出数据如何在系统中流动，在边界处识别威胁；
  • 攻击树（Attack Tree）：系统地列举达成某个攻击目标的路径。

产出：安全需求、需要防护的点、风险接受决策。

这是最"左"的活动，也是性价比最高的之一。

二、编码阶段

1. 安全编码规范与培训

针对不同语言的安全编码指南（如 OWASP 的 Secure Coding Practices）。

2. IDE 插件

在开发环境中实时提示安全问题（如硬编码密钥、已知的不安全函数）。

3. 安全的代码库和框架

使用默认安全的框架（如自动转义的模板引擎）——让安全的做法成为最容易的做法。

4. 密钥检测（Secret Scanning）

在提交前检测代码中是否包含密钥、令牌（如 git-secrets、Gitleaks、detect-secrets）。

三、代码提交与评审

1. 代码评审（Code Review）中的安全关注

在 PR 评审时关注：

  • 是否有输入验证；
  • 是否有授权检查（前文提到过的 IDOR）；
  • 是否使用了参数化查询；
  • 是否引入了新的危险依赖。

2. pre-commit hooks

提交前自动运行 lint、格式化、密钥扫描。

四、CI 阶段（最重要的自动化层）

1. SAST（静态应用安全测试）

在不运行代码的情况下分析源代码，找出潜在漏洞模式（如 SQL 注入、XSS、路径穿越）。

优点：早、快、覆盖全量代码。
缺点：误报率高，需要调优。

2. SCA（软件成分分析）

扫描依赖中的已知漏洞（CVE）和许可证问题。

3. 容器镜像扫描

4. 基础设施即代码（IaC）扫描

检查 Terraform、Kubernetes YAML 等配置中的安全问题（如公开的存储桶、过宽的安全组规则）。

5. 单元测试中的安全用例

如前文提到的，为越权访问编写测试。

五、测试与预发布

DAST（动态应用安全测试）：对运行中的应用做黑盒扫描。误报率低于 SAST，但覆盖有限。

IAST（交互式应用安全测试）：结合运行时插桩，精度高。

模糊测试（Fuzzing）：向程序输入大量随机或半随机的输入，寻找崩溃和异常。

六、部署与运行（"右"的部分依然重要）

左移不意味着放弃运行时的安全：

  • 运行时防护（WAF、RASP）；
  • 监控与告警；
  • 事件响应。

关键成功因素

一、不要只是"加门禁"

如果在 CI 中加入一堆安全扫描，产生大量失败的构建和噪音，开发团队会：

  • 绕过它；
  • 或者要求放宽规则；
  • 或者干脆忽略结果。

结果：工具在，但没用。

二、降低噪音，提高信噪比

  • 先只启用误报率低的规则；
  • 对存量问题设置基线，只关注新增；
  • 提供清晰的修复指导（而不只是"这里有漏洞"）。

三、让开发者能自己修复

工具应该：

  • 集成在开发者熟悉的环境（IDE、PR 评论）；
  • 给出具体的修复建议和代码示例；
  • 快速反馈（几分钟内，而不是几小时后）。

四、安全团队的定位转变

从"守门员"（在最后审批）转变为"赋能者"（提供工具、模板、培训、咨询）。

这在规模化的组织中尤其关键——安全团队不可能审查所有的代码变更。

一句话

安全的目的是让产品更安全，而不是让流程更严格。

左移成功的标志，是开发团队主动使用这些工具，而不是被迫应付检查。

说明：本文为安全工程的知识整理。