DevSecOps：应当做好的十件事

0xtuhao

发布于 2022-06-21 10:27:20

3930

发布于 2022-06-21 10:27:20

文章被收录于专栏：从运维安全到DevSecOps

本文介绍的便是《DevSecOps：初入江湖》中提到的《Gartner 2017调研报告》原文。

背景介绍

惨痛的教训告诉我们：DevSecOps很重要！

对于很多企业而言，云和DevOps是推动企业业务发展的关键的技术引擎。企业的IT、安全和开发人员都知道在云和DevOps环境中，有大量的敏感信息（如密钥和凭据）需要保护。尽管大部分人都有安全方面的意识，但我们仍能看到诸多的数据泄漏事件。

以2017年发生的Uber数据泄露事件为例：

“11月22日，Uber发布声明，承认2016年曾遭黑客攻击并导致数据大规模泄露。根据这份声明，两名黑客通过第三方云服务对Uber实施了攻击，获取了5700万名用户数据，包括司机的姓名和驾照号码，用户的姓名、邮箱和手机号。”

对于面向消费者的企业而言，信任是企业顺利发展的一个重要组成部分。然而，不幸的是，最近几年，企业或机构发生用户信息泄露事件正在变的越来越普遍，引发的危害及潜在的破坏不可估量。

调查发现，Uber数据泄露的原因竟然是工程师将解锁数据库的安全密钥被存储在GitHub的一个可以公开访问的页面。媒体将称作是“In major goof”（超级傻瓜）的失误。

然而，这类由于操作不当引发数据泄漏的事件并不是孤案，尤其值得注意的是，当今云环境和DevOps的迅速发展导致安全风险显著地提高了。安全公司 Detectify 的安全顾问 FransRosén 曾于2017年 7 月 13 日发布一份报告称“网络管理员经常忽略 AWS 访问控制列表（ ACL ）规则，因服务器错误配置而导致大量数据泄露。”

在网络急速发展的大数据时代，很多企业都贯彻着“敏捷”的思维和行动，这是一个危险的信号，而且正在不断的被验证着：越来越多的消费者、监管机构和市场发现由此所造成的数据泄漏的代价是高昂的、无法接受的。由于数据泄漏，你可能会看到市场资本中一夕之间损失数亿美元、消费者对企业和机构的信任度下降，在某些情况下，高管们的职业生涯可能会结束或停滞不前。毫不夸张地说，一些依赖数据生存的企业甚至可能在无意中因为一个密钥存储的疏忽而使整个企业面临灭顶之灾，至少竞争对手不会放弃这些机会。

事实上，通过实施最低限度的特权，很多数据泄露事件都是可以提前预防的。接下来，我们将重点讨论一下DevSecOps的概念，以及企业想要成功实行DevSecOps应采取的十项有效措施。

DevSecOps的概念

DevOps是Development和Operations的缩写，而DevSecOps则是Development、Security和Operations的缩写。John Willis(DevOps Cookbook合著者之一)称Patrick Debois是DevOps的缔造者，而DevOps的传道者们认为，DevSecOps的基本理念是让每一个解决方案、开发测试的多个跨部门协作人员都融入开发运维和安全的理念，并正确地理解DevOps的做法与含义。也就是说DevSecOps是一个项目组织方式，因此并不不存在DevOps者，更不是说将开发环境和生产环境整合在一起的意思，DevSecOps是一个群体做法，核心理念是：“安全是整个IT团队（包括开发、运维及安全团队）所有成员的责任，需要贯穿整个业务生命周期（从开发到运营）的每一个环节。”

将安全整合到DevOps的“DevSecOps”会带来思维方式、流程和技术的整体变化。安全和风险管理的领导者，必须坚持合作，DevOps的敏捷性意味着其在开发过程是无缝的和透明的，同理，“DevSecOps”中的“安全”也应当是沉默的。

企业在执行DevSecOps时通常会面临以下几个方面的挑战：

