每天扫描超 300 亿行代码，DevSecOps 在华为的落地与实践

多年来，软件开发以及其引发的软件安全问题总是相生相伴。最近几年，国内有越来越多的软件开发团队和企业开始践行 DevOps 的研发模式。随着 DevOps 的发展，研发安全保障的思维和技术也在不断演化发展，其中一个重要的思想就是 DevSecOps。什么是 DevSecOps？它的价值是什么？DevSecOps 怎样在企业落地？......针对上述问题，InfoQ 记者采访了华为技术专家章可镌。

据悉，章可镌于 2007 年加入华为，他不仅写过代码，带过产品，而且还做过交付。大约 6 年前，他的工作重心转向软件开发周期中安全保障能力建设工作。

从 DevOps 到 DevSecOps

针对 DevOps 领域的安全治理问题，Gartner 提出了 DevSecOps 概念。简言之，DevSecOps 是一种旨在将安全性嵌入 DevOps 链条中的每个部分新方法，它有助于在开发过程早期而不是产品发布后识别安全问题，目标是让每个人对信息安全负责，而不仅仅是安全部门。

DevSecOps 架构，如下图所示：

针对上图，章可镌表示，自己更习惯将左右两个图拆开来看。左边的“Dev 段”，聚焦软件开发过程的安全保障；右边的“Ops 段”，聚焦软件运行时安全。他说：“从软件或服务的角度看，左边画个圈，保证它‘生’来安全；右边画个圈，保证它‘活’的安全。”

进一步看，这张图的左、右部分可以再拆成上下两段，因此出现四个象限。

• 第一象限的 Configure+Detect 阶段，可以理解为对应用程序的运行时的安全保障，比如容器和基础设施安全、RASP、WAF 等；

• 第二象限的 Plan+Create 阶段，从宏观上可以认为是在进行软件的安全设计与开发前准备，更注重安全规则的制定、安全需求分析、软件设计时的安全考虑；

• 第三象限的 Verify+Preproduction 阶段，即是对开发阶段进行安全保障，可以进行 AST、Fuzz、SCA 等；

• 第四象限的 Predict+Respond 阶段，可以理解为软件的在网安全监测，比如监测和响应安全事件等。

在章可镌看来，DevSecOps 概念的诞生，实际上伴随着“安全左移”的思想，即“更早”、“更快”地发现安全风险并（处理）。

他说：“六西格玛管理教过我们算过一笔账：问题发现越早，代价越小。以我理解，DevSecOps 的目标是在软件生命周期的全部阶段，可以更早、更快地发现并处理安全问题。而它之所以出现，是因为现有的软件开发（运维）流程无法支撑这一目标。”

DevSecOps 的核心是人，以及由人所形成的文化。章可镌认为，“虽然 DevOps 从一开始就不断强调工具链的重要性，但我们还是期望在组织、企业和团队中，研发业务线的人需要具备相应的素质。谈到 DevSecOps 会强调安全素质，但并非要有专业安全背景，而更多的是指具备基本的安全意识”。

为什么做 DevSecOps？

章可镌表示，一直以来，华为传统的电信级产品对产品质量要求非常严苛。这类产品在交付给客户后，即属于客户资产，因此客户（比如电信运营商）不会允许华为技术人员随意进出其机房，更别说远程运维其设备。

在这样的背景下，一方面，CT 在 2000 年前后逐步向 ICT 转型，各类网络安全问题越来越突出；另一方面，华为客户对安全、隐私的重视程度越来越高，其产品必须适配客户的网络安全合规要求。加上安全问题的地缘政治化，网络安全逐渐成为事关生死存亡的命题。

“而所谓的安全要求，往往只看结果——发生问题后，那种‘不知者无罪’或‘过程正确’的说法在这里不成立。”他说。

华为一开始的做法很简单，引入业界先进的工程方法和工具技术，尽可能保障华为产品足够安全。但是，他们在实践后发现，这些优秀的工具可能还没法适应华为如此庞大体量的工程化要求。据悉，华为现在落地的安全编码检查，一天需要扫描的代码量级在 300 亿行以上，“在引进这些工具时，没有谁能简单地做到”。

DevSecOps 在华为的落地

在尝试 DevSecOps 时，他们希望让安全保障能支撑快速迭代开发，同时又平衡安全检查的深度；其次，不同的团队、不同的业务形态，既不能太过散漫，又不能太过集权式管理。并且，安全不能只是一小部分人关心，安全团队和开发团队不应该是对立关系。

在章可镌看来，DevOps 的基本诉求之一是要“快”，而安全保障却具有“快不起来”的特点。因为安全本身需要更为专业的知识背景，分析更复杂的攻击方式和潜在安全问题。并且，即使使用工具，其技术栈也深于普通的检查工具，这意味着耗时更长。

比如，对源代码的静态检查，如果只是检查代码风格，他们可以做到快速扫描；如果需要进行安全编码的自动化检查，那么就需要进行流分析，甚至需要一个专门的编译过程来收集必要信息。

对此，华为的做法是分阶段配置，同异步按需。一方面，抽取快速、简单、明确的检查工具或检查规则，将它配置到开发作业流的前端，比如 IDE、个人代码门禁，将厚重的内容放到后端，例如每日半夜自动触发的全量安全验证。另一方面，将厚重的内容进一步剥离形成异步模式，让它成为“慢轨”，不影响日常高速迭代的“快轨”车道。

华为的产品线非常丰富，从传统电信设备到手机终端，从嵌入式到云服务。这也意味不同的产品团队为了更好地适配自己的产品形态，会使用不同的开发语言，有不同的开发过程。“我们也讲究‘力出一孔’，这意味着已有的能力需要尽可能复用，避免重复造轮子”。

