构建DevSecOps中的代码三层防护体系-CSDN博客

本文链接：https://blog.csdn.net/shendong70/article/details/133106835

1. DevSecOps

近年来，大型企业DevSecOps引入占比逐年递增，从2020年的41.3%增至2022年超63.5%, 其复合增长率超过20%。

DevSecOps一词最早由Gartner在2012年提出，并在最近几年逐步成为软件开发种的热点。DevSecOps在开发人员、测试人员、安全团队和运维团队之间架起了桥梁；它改善了团队之间的沟通和协作，其目标是更快、更高效地交付。DevSecOps，在DevOps的基础上增加了安全的活动，在保障快速开发、快速的部署的基础上，提高了安全性，内嵌安全到应用程序中，能够更迅速地应对安全威胁。

下图是美国国防部（Department of Defense（DOD））定义的DevSecOps软件生命周期的9个阶段：计划、开发、构建、测试、发布、交付、部署、操作和监控。安全嵌入到每个阶段。DevSecOps生命周期具有很强的适应性，并且有许多反馈循环来驱动持续改进。DevSecOps 在管理理念、管理方法、组织结构、开发流程、软件开发、开发平台、工具集成、以及企业文化等方方面面对传统的软件开发提出了新的挑战。

在这里插入图片描述

在DevSecOps的应用过程中，静态分析工具在开发阶段承担着非常重要的代码质量和安全的看护任务。本文重点讲述软件静态分析工具在DevSecOps的开发域中的重要作用。

2. DOD DevSecOps

美国防部自2021年起发布一系列关于DevSecOps相关文件：《国防部企业DevSecOps战略指南》、《国防部企业DevSecOps基础》、《DevSecOps参考设计》《DevSecOps行动手册》等相关支撑文件。

今年五月又补充了《DevSecOps 基础指南：活动和工具》。在这个文档中更加清楚的定义了在DevSecOps的生命周期中，需要完成的安全活动和对应的工具。涉及的安全活动如下表：

安全活动	阶段	依赖的工具
基于任务的网络风险评估	全部	基于任务的网络风险评估工具
威胁建模	计划	威胁建模工具
代码提交扫描	开发	代码仓安全插件
安全代码开发	开发	IDE
提交前的静态代码扫描	开发	IDE 安全插件
依赖组件漏洞检查	构建	依赖关系检查/物料清单检查工具
静态应用程序安全测试和扫描（SAST）	构建	静态应用程序安全测试和扫描工具(SAST)
数据库安全测试	测试	安全合规工具
动态应用程序安全测试和扫描（DAST）	测试	动态应用程序安全测试和扫描工具（DAST）或交互式应用程序安全测试工具（IAST）
交互式应用程序安全测试（IAST）	测试	动态应用程序安全测试和扫描工具（DAST）或交互式应用程序安全测试工具（IAST）
手动安全测试（如渗透测试）	测试	各种工具和脚本（可能包括网络安全测试工具）
服务安全测试	测试	安全合规工具
部署后安全扫描	部署	安全合规工具
合规监控（资源和服务）	监控	合规工具、操作看板
合规性监控	监控	合规工具、操作看板
数据库监控和安全审计	监控	安全合规工具
运行时应用程序安全保护（RASP）	监控	安全合规工具
系统安全监控	监控	信息安全持续监控 (ISCM)
SBOM 软件组成分析	构建后期	SBOM和软件工厂风险持续监控工具
软件工厂风险持续监控	构建后期	SBOM和软件工厂风险持续监控工具
接口安全测试	构建	API 安全测试工具
合作和对抗测试	运维	合作和对抗测试工具
持续网络运营测试	运维	持续性网络运营测试工具
工程混淆	运维	工程混淆工具

从这个活动表我们可以看到在开发过程中，有三个关键的安全检测点, 即表格中我们标红的部分），以及文件中关于这三个检测点的信息合并成下表：

活动	基线	描述	输入	输出	依赖的工具
代码在提交前的静态分析	要求	在开发人员编写代码时对代码进行扫描和分析。通知开发人员潜在的代码弱点并提出补救建议。	源码、已知弱点	发现代码中的弱点问题	IDE插件
代码提交检查	要求	在将更改推送到代码仓之前，请检查更改中的敏感信息。如果发现可疑内容，它会通知开发人员并阻止提交。	本地提交的代码	检出的安全问题和警告	代码仓安全插件
静态应用安全测试	要求	对软件系统执行静态分析检查	源码、已知的安全问题和弱点	静态检查报告和修复建议	静态分析工具

从这个表格我们可以看到，在代码的开发阶段在以下检测点需要完成相应的静态分析检测：

在IDE，通过IDE安全插件，对需要提交的代码完成安全检测；
在代码仓，通过安全插件，进行的代码提交扫描，也是我们常说的“门禁”；
在构建，通过静态分析工具，完成静态应用程序安全测试和扫描（SAST）