作为一名安全或风险管理人员，应当很清楚企业的业务发展是核心，因此向客户提供新的IT功能的产品开发团队才是王道，而不是信息安全或IT团队。
信息安全工作必须适应开发过程和相应的工具，而不是背道而驰。
组织使用DevOps生产新的应用和服务，DevOps相关的过程和工具也有责任遵照公司对其他应用程序的要求，产生安全且符合要求的代码。
要求应用程序达到百分百地安全是不现实的，企业一旦陷入“将安全漏洞的数量降为零”的错误追求中，安全测试的负担识别加重，且很可能成为业务发展的一个障碍。

因此，问题的关键是风险的控制和管理，而非单纯的追求安全。想要确保应用程序和数据安全，在进行安全和风险管理（Security and risk management，SRM）时，应当注意：

将安全和合规测试无缝地整合到DevSecOps中，使开发者专注工作在持续集成和持续部署工具链环境中。
持续的扫描已知的漏洞和配置错误，对象包括所有开源的和第三方组件。理想情况下，管理并维护一套完整的资产清单，便于完成对所有软件组件的分析。
不要尝试删除自定义代码中所有未知的漏洞，相反，应把开发人员看作放在最严谨和最自信的人。
鼓励尝试使用新的工具或方式，以减少与开发人员的摩擦，例如使用交互式应用安全测试（IAST）来取代传统的静态和动态测试。
把信息安全团队完美地融入DevOps进程中。
使用相同的统一的规范来处理所有自动化脚本、模板、图像和设计，并保证安全工作覆盖了所有的源代码。

企业对DevSecOps的战略规划

Gartner 分析师的调查结果显示：

2019年，超过70%的企业将实施DevSecOps的相关举措，实现针对开源软件和商业软件包的自动化安全漏洞和配置扫描，2016年这一数据低于10%。
2021年，80%的快速发展团队将实践DevSecOps的举措，2017年这一数字为15%。

当今，DevOps已经成为企业IT能力快速发展和持续交付的首选方法，正确的实施DevOps对企业发展至关重要。

尽管大多数情况下，DevOps未能合理的处置安全性和合规性的问题，但值得高兴的是，企业越来越重视这一情况，根据Gartner的调查数据显示，在受约束的环境中实施DevOps，最优策略是与信息安全紧密结合，如下图所示：

*来源：Gartner（2017年10月）

在过去的一年中，Gartner的调研数据显示，“如何安全地将安全性集成到DevOps中（即交付DevSecOps）一直是客户感兴趣的领域中关注度遮增长最快的结点之一，Gartner的分析师们进行了600多次的调查，不断的与不同的客户进行交流，沟通他们在DevSecOps方面实施了那些卓有成效的举措，通过分析这些案例，总结出了十项最佳实践，SRM的领导者如果想要成功的交付DevSecOps，可以优先考虑这些方法。

成功交付DevSecOps的十条建议

（1）使您的安全测试工具和过程能够很好的适应开发人员，而不是背道而驰

DevOps的哲学植根于它打破了传统IT领域的陈规，打通了开发和运营的脉络，然而，安全是另一个需要被移除和整合的领域。如果能正确的实施，DevSecOps里的“安全”应当是静默的，换句话说，DevSecOps的目标应该是尽可能的将“安全”无缝并透明地交付给开发者。

不要强迫DevOps开发者去适应信息安全的传统过程，相反，应当有计划的持续性的将安全无缝地集成到开发者的持续集成/持续部署（CI / CD）的工具和流程中。对于那些习惯于迫使开发人员遵从我们的流程的信息安全专业人员来说，重要的是要转变心态，因此有必要进行一些调整，例如：

不要使开发者离开他们熟悉的工具链环境。这意味着你的安全测试需要集成到开发者的开发环境（IDE）和CI/CD工具链的工具中（如Jenkins、Bamboo、Microsoft Team Foundation Server、Chef、Puppet 或Ansible）。
集成安全扫描，使信息安全专业人员不需要再扫描应用程序，例外情况下，才需要信息安全人员提供援助。应尽可能做到，一切对开发人员来说都是自动化的和透明的。
通过应用编程接口（API）构建安全性和合规性扫描平台，而不是通过安全厂商的本地控制台。测试结果应在通过你自己开发的仪表板来呈现（例如Sonar、Maven 或 Jenkins）。因此，要求所有安全扫描工具和服务都完全API化。
使用威胁建模工具作为非功能性需求的一部分，自动化简单的收集所有新增应用程序的安全需求。
通过开发者现有的漏洞跟踪过程（如JIRA或BugTraq），解决检测到的安全问题。
改变心态，将一次性的安全扫描转化成连续地安全保证过程，从项目一开始就将安全集成进去，并评估每一次新的迭代。

