目前，业界已经达成共识：“安全左移” 成为了落地 DevSecOps 的重要实践之一。

所谓左右，与软件研发生命周期（SDLC）相关，常规的软件研发生命周期从左到右基本由以下步骤组成：计划（Plan）→ 编码（Code）→ 测试（Test）→ 发布（Release）→ 部署（Deploy）→ 运维 & 监控（Operation & Monitoring）。

“左移” 是指靠近编码、计划侧，“右移” 是指靠近上线运维侧。

安全左移与软件敏捷交付有关。传统安全手段和安全人员的介入，都在 SDLC 右侧。在敏态交付的驱动下，产品月度发布甚至周发布都变得稀松平常了，但安全始终是软件交付的底线与基石。为了在快速交付的前提下，还能保证软件的安全性，就提出了将安全进行左移的思路——即在计划、编码阶段就让安全介入，从源头把控安全。

安全左移是一本经济账

归根究底，安全 “左移” 的背后其实是一本经济账。

从上图可以看出，在软件开发生命周期不同阶段发现漏洞，其修复成本（人力、财力等）是不一样的。

如果说需求阶段发现一个漏洞，其修复成本是 1，在编码阶段发现，其成本就变成了 5，而在生产阶段成本变成了惊人的 30，这意味着：生产阶段漏洞修复成本=需求阶段漏洞修复成本 x 30 。

也就是说：越早发现漏洞，其修复成本越低，而越早也就意味着要在靠近软件开发生命周期左侧来发现漏洞，即 “安全左移”。

3 个层面，实现真正的安全左移

要实现真正的 “安全左移”，需要做到以下三个层级：

手段/工具左移

针对应用程序安全，不同阶段有不同的安全手段来帮助发现潜在的安全漏洞，诸如:

• 传统的静态应用程序安全测试（SAST），可以在应用程序处于非运行态时，针对源码、字节码、二进制包等进行扫描，发现问题;

• 动态应用程序安全测试（DAST），可以在应用程序在运行态时，扫描和发现问题；

• 敏感信息监测；

• 当下时兴的容器镜像扫描、IAST、RASP 等手段。

在传统时代，安全一般在靠后阶段（可能是 Test 阶段甚至 Release 阶段）介入，一般是由专业的安全人员来手动进行上述的安全测试。这个过程中，研发不参与安全问题发现。

而在 “安全左移” 体系中，我们鼓励研发人员参与到安全防护体系中来，甚至成为安全发现与修复的前站。比如在 IDE 中集成 SAST，在编码阶段就能在本地进行安全扫描，一旦发现问题，即可自行修复，不涉及与其他团队（测试、安全）的交互，降低了沟通成本。

此外，开发人员也可以在本地尝试敏感信息扫描（可利用开源的 git-secrets、git-leaks 等工具）确保编码时没有对于敏感信息（数据库密码、token 等）进行 Hardcode。

手段/工具的左移，是实现 “安全左移” 的第一个层级，也是最容易实现的一个层级。

数据左移

当然，对于安全而言，发现问题并不是最重要的，能尽快修复问题才是最终目的。这就要求所有安全报告（由第一层级的安全工具所产生）的数据经过有效整理（如去除假阳性、区分好漏洞的严重等级、建议的修复手段等）并直接反馈给研发人员。反馈方式如直接把结果嵌入到 MR（Merge Request）中，方便开发人员、测试人员、代码审核人员查看信息，以确保合入的代码是经过安全扫描、修复的，进一步保证代码质量。此外，所有安全报告应该有统一的安全面板进行展示，方便所有人员查看，做到公开透明，有助于团队协作。

数据左移的目的是为了用数据驱动安全问题的修复，同时通过公开透明的方式提高安全性。这是“安全左移”的第二个层级。

文化左移

DevSecOps 模式下，安全人员不再是唯一需要对安全负责的团队/人员。

“安全左移” 之下，需要培养开发人员对于安全的责任意识，在编码中秉持安全原则，比如不引入有安全风险的外部依赖包、不 Hardcode 敏感信息等。

再往左，还可以培养产品/架构的安全意识，在计划/设计阶段就充分考虑安全，比如使用威胁建模方式，梳理安全边界、系统间的安全连接方式等。

文化左移是 “安全左移” 的第三个层级，也是最终层级。其目的是打造真正的 “人人为安全” 的企业文化，这也是 DevSecOps 最终想要达到的目标 —— 一个企业中，所有与软件研发相关的人员都可能成为软件安全交付的瓶颈，只有每个人都具有安全意识，才能消除安全瓶颈点，共同为客户交付安全、高效的软件。