《DevSecOps 基础指南：活动和工具》中，只提出了对流程检测点的需要有的活动要求和工具的粗略的要求，并没有给出具体的流程融合和该怎么在不同的检测点如何选择工具。

3. OWASP DevSecOps

开放全球应用程序安全项目（Open Worldwide Application Security Project （OWASP））是一个非营利性基金会，致力于提高软件的安全性。基金会致力于通过其社区主导的开源软件项目，全球数百个分会，数万名成员以及举办本地和全球会议来提高软件的安全性。

《OWASP DevSecOps 指导（OWASP DevSecOps Guideline》）指导我们如何实现安全管道和使用最佳实践，并介绍了可以在这件事上使用的工具。

指导在DevSecOps的实践中，还特别用一个章节介绍了预提交（pre-commit）的流程。如下图：
在这里插入图片描述

这张图清楚的给出了预提交的检查流程，并给出了在预提交中需要完成的两种检查：

确保代码中没有密码、密钥问题；
代码遵循Linter 规则。

这里的Linter 我找不到一个合适的中文来翻译这个英文。Linter 本意指的是衣服上在洗衣机洗完后，由于滚动摩擦会使衣物的纤维聚集在一起形成绒毛或纤维等的小球。以前想把这些多出来的"小球"去掉，后来人们发明了叫Linter的神器，一滚就能清除掉这种"小球"。

1978 年，工作于贝尔实验的Stephen C. Johnson 在 Debug 自己的 C 语言项目时，突然想到为什么不做一个工具来提示自己写的代码哪里有问题呢？这个工具也被称为 Linter。Linter是一种静态分析工具，主要用于发现代码中语法错误、潜在 Bug、代码风格等。我们常见的以lint命名的各种工具就是这一类型的静态检查工具。几乎每种语言都有自己语言的Linter工具，例如我们熟悉的：Java:checkstyle，Javascript:ESLint，Python:PyLint，C/C++:cpplint、Go:golint等等。

《OWASP DevSecOps 指导》中，给出了Linter的作用：
- 检测代码中的错误以及可能导致安全漏洞的错误；
- 检测格式或样式问题，并使代码更具可读性，从而获得更安全的代码；
- 检测建议的最佳实践；
- 可以提高代码的整体质量；
- 由于每个人都遵循相同的 linting 规则，因此代码的维护变得更加容易。
《OWASP DevSecOps 指导》中，将静态检查工具的按检查问题的不同定义成Linter 和高级静态检查工具：
- Linter工具是静态分析的最基本形式。使用 lint 工具有助于识别常见错误，例如：
  - 数组索引越界；
  - 空指针解引用；
  - （潜在）危险的数据类型组合；
  - 无法访问的代码（死代码）；
  - 不可移植的结构。
- 高级静态分析工具。高级静态分析工具通常提供：
  - 基于模式的检查;
  - 质量和复杂性指标；
  - 面向开发人员的最佳实践建议；
  - 支持多种以安全和安保为重点的编码标准；
  - 用于开发安全关键型应用, 例如：开箱即用的认证。

《OWASP DevSecOps 指导》给出不同工具检查缺陷类型的不同，主要还是说明在不同的检测点，需要配置不同类型的检查工具。

4. 安全左移

Capers Jones在《应用软件测量：生产力和质量的全面分析》中阐述了从软件工程实践角度出发，说明了大部分的问题在编码阶段引入，同时随着缺陷在开发过程中发现的越晚，修复成本越高。

所以我们希望通过将开发完后的测试工作融入到开发过程中，这样可以有效的降低开发过程中引入缺陷的修复成本。

测试向开发阶段左移
测试左移,缺陷在开发阶段减少

在DevSecOps概念提出后，人们很自然的就提出了“安全左移”的概念。“安全左移”（引自《OWASP DevSecOps 指导》中的定义）是一种将安全性嵌入到开发过程中的方法或解决方案，并从应用程序或系统设计的初始步骤开始考虑安全性。换句话说，安全性对从事软件开发和操作过程的每个人负责。当然，安全是一种职业，我们需要高技能的人来扮演与安全相关的角色;但在这种方法中，任何设计师、软件架构、开发人员、DevOps 工程师和…与安全人员一起对安全负有责任。

从这个描述中我们可以看到安全左移包括几个具体的活动：

安全从设计开始，贯穿整个流程；
全员参与安全活动；

根据前面我们对美国国防部《DevSecOps 基础指南：活动和工具》，以及OWADSP的《OWASP DevSecOps 指导》的了解，在开发过程的编码阶段有三个检查点：IDE、门禁、持续构建(CI)。按照"安全左移"的理念，我们是不是也可以“一路向左”, 将静态检查工具放到IDE或门禁中，实现静态检查工具的左移，从而去掉持续构建(CI)中的检查环节？是不是可以一路向左？