（2）不要试图在开发过程中消除所有漏洞

有一句流传了几百年的格言，后来因伏尔泰的推崇而闻名：

Il meglio è nemico del bene (Pescetti)

Le mieux est l’ennemi du bien (Voltaire)

这句话的意思是“完美是好的敌人/完美是效率的敌人”，其所揭示的寓意放到现在依然适用，尤其是在数字化商务领域，在那里，“信息安全驱动完美”的安全理念与企业和开发者对速度和敏捷性的需求往往是不一致的。

没有完美的安全，零风险是不可能的。对于DevSecOps而言，我们要做的是持续的风险和信任评估以及对应用程序漏洞进行优先级排序。为了消除应用程序可能存在的所有漏洞，我们将会放慢开发人员的进度，寻找那些不是真实的（误报）的问题，或者解决真正的、但不是直接或容易利用的低风险漏洞，无疑是在浪费开发人员的时间。

在测试速度、浪费开发者时间（误报和假阴性风险增加）之间需要权衡。实施DevSecOps时，信息安全人员必须接受：“零漏洞”既不可能也不可取，尤其是当它明显阻碍了新服务开发和创新步伐的时候。

此外，我们可以通过使用运行时保护控制来补偿已知的、较低风险的脆弱性或未知的脆弱性的剩余风险：

基于网络和主机的入侵防御系统（IPS）（以防止对已知的操作系统和软件包的攻击）。
Web应用防火墙（WAF）。
运行时应用程序自我保护。
将应用程序性能监视和应用程序安全监控融合在一起。
使用合适的僵尸网络缓解方案。
在应用层进行深度防御，包括负载均衡、拒绝服务和分布式拒绝服务保护。

思考并处理应用安全问题时，通过DevSecOps持续改进应用程序的开发和运营过程。需要明确，我们不需要消除开发过程可能存在的所有漏洞，运行时保护措施是DevSecOps战略的重要组成部分。DevSecOps是一个需要不断完善的过程，如下图所示：

安全不应止步于开发阶段（上图的左侧），整个DevOps生命周期都需要保护，包括新服务的部署后的运行阶段（上图的右侧）。安全，就像开发一样，成为一个连续的交付、学习和改进的过程。

在开发过程中执行基于风险的扫描，被接受的一些漏洞将运行时的持续评估来进行补偿。总之，如果没有监管方面的缺陷，那么可以接受多少风险并不取决于信息安全，而是由产品/服务所有者最终做出的商业决策。

（3）首要任务是识别并移除已知的严重漏洞

现代软件是组装而成的，而不是开发出来的。开发者们从公开可用的源代码和代码库（如GitHub，SourceForge，Maven central 和 Docker Hub）中收集并整合了大量的预编译组件、代码库、容器和框架（如Apache Struts和Swing）。自定义的代码在现代软件中所占的比例少之又少。

相应的，安全扫描的焦点也有所转移。大多数风险都可以通过识别这些公开库、框架和组件的已知的漏洞和错误配置来完成，问题解决之后才投入生产。从安全的角度来看，识别已知代码中已知的漏洞比自定义代码中的未知漏洞要容易得多。实现方式多种多样，最简单的一种方式是将文件与漏洞库相匹配。脆弱性评估供应商调整他们的扫描能力，将这些操作集成到DevSecOps中自动化的完成，诸如Docker之类的工具供应商也提供此类整合能力，这种最佳实践的重要性不能低估。Equifax公司因Apache Struts漏洞而遭遇数据泄露的教训十分沉重。

