软件开发中，如何为你的代码构建三层防护体系
本文分享自华为云社区《构建DevSecOps中的代码三层防护体系》，作者：Uncle_Tom。在DevSecOps的应用过程中，静态分析工具在开发阶段承担着非常重要的代码质量和安全的看护任务。本文根据开发过程的不同位置的开发环境、代码特征以及检测工具能力的差异，提出了需要因地制宜地部署检查工具，形成递进的三层代码安全防御体系，从而提高应用软件整体安全性，同时又能有效的贯彻安全左移的策略，降低安全问题的维护成本。
1. DevSecOps
近年来，大型企业DevSecOps引入占比逐年递增，从2020年的41.3%增至2022年超63.5%, 其复合增长率超过20%。
DevSecOps一词最早由Gartner在2012年提出，并在最近几年逐步成为软件开发种的热点。DevSecOps在开发人员、测试人员、安全团队和运维团队之间架起了桥梁；它改善了团队之间的沟通和协作，其目标是更快、更高效地交付。DevSecOps，在DevOps的基础上增加了安全的活动，在保障快速开发、快速的部署的基础上，提高了安全性，内嵌安全到应用程序中，能够更迅速地应对安全威胁。
下图是美国国防部（Department of Defense（DOD）） 定义的DevSecOps软件生命周期的9个阶段：计划、开发、构建、测试、发布、交付、部署、操作和监控。安全嵌入到每个阶段。DevSecOps生命周期具有很强的适应性，并且有许多反馈循环来驱动持续改进。DevSecOps 在管理理念、管理方法、组织结构、开发流程、软件开发、开发平台、工具集成、以及企业文化等方方面面对传统的软件开发提出了新的挑战。
https://alliance-communityfile-drcn.dbankcdn.com/FileServer/getFile/cmtybbs/519/984/817/2850086000519984817.20230922100250.88512708403829483628176105784412:50001231000000:2800:4B94A2B43282594304C34F887C318B659D104A224167C99D5A442B351F851B42.png
在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）的流程。如下图：
https://alliance-communityfile-drcn.dbankcdn.com/FileServer/getFile/cmtybbs/519/984/817/2850086000519984817.20230922100300.31473610579483748350629838573366:50001231000000:2800:CBD0CD4BB511B5A14A2A2277B80FAEBAC8A971A9E62FFF13D5218AC8D09A5875.png
这张图清楚的给出了预提交的检查流程，并给出了在预提交中需要完成的两种检查：
[*]确保代码中没有密码、密钥问题；
[*]代码遵循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在《应用软件测量：生产力和质量的全面分析》中阐述了从软件工程实践角度出发，说明了大部分的问题在编码阶段引入，同时随着缺陷在开发过程中发现的越晚，修复成本越高。
所以我们希望通过将开发完后的测试工作融入到开发过程中，这样可以有效的降低开发过程中引入缺陷的修复成本。
[*]测试向开发阶段左移
https://alliance-communityfile-drcn.dbankcdn.com/FileServer/getFile/cmtybbs/519/984/817/2850086000519984817.20230922100340.62858395515941778623780712599431:50001231000000:2800:C6E8216E070A439F24AA06EA0526F33BB7976092640F0F3C81808A2E3AC8E965.gif
[*]测试左移,缺陷在开发阶段减少
https://alliance-communityfile-drcn.dbankcdn.com/FileServer/getFile/cmtybbs/519/984/817/2850086000519984817.20230922100350.73888295072290959157220276884290:50001231000000:2800:55BCA4A914E7ADB09ABD23871454AF262A446DA7F859B48A23BC6CC6CC00086F.gif
在DevSecOps概念提出后，人们很自然的就提出了"安全左移"的概念。“安全左移”（引自《OWASP DevSecOps 指导》中的定义） 是一种将安全性嵌入到开发过程中的方法或解决方案，并从应用程序或系统设计的初始步骤开始考虑安全性。换句话说，安全性对从事软件开发和操作过程的每个人负责。当然，安全是一种职业，我们需要高技能的人来扮演与安全相关的角色;但在这种方法中，任何设计师、软件架构、开发人员、DevOps 工程师和…与安全人员一起对安全负有责任。
从这个描述中我们可以看到安全左移包括几个具体的活动：
[*]安全从设计开始，贯穿整个流程；
[*]全员参与安全活动；
根据前面我们对美国国防部《DevSecOps 基础指南：活动和工具》，以及OWADSP的《OWASP DevSecOps 指导》的了解，在开发过程的编码阶段有三个检查点：IDE、门禁、持续构建(CI)。按照"安全左移"的理念，我们是不是也可以"一路向左", 将静态检查工具放到IDE或门禁中，实现静态检查工具的左移，从而去掉持续构建(CI)中的检查环节？是不是可以一路向左？
https://alliance-communityfile-drcn.dbankcdn.com/FileServer/getFile/cmtybbs/519/984/817/2850086000519984817.20230922100402.14986701344163403884128822505031:50001231000000:2800:FB98A736F3FE210E4C812354E4A1DECF096A7B69CB85DA375FC4F76605993419.png
4.1. 成语故事“因地制宜”
好久没在博客里讲故事了。中国历史悠久、先贤们将各种为人、处事的道理、哲学融汇在一个个故事里，通俗易懂，并炼成了让人津津乐道的成语故事，源远流长，让普通人都能牢记这些哲理精髓，一代代传承。最近刀郎红火起来的歌曲，除了歌曲本身，人们更喜欢挖掘的是歌曲中包含的各种凄美故事。
春秋末年，楚王听信谗言，杀了伍子胥一家，伍子胥逃到了吴国。伍子胥为了借助吴国给自己报仇，给吴王献计：要想使国家富强，人民安定，首先要高筑城墙，这样才能加强防御力量，使其他国家不敢进犯。还要加强军事力量，充实武器及物资的储备，这样就能够对别的国家形成威慑之势。同时还要发展农业，只有农业发展了，国家才能富强，百姓才能安居乐业，将士们才有充足的给养，而且要充实粮仓，以备战时之需。这样国家才能安定，才有可能发展。吴王非常赞同伍子胥的战略。于是巧妙利用吴国的地形，建立起一座依山傍水的城郭。城中有多个城门，且其中三个筑有城楼。大城中还有东西两座小城，西城为吴王的王宫所在地，东城则是驻扎军队、存放军备的地方。就这样在城中设置守备、积聚粮食、充实兵库，为称霸诸侯做准备。经过一段时间的准备，吴国逐渐强盛起来。最后吴军大举进攻楚国，五战五胜，最后攻陷了楚国的国都：郢都。伍子胥终于报了杀父兄之仇。这就是“因地制宜”成语的故事。
从这个成语我们也悟出一个道理，对于开发阶段中，对静态分析的工具使用并不能"一路向左", 需要考虑检测点的差异, 选取合适的检测工具，才能建立有效的防御体系。
4.2. 建立三层代码的防护体系
我们通过下表可以清楚的看到三个检测点的差异，以及根据差异选用不同的静态检查工具，从而达到“因地制宜”的效果。
比较项IDE门禁CI扫描范围模块级的代码少量修改的代码文件全量的工程代码代码量差异一般小于
页:
[1]