在这里插入图片描述

4.1. 成语故事“因地制宜”

好久没在博客里讲故事了。中国历史悠久、先贤们将各种为人、处事的道理、哲学融汇在一个个故事里，通俗易懂，并炼成了让人津津乐道的成语故事，源远流长，让普通人都能牢记这些哲理精髓，一代代传承。最近刀郎红火起来的歌曲，除了歌曲本身，人们更喜欢挖掘的是歌曲中包含的各种凄美故事。

春秋末年，楚王听信谗言，杀了伍子胥一家，伍子胥逃到了吴国。伍子胥为了借助吴国给自己报仇，给吴王献计：要想使国家富强，人民安定，首先要高筑城墙，这样才能加强防御力量，使其他国家不敢进犯。还要加强军事力量，充实武器及物资的储备，这样就能够对别的国家形成威慑之势。同时还要发展农业，只有农业发展了，国家才能富强，百姓才能安居乐业，将士们才有充足的给养，而且要充实粮仓，以备战时之需。这样国家才能安定，才有可能发展。吴王非常赞同伍子胥的战略。于是巧妙利用吴国的地形，建立起一座依山傍水的城郭。城中有多个城门，且其中三个筑有城楼。大城中还有东西两座小城，西城为吴王的王宫所在地，东城则是驻扎军队、存放军备的地方。就这样在城中设置守备、积聚粮食、充实兵库，为称霸诸侯做准备。经过一段时间的准备，吴国逐渐强盛起来。最后吴军大举进攻楚国，五战五胜，最后攻陷了楚国的国都：郢都。伍子胥终于报了杀父兄之仇。这就是“因地制宜”成语的故事。

从这个成语我们也悟出一个道理，对于开发阶段中，对静态分析的工具使用并不能"一路向左", 需要考虑检测点的差异, 选取合适的检测工具，才能建立有效的防御体系。

4.2. 建立三层代码的防护体系

我们通过下表可以清楚的看到三个检测点的差异，以及根据差异选用不同的静态检查工具，从而达到“因地制宜”的效果。

比较项	IDE	门禁	CI
扫描范围	模块级的代码	少量修改的代码文件	全量的工程代码
代码量差异	一般小于<10万LOC	修改量一般<500LOC，修改文件<10个	根据工程大小确定，可以达到亿级的代码量
编译环境	部分语言具备本地编译环境，C语言应编译器配置复杂	不具备编译环境	具备编译环境
工具配置	简单，开箱即用，可以有少量的配置，与IDE融合	有一定的配置，需要与pre-commit 融合	可以有复杂的配置用于规则的选择和规则参数的设置
工具使用	部分开发人员会使用	强制。注：IDE检查并不能保证开发人员一定执行了检查任务，这里通过强制手段，确保代码在入库前完成基本的安全检查	强制
分析精度	要求工具误报低，但允许有少量的误报	要求工具工具误报更低，减少因工具误报照成不必要的反复	容忍一定的误报率，建议<30%
分析效率	秒级扫描，不影响本地开发，最好事实完成检查	分钟级的扫描，建议<5分钟	小时级的扫描，在第二天上班前获得扫描结果即可
静态检查工具要求	编译/非编译型，单文件分析，基于语法树分析；在不影响效率或能到依赖信息的情况下，适度的进行跨文件的分析，提高检查范围和能力	非编译型，单文件分析，基于语法树分析在整体工程较小的情况下，通过CI完成全量检查	编译/非编译，跨文件分析，各种检查能力

DevSecOps 在实施过程中除了强调工具的配合实现各个检测点的自动化，更主要的是需要提供一套完整的工具整合平台，实现整体流程的自动化运行和监管。这也是为什么大部分的企业在实施DevSecOps的时候，都选择了通过云平台支撑DevSecOps的实施方式。

5. 华为云的三层检查体系

优秀的代码质量保障实践，往往将代码检查融入到开发作业流中，在用户代码编写、代码提交时进行自动化的审计检查，并对团队每日产出的代码进行持续编程规范和质量检查。

这一活动实践要求已是安全开发过程SDL、DevSecOps等众多优秀开发模式推荐进行的实践要求。
华为云代码检查服务（CodeArts Check）提供丰富的API接口、涵括任务新建、任务设置、任务扫描、任务报告解析等检查业务全流程，支持用户使用接口方式无缝集成到自建CI/CD或者CodeArts，作业数据灵活对接到客户看板，代码质量可视、可管理。
同时通过灵活的任务管理，支持排除目录设置避免无效扫描，并支持混合语言检查、简化部署、一次获取整个版本代码质量。

在这里插入图片描述