开源软件（OSS）提出了一个独特的挑战，因为开发人员可以简单地剪切和粘贴源代码，而不是关联整个库或框架。这样一来就不能简单地通过哈希值进行识别，，而是需要全面的扫描源代码本身。此外，OSS的使用可能因授权问题产生一些法律风险，因此建议使用商业软件组成分析（SCA）解决方案为应用程序构建详细清单，这个清单还有一个延长生命周期的好处，如果之后所使用的组件包含一个严重的安全漏洞，安全团队通过这份清单可以快速的查询并明确“哪些应用程序受到了影响”（例如，著名的Apache Struts或OpenSSL的Heartbleed攻击）。

评估应用程序已知漏洞的过程中，SRM负责人应该扫描：

开发人员工作相关的全部内容（包括虚拟机、容器和机器镜像），应充分考虑容器安全及相应的最佳实践。
所有嵌入的OSS代码的已知漏洞。
所有的OSS组件（包括库和框架）。
所有的操作系统文件、可执行文件和动态链接库。
所有平台文件（如Apache和Microsoft IIS）。
第三方商业性的代码库。
第三方公共的应用程序（如SQL Server和Oracle）。
与配置相关的漏洞（例如端口的打开/关闭、服务的激活和正在运行的进程）。

“扫描”的概念也应该扩展到识别恶意软件和敏感数据，而不仅仅是编码方面的漏洞。SRM负责人应该确保加密密钥和其他机密数据不会意外地嵌入到代码中。

（4）不要固守传统的静态/动态分析方法，应当适应新的变化

上文中我们强调了识别已知的组件、库和框架中的已知漏洞的重要性，但是对于应用程序中那些实际存在的10%～40%的自定义代码该如何处置呢？执行DevSecOps，意味着你应该寻找自定义代码的未知漏洞。但是，不要固守那些传统的针对应用程序安全测试的静态和动态分析工具和服务，要明白这些传统的测试解决方案需要被重构、调整或更换，具体步骤如下所示：

可以从把简单的测试直接集成到IDE开始。一些开发者提出基于IDE的安全扫描的指标无法被跟踪和报告，这可能成为与DevOps建立合作伙伴关系的契机。
所有的扫描工作应该是完全自动化的，在开发者的CI/CD工具链和诸如代码提交之类的事件处理过程中自动的通过APIs的方式触发，通过API引发开发商的CI / CD的工具链和过程事件像提交代码。第三方产品（如Cybric和BMC）可以帮助开发者实现安全检测自动化。
扫描不应该要求安全专家运行、配置或解释结果，开发者就可以做到。
扫描应该不断调整，以减少误报，即使是牺牲假阴性（漏报增多）。
扫描结果应直接运送到bug跟踪系统或开发者面板，这依赖于开发者使用的CI / CD工具和方法。

无论执行哪种安全扫描，SRM负责人都应该按风险把发现的漏洞进行优先级的排序，并提供给开发者。工作重点应放在减少误报，在充分信任开发者的基础上指导他们优先修复严重的漏洞。正是因为这个原因，几个AST供应商正在尝试使用机器学习来修正扫描结果。接受较低风险的漏洞是可以的，这些漏洞可以通过运行时的保护控制来减轻，或者在将来的软件迭代中加以解决。

考虑交互式应用安全测试（IAST）替代传统的静态应用安全测试（SAST）和动态应用安全测试（DAST）是可行的，我们建议这么做。IAST是在DAST基础上的一种该进形式，测试过程更加可视化，包括内部和外部的。IAST综合了DAST和SAST的优势，在确保测试代码覆盖率的基础上尽可能的做到了减少误报。然而，目前支持IAST的平台有限，需要应用程序在运行状态下才能执行IAST。如果IAST工具被用作开发者进行扫描的诱导工具，那么之后需要一套完善的全回归测试（而且最好是自动化的）进行配合。

一些AST供应商提供“测试即为服务”。可以将其融入DevSecOps中，但运作时间限于双方严格的服务水平协议（SLA）约定，使用IDE进行轻量级的、近实时的扫描。例如双方可以约定，四小时内扫描50%，八小时内扫描80%， 24小时内扫描90%，SLA还包括一些服务有效性的保障，不符合条件的话可能就会被罚款。注意，即使SLA约定的条款“时间紧迫”，以致于可能不适合极为迅速的DevOps周期，但供应商也应该通过API提供测试服务，确保开发人员仍能使用相同的应用程序“提交”代码进行测试或检索结果。