正如 DevSecOps 宣言的起草者之一 Shannon Lietz 所说，不存在“one size fits all（一刀切）”的好事。华为的策略是按组织层级，定义出每一层组织的“最小集”和不可逾越的“红线”，剩下的自由发挥。

公司级的安全团队会提供方法、规范、组件、基础技术和工具，而产品线对自己的安全质量负责。

最后，安全团队提供方法、规范、组件、技术和工具。Shannon Lietz 曾提到，保障安全的工作是“非常有技术含量的工作”。而由安全团队所做的技术工作的成果落地到开发团队时，常常被认为是过于冗繁、小题大做。开发人员在被要求修改看起来不会影响程序正常功能的潜在问题时，就容易有抵触情绪。并且，安全类的检查工具常常伴有误报。

针对这个问题，“不好解决，也不太可能在短期内得到解决，这是一个持续的安全意识和行为规范的塑型工作。我们希望营造一种有着广泛共同安全意识的氛围”。

• 第一，制定各类安全规范和对应的培训课程，范围涵盖软件设计、开发、测试到运维；

• 第二，对参与公司安全生态建设的团队和个人给予激励；

• 第三，在已有的流程节点上设置合理安全评审内容，以无缝结合到现有流程，（尽可能自动化地）反馈研发过程中的安全风险；

• 第四，提取工具生成的各类数据以支撑数字化运营，来证实工具的作用或发现工具的不足并持续改进，例如用机器学习的方式来降解误报，取得很好的效果。

据悉，华为提出了一个矩阵式运营的概念。举个例子，在 SAST 落地时，对横向的过程分为 IDE、代码提交门禁、版本级全量检查三个子场景；在组织层面，分为公司、产品线、具体产品三个层级，形成一个 3X3 的运营体系。在这九宫格的每个格子里，都有对应的规范、方法、策略、工具和人，以这种方式，尽可能地保证足够的灵活度，并且不会成为一盘散沙。

如何挑选 DevSecOps 工具

在工具层面，章可镌称“希望‘吸收宇宙能量’”，在可选择的范围内，选择最成熟、能力最强的工具。他们会参考各大知名评估机构的推荐，也会进行对比测试选型。不仅关注整体的能力，而且更关注工具是否可以覆盖华为业务场景下常见的或最新的安全问题。

同时，他们也会关注开源软件的动向。他表示，“当我们选择开源工具时，更注重的可能不是它‘现在有什么’，而是它‘能为我们达成什么’。”

华为技术人员会在开源工具的基础上进行更深层次的研发，“而不是仅仅把它往 CI/CD 上一扔，或者只做一些规则适配”。

工具的挑选或自研完成后，华为会把它集成到与之对应的安全工具平台上。

据章可镌介绍，在设计阶段，华为有自己的威胁建模工具 SecDesign、隐私分析评估与管理平台 SecPCP；在开发阶段，有安全编码检查平台 SecSolar；在测试阶段，有安全测试云 SecGuard。在 Ops 阶段，华为也有相应的工具。

他说：“优秀工具经过各平台优秀的工程化能力加持，再与流水线一起，形成一条研发端自动化安全工具链，服务于华为产品线，形成企业级安全保障能力。”

无论是选择现有工具，还是合作、自研工具，华为看重的是这个工具是否适合其业务场景。优秀的工具不仅具备普适能力、易于集成、生态开放的特点，而且它在某一点的能力是非常精专的。

目前，他们正在 DevSecOps 领域做一些新的尝试：

• 让更资深、更专业的安全服务进一步工具化、工程化，比如华为现在可以通过人工+工具辅助的方式完成较大规模的缓冲区溢出问题的形式化验证，未来试图实现完全自动化；

• 提供安全隐私评估和管理的作业平台，例如，在 GDPR、WP29 和国内隐私保护相关法律法规的要求下，产品需要关注哪些设计要素？如果仅由产品开发团队去分析，那要耗费大量人力并且不专业；

• 让应用安全测试编排（ASTO）更合理，各类测试可以产生更好的联动。

DevSecOps 的发展趋势

对于 DevSecOps 的未来发展，章可镌分享了几个个人观点：

更左移

更左移，以期待更早地发现问题。以前有人说“质量是设计出来的”，他认为安全质量也可以朝这个方向去努力。“我们看到，很多初创公司或挣扎在生存线上的公司可能并不太关注安全，或仅关注 Ops 段的安全”。而有能力的公司会把安全控制向左移到 Dev 阶段。一开始，关注点会在后端测试阶段；再进一步，他们会追求在编码阶段就杜绝引入安全问题，考虑 Security as Code。更有追求者会在设计甚至需求分析阶段就考虑到尽可能多的安全威胁因素并制定消减措施。

更开放

DevSecOps 秉承了 DevOps 的开放思想。章可镌认为谈到安全，他理解为生态开放、心态开放。

生态的开放：兼容并包，例如提供开放的集成能力（可以集成第三方，也能被第三方集成）、工具能力二次开发。不仅是规则定制，甚至可以将分析过程的中间结果也开放出来，以满足更灵活的定制化需求。

心态的开放：理解安全是更专业的话题，需要专业的解决之道，愿意学习安全知识而非抗拒，比如安全设计与编码规范。

更高效

从安全角度看，对“高效”的诉求尤其强烈。对此有深入理解的人认识到有一些安全的工作无法避免人工操作，这也意味着需要更长时间。举个例子，设计阶段的安全分析工作还没有太好的自动化工具，那些更专业的安全服务目前还无法实现全自动化。SAST 基于编译的增量分析还需要解决不少的问题，当提高检查敏感度参数时，就需要安全团队的专家协作进行代码人工检视以及工具告警的人工排查。如何更高效地确保产品生命周期的安全，这将是 DevSecOps 的永恒课题。