（5）培训所有开发人员基本的安全编码知识，但不要期望他们成为安全专家

DevOps产品团队的每个人都应该接收安全培训，培训内容因角色不同而有所不同。开发人员应当获得最多的培训，测试人员和产品负责人相对少一些。注意，尽管应当向所有开发人员培训基本的安全编码知识，但却无法让这些团队成员成为安全专家。例如，大多数应用层漏洞可以通过设置输入白名单和过滤掉多余的字符进行处理；SQL注入和跨站点脚本攻击的根本原因是在输入时缺乏适当的检测；同样的原则也适用于数据库和配置文件以及网络流量的输入检测。

重点推荐OWASP Top10和类似的公开可用的安全测试指南。培训应包括：

如何构建并维护简单的威胁建模场景（像坏人一样思考）
设置输入白名单，对用户的输入和文件进行过滤和消毒
- SQL注入
- XSS
- CSRF
注射
破坏认证和会话管理
不安全的直接对象引用
安全性的配置错误
基本的安全防护
- 为什么不能在应用程序代码或脚本中嵌入密钥或凭据？
- 打补丁的重要性
- 为什么黑客专注于盗窃管理员的凭据？如何避免此类攻击？

理想情况下，第一次培训时应当由相关人员当面进行，之后定期进行年度培训，同时运用线上培训的方式加以强化。此外，如果在开发中发现了安全问题，则可以根据需要对开发人员或团队进行进一步的具体培训。例如，如果在开发人员的代码中发现了一个严重漏洞，则可就该问题上进行进一步的培训，避免问题再次发生。

（6）采用安全捍卫者模型，并实现简单的安全需求收集工具

在《DevOps Security Champions Help Organizations Gain Leverage Without Training Everyone 》一文中，我们建议企业使用安全捍卫者模型，将有效的信息安全团队资源充分应用于开发组织。将安全捍卫者的头衔授予组织中能够担当现场顾问和专家的员工，他们可以在开发过程的早期就预见到可能存在的潜在的设计或实现问题。

安全捍卫者可以有效提高复杂的安全编码问题的感知度，他们能够提供及时的、针对团队编码过程中遇到的实际问题提出修复方案，而不是抽象的、不可靠的问题。例如，对于风险为低级或中级的新应用程序开发项目，安全捍卫者可以作为安全需求收集和威胁建模的起点。推荐企业使用一个简单的安全需求收集和威胁建模工具，使得开发人员尽可能地轻松完成任务。对于风险级别高的应用程序，目标应该尽可能的提高，建议直接联络信息安全团队进行全面地威胁建模和安全需求收集。

SRM负责人应该识别那些对安全感兴趣的开发人员，并为他们提供一个扩展的角色，即安全捍卫者。这样做会使有限的安全培训的效果更佳，为敏捷开发过程和DevOps团队成员提供一定级别的安全监督。

（7）禁用源代码中已知的易受攻击的组件

前文已经提及，现代应用程序的大多数风险是由于使用已知的易受攻击的组件、库和框架导致的。与其等到应用程序组装好之后在扫描环节才被识别出这些已知漏洞，提前警告开发人员不要下载和使用这些已知的易受攻击的组件可能是更好的解决问题的办法，尤其是当存在严重漏洞时，可以选择提前阻止开发人员下载。

实际开发环境中，是否允许开发者从互联网上下载代码的问题应由安全和开发架构师共同协商处理。某些组织认为这样做的风险很高，因此开发人员被阻止直接从Internet下载这些风险组件；还有一些组织，会限制用户将代码托管到公共代码平台上（如GitHub）。

开发人员下载的代码库中可能包含较老的、已知的易受攻击的软件版本。为了解决这个问题，一些提供商提供了“开放源码软件防火墙”，以便向开发人员披露这些代码库的安全态势，便于更好的决策使用哪个版本的软件。通过这种方法，开发人员可以明确的清楚那些组件和代码库存在严重漏洞，避免下载并使用（例如，可以使用漏洞的CVE评分来判断该漏洞的严重程度）。

对于那些不允许开发人员直接从公共Internet下载代码的组织，需要考虑使用安全的代码存储库模型，此时，需要信息安全团队与开发团队协同合作，建立、审查并维护这些组织内部托管的组件存储库，在这个过程中，开发架构师和信息安全工程师之间应保持联系，随时更新开发人员请求使用的新框架和代码库。此外，一些机构会要求使用符合安全需求的、预先批准的、标准化的代码库或组件（如认证、授权、密钥管理、加密、点击劫持和输入过滤），以便于进一步降低风险。

（8）使用自动化脚本确保并践行操作的规范化

不要对基础设施和运营平台的安全管控。想要实践“基础设施作为代码”的话，针对基础设施也应当有类似源代码控制一样的措施，包括所有的软件项目的版本控制（如配置脚本和可执行文件）。应确保这些控件使用了正确的脚本版本，平台控制和配置脚本不应包含机密信息（如凭据、密钥或其他公开的漏洞）。可能的话，需要针对这些工具进行专门的安全扫描。

对于这些自动化代码、脚本、方法或生成脚本的工具等基础设施和平台构件，应看作具有特定附加风险的有价值的源代码，因此，有必要对它们使用源代码相关的安全管控，包括审计、保护、数字签名、变更控制和版本控制，以保护这些基础设施和平台构件。

容器和容器管理系统必须具有记录并留存变更控制信息的功能，确保所有已知的漏洞已经被妥善处理。

总而言之，所有变更都应当有明确的记录。

（9）使用强大的版本控制措施管理所有代码和组件

在软件开发的整个生命周期中，使用适当的工具（如分布式版本控制系统DVCS和应用程序生命周期管理ALM工具）进行恰当的源代码版本控制。

在快速更迭的开发环境中，捕捉变更的每一个细节至关重要，包括代码的出处、更改的内容、时间和操作者，以及是否已经获得了相关授权（例如，其他产品经理的产品可能受到变更的影响）。在大多数情况下，并没有一个明确的权限模型，但是这种情况可以适用“信任和验证”的原则，使用一些方法获知某人调用了某个API或使用了某些代码。明确使用的代码与生产中实际使用的代码之间的区别，这样做有利用在将来的迭代中通过删除未使用的组件来降低风险，或者删除那些存在漏洞但却未实际使用到的代码。

代码从预发布到生产，检测代码的数字签名，并确保最终的版本是最后一次扫描过的版本。注意，在代码运行时不要实例化，无需确认它是否被篡改，代码配置即防篡改确认是“防护”阶段的功能。平台运营团队将使用传统的变更控制技术（包括ITIL方法）为产品团队提供底层的基础设施和平台。

（10）默认的基础架构应当是“不可变的”

对于经常更新的现代化应用程序而言，维护这些应用程序需要采用一种更安全的操作方式。在可能的情况下，不允许任何人直接对生产系统进行更改。基础设施应当是“不可变的”。当需要更新时（包括安全补丁和配置更改），这些需求应该返回到开发阶段并由自动化工具进行部署。

生产的镜像（包括库、组件和OS）应当保存在安全的存储库中。如果某个文件需要修补，请在安全的存储库中进行，而不是直接在生产系统上修改。此外还需要确保新修补的应用程序可以使用现有的DevOps流程进行部署。要知道大多数的安全事故和操作不当导致的事故产生的根本原因是管理不删或未打补丁，流程规范化可以带来安全和操作上的益处。

从操作和安全的角度来看，许多现代容器和工作流程系统都包含自动化的健康监测功能，当偏离预期状态时会发出警报。如果工作流程行为怪异或与正常状态相比偏移过多，则可以从活动资源池中删除它，用清洗后的良好状态的工作流程取代它。

从安全的角度来看，这种模式是先进的，并且有可能从根本上提高安全性，通过主动“杀掉”目前的工作流程，并用已知的良好状态替换它们，即使它们看起来是“健康的”。假设一个聪明的黑客以某种意想不到的方式在系统中获得了立足点，通过周期性地、随机的杀死工作中的进程，可以使得攻击者的立足点丢失，无法获得持久性。五年前，曾提出过一种“利用系统的工作流程作为一种对抗对抗高级持续性威胁的策略”的概念，那时候还只是一种愿景，但现在技术的发展使得这种方法成为可能。