DevSecOps 实践

引言

国内由于《网络安全法》及安全等保2.0标准的实施，以及公司业务的国际化，互联网时代数据安全的重要性开始超越业务质量和稳定性，各大公司都能看到正在组建独立的信息安全团队，他们的职责也不再仅限于安全漏洞的测试挖掘，还包括安全合规，安全风控，安全攻防，安全审计，安全管理等等，贯穿研发业务管理各个环节，正在形成一个独立稳定的基础设施团队。信息安全团队风光的背后，我们经常也会听到以前在传统测试团队听到的质疑，“安全渗透测试主要都依靠手动挖掘，如何提升安全团队的测试效能？”、“安全漏洞问题，都是安全团队的责任吗，直接负责编码的工程师没有责任？”安全从业者也一直在反思并尝试将自动化的安全检测、自动化的安全代码检查融入到 DevOps 的体系中。

DevSecOps 是一场关于 DevOps 概念实践或艺术形式的变革。为了更好理解它，我们应该首先理解 DevOps 的含义。

在著名的 DevOpsDays 之后，DevOps 被越来越多的人所熟知并迅速得到了大多数人的认可。人们认为这正是IT部门的正确运作方式，DevOps 成为了一种促成开发运维合作的运动。人们在各种场所和活动中不断分享自己的经验和见解，并催生了很多工具和实践的产生。但是，每个人对 DevOps 的理解都有所不同，争议在所难免。

这些争议促社区统一化 DevOps 的定义。于是博客 The Agile Admin 发表了“ What is DevOps ”这篇文章。该文给出了详细 DevOps 的定义，并且依据敏捷的体系构造出了DevOps 的体系: 它包括一系列价值观、原则、方法、实践以及对应的工具。并且梳理了 DevOps 的历史和对DevOps 的一些误解。它定义了DevOps是什么，不是什么。

DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.

DevOps是一套结合了软件开发(Dev)和信息系统运维(Ops)的实践，旨在缩短系统开发生命周期，提供高质量的持续交付。它是一种重视 “软件开发人员（Dev）” 和 “ IT运维技术人员（Ops）” 之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。定义很抽象。但是具体来说，在DevOps中通常会讨论三个主要的实践领域。

• 基础设施自动化 - 将系统、OS配置和应用程序部署创建为代码进行自动化管理

• 持续交付 - 以快速和自动化的方式构建、测试和部署应用程序。

• 可靠性工程 - 系统运维、监控和编排，当然，首先是为可维护性进行设计

虽然DevOps的定义看起来很完美，但是，组织中的一些人就会有抱怨，例如：网络管理员，安全人员，他们会说为什么把我们排除在外？！创建产品或系统的所有参与者都应该从一开始就进行协作——各种类型的业务人员、各种类型的开发人员和各种类型的操作人员，当然所有这些都包括安全、网络和其他任何相关人员。所以在DevOps的定义中增加了一条：

那么问题来了，既然都包括在内，如何让安全人员高效的参与到整个DevOps的工作方式中来？DevOps并没有给出答案。

产品安全性必须在应用程序的整个生命周期中扮演集成角色。传统的开发模式往往是在最后产品的安全测试交给专门的测试团队来做，他们往往是跟开发团队隔离开的一个独立的甚至是第三方公司的团队。在DevOps的交付节奏下，这显然行不通。迫切需要安全团队需要跟DevOps团队一起工作。

在此背景下，2012年，高德纳(Gartner)咨询公司研究员David Cearley提出DevOps的定义需要修改，使之包括安全理念，他称之为DevSecOps。它是糅合了开发、安全及运营理念以创建解决方案的全新方法。Gartner公司在2016年9月发布的报告DevSecOps: How to Seamlessly Integrate Security into DevOps中对该模型进行了详细的分析，并列举了对应的最佳实践。此后，DevSecOps一词很快成为热门词汇。

DevSecOps可以理解为将安全性融入到DevOps的过程中，在整个开发和运维的过程中将安全作为一项重要的考虑因素，最终保证产品在整个生命周期内的安全性。

利用DevSecOps实现安全自动化可以在提高研发运维效率的同时增强应用的安全性。以下是DevSecOps宣言，它定义了相关的价值观和原则。

• 向前一步胜过说不Leaning in over Always Saying “No”

• 数据和安全科学胜过害怕、不确定和质疑Data & Security Science over Fear, Uncertainty and Doubt

• 开放性的贡献和合作胜过单纯的安全性需求Open Contribution & Collaboration over Security-Only Requirements

• 可用的基于API的安全服务胜过强制性的安全控制和文档Consumable Security Services with APIs over Mandated Security Controls & Paperwork

• 业务驱动的安全分数胜过橡皮图章的安全审核Business Driven Security Scores over Rubber Stamp Security

• 红蓝团队漏洞测试胜过依赖扫描和理论上的漏洞Red & Blue Team Exploit Testing over Relying on Scans & Theoretical Vulnerabilities

• 24*7主动安全监控胜过安全事件通告后的应急响应24x7 Proactive Security Monitoring over Reacting after being Informed of an Incident

• 共享威胁情报胜过保持自己的信息Shared Threat Intelligence over Keeping Info to Ourselves

• 合规运营胜过剪贴板和检查清单Compliance Operations over Clipboards & Checklists

DevSecOps是一种“每个人都对安全负责”的IT安全方法。它涉及到将安全实践注入到组织的DevOps管道中。目标是将安全性合并到软件开发工作流的所有阶段。

让我们回顾下传统的瀑布开发模型中安全测试基本上放在系统上线的前一刻，往往针对安全测试的结果都没有足够的时间和成本去做调整，在DevOps中显然不行，产品是持续交付的，最快甚至1-2周就发布，在这么短的时间内，我们不可能还和之前一样做安全测试。如何把安全无缝的集成到敏捷和DevOps开发中，就是DevSecOps关注的方向。

总的来说，人、技术和流程的三位一体在DevSecOps的实践中扮演着重要的角色。

everyone is responsible for security

无论企业在其他方面有多擅长，如果管理层或员工对产品安全不感兴趣或不愿意花费成本，那么有效的DevSecOps环境是不可能的。

说服高级管理层做出转变可能是一项艰巨的任务。但事实是，由于安全效率低下，频繁发生严重而引人注目的数据泄露和黑客攻击却有助于这种转变。安全专家和“安全冠军”将在DevSecOps中扮演关键角色。

关于实行DevSecOps对管理者来说有个误解就是组织需要信息安全的专业人员，其实不然，除非你不能有效地培训你现有的员工，或者你的开发人员对DevSecOps的转变不感兴趣，否则你还没有必要提高你的招聘上限。DevSecOps的目标是打破壁垒。您的开发团队由具有不同技能的人员组成，他们将接受有关DevSecOps流程和方法的培训，这些流程和方法应该适用于整个交付过程。因此，你可以整合现有的团队——而不是雇佣一个新的DevSecOps工程师。

DevSecOps工程师越来越受欢迎，这个角色需要补充一些特别的技能，必须具备对DevOps原则、实践和文化的全面了解。候选人应该对Java、Python等语言有很强的理解能力。一个好的DevSecOps工程师还应该知道诸如Chef、Puppet、Ansible和ThreatModeler之类的程序（当然主要看组织的技术栈）。

除此之外，DevSecOps专业人员必须了解风险评估和威胁建模技术的复杂性。他们将掌握最新的网络安全威胁、现代最佳实践和其他相关软件的知识。至于工作经验，DevSecOps的丰富的工作经验当然是最理想的。而且以前在非DevOps IT安全方面的经验可以为DevSecOps工程师的转型提供很好的基础。

安全团队应该熟悉应用的底层逻辑及架构，不应该跟开发和运维团队有沟通上的隔阂。我们公司内部使用Security Master项目来组建安全虚拟团队，该项目曾经在多个产品线中经历实战和优化，当前已形成了一套行之有效的方法和流程。

具体来说就是从每一个敏捷团队中选出一个经验丰富的人员担任Security Master，这个人最好不要是Scrum Master，因为某些时候ScrumMaster的工作会跟Security有冲突。Security Master在每个Sprint会预留30%的时间开展安全相关的工作，当然这并不意味着所有的安全工作都由他来完成，这个角色主要承担相关工作的驱动，以完成安全团队约定的目标。然后每两周进行一次安全的同步会议，进行工作总结，下一阶段的计划、知识的分享等。

拥有一个在安全问题上受过良好培训的工作人员，对组织的安全来说至关重要。安全意识培训是让人们了解安全问题、 以便他们能更好地识别并响应问题的过程。是面向所有员工的。

那么什么样的安全意识培训是有效的？

安全意识培训计划有效性的一个关键衡量方法：人们在面对某些情况时，他们行为改变的程度。如果这种改变是朝着更好的安全态势发展，那么我们可以推断出整体计划是有效的。安全意识培训通常涵盖以下内容：

1.社会工程

社会工程是操纵个人，以便他们执行那些违反安全协议的行为的过程，例如员工出了公司的大门就不建议佩戴工卡以便被攻击者尾随攀谈了解内部情况。网络钓鱼也是常见的攻击手段。其中最典型的就是电子邮件网络钓鱼（手机短信之类的文本也有类似的效果）。还有针对高级管理员的鱼叉式网络钓鱼-捕鲸。

2.上网安全

这个主要是让组织员工不要上非法或涉黄网站，以及到官方网站下载安装包，以免三方平台在安装包中植入病毒或木马程序。

3.数据保护

所有敏感数据都必须是被加密的。未加密的数据如果存储在未授权的在线资源中或与他人共享时就容易有泄露的风险。

4.文化

文化是一个抽象的概念，具体的就看是否有这样的环境使员工能安心的进行自我报告安全相关的事件？这些举动是否被激励？他们在遇到奇怪或可疑情况时积极地寻求信息和指导？这些自我报告和信息请求体现了组织文化是否会帮助或阻碍我们保护产品或系统。

为了达到安全内置，管理层需要重新对DevOps的流程进行设计，并提出安全的要求。并在开发和运营中使用安全工具进行全程监管。引入自动化的安全控制机制贯穿到整个SDLC中。

除此之外，对风险和漏洞的管理流程也需要额外注意。

安全风险来自安全（含隐私影响）评估。安全评估在需求设计阶段就会实施，有效方法就是根据威胁建模的方法来识别产品的风险。这里不展开威胁建模的具体实施方法。

一般流程就是识别信息资产，识别脆弱性和威胁，识别风险，评估风险，处理风险。

识别出来的风险要和产品经理一起分析定级，一般是做定性分析（因为定量分析没有办法完全适用，例如对公司声誉的影响，会损失多少钱就无法进行定量分析）。

对于定级后的风险需要做mitigation计划，处理风险的手段包括：转移、规避、缓解、接受。

在处理后，剩下的风险我们称之为剩余风险，需要指定review的计划，因为随着环境的变化，一些级别不高的风险级别可能会上升。

安全评估也不是一次性的活动，一般一年需要做一到两次，中间要做一次剩余风险的review和相关风险处理的实际实施情况。

漏洞来自一些安全扫描工具或者渗透测试活动，安全团队对识别的漏洞和脆弱性进行分级评估。这些漏洞的主要来自两个层面。一个组件本身的漏洞，另外一个是整个产品层面，包括运行环境的安全（例如操作系统的漏洞）。这两个层面的管理是不一样的。

对组件本身的漏洞，我们一般由开发团队自己进行处理。对共性的问题，有安全团队进行分析和分享，作为技术债务由开发团队进行处理。

对产品和运行环境方面的漏洞需要进行漏洞的生命周期管理，下图是漏洞的生命周期的定义。

写报告可能是安全专业人员最不喜欢的任务之一，但它通常是最关键的任务之一。安全测试需要输出测试报告，产品发布需要一系列的安全相关报告，例如安全性声明，安全和隐私说明等等。对这些报告而言，技术人员相对容易一点。

但是往往会忽视对管理层的汇报报告。特别是管理层是非技术出身的时候，一份好的技术报告应该能反应投入到安全的成本。类似这样的报告至少要包括威胁、漏洞、利用的可能性及利用后的影响、建议措施。特别是要将重要发现和建议转化为对组织高级领导层来说可以理解且有意义的语言。毕竟他们的支持能提供对安全控制做持续优化所需要的资源。

DevSecOps背后的哲学就是把安全shift left，也就是尽早的把安全考虑在内，从需求阶段就需要引入安全方面的基本需求，例如认证和授权，数据加密等，以做到安全及隐私保护方面的法律合规。对于一些关键的产品来说，还意味着需要更多安全方面的需求，例如防火墙产品。我不太喜欢这个词，从字面上理解好像就是把安全相关的工作在前期就解决掉似的。

实际从上面流程中可以看到安全控制会融入到DevOps中的每个阶段，凭借手工来做安全的控制和测试几乎是不可能的。在一些优秀的企业团队中，他们的发布周期能做到2周一个版本。所以自动化就成为必然。

我们把SDLC的各个阶段相应的安全控制称之为安全门，在CI/CD 管道中，每个安全门通过后才会进入到下一阶段。下面列出的是一些常见的安全门控制。

• 安全及隐私的基本需求来自法律法规的要求，以及安全架构及策略方面，例如集中认证和访问控制、安全事件日志，加密算法、密码策略等。

• 供应链安全包括引用的第三方商业或开源的产品可信来源，内部漏洞扫描等。

• 安全编码是针对开发人员写出安全代码的一组实践或准则，可以参考《Secure Coding Guidelines for Java SE》《SEI CERT Coding Standards》

• 容器安全包括使用可信来源，基础镜像的选择和硬化，关于制作安全的应用镜像可以参考《CIS Docker Benchmarks》CIS是一个有远见的、非盈利的组织，利用全球IT社区的力量来保护私人和公共组织免受网络威胁。CIS发布的一系列benchmark是保护IT系统和数据免受最普遍攻击的全球标准和公认的最佳实践。由经验丰富的IT专业人员组成的全球志愿者社区不断完善和验证这些经过验证的指南。

• 软件组合分析(Software Composie Analysis) 是将开源软件(OSS)的可见性自动化的过程，用于管理他们的风险管理、安全和许可证合规性风险。SCA允许在整个软件供应链中对开源软件的使用进行安全风险管理，所以需要为所有应用程序创建准确的物料清单，持续监控他们的他们漏洞信息。

• 静态应用程序安全性测试（SAST）是一组用于分析应用程序源代码、字节码和二进制代码的技术，用于对表示安全漏洞的编码和设计条件进行分析。SAST分析处于非运行状态的应用程序。

• 动态应用程序安全测试(DAST)技术的目的是检测应用程序在其运行状态下的安全漏洞。大多数DAST解决方案只测试支持web的应用程序的公开HTTP和HTML接口，但是，有些解决方案是专门针对非web协议和数据畸形设计的(例如，远程过程调用、会话发起协议[SIP]等)。

• 交互式应用程序安全测试（IAST）是2012年Gartner公司提出的一种新的应用程序安全测试方案，通过代理、VPN或者在服务端部署Agent程序，收集、监控Web应用程序运行时函数执行、数据传输，并与扫描器端进行实时交互，高效、准确的识别安全缺陷及漏洞，同时可准确确定漏洞所在的代码文件、行数、函数及参数。IAST相当于是DAST和SAST结合的一种互相关联运行时安全检测技术。

• 软件签名主要使得客户能够检查所收到的软件产品是否确实来自本公司，并且软件没有被篡改。通过使用非对称加密机制对软件进行签名，可以建立对原始软件的信任和所接收软件的完整性。

• 贸易合规性检查主要是确保公司遵守所有与跨境出口、转口、进口、转让、装运或任何其他商品、技术、软件或服务相关的适用法律法规。贸易遵守领域还包括遵守制裁和禁运。主要是对使用是第三方软件，加密算法等的合规性。

• 运维安全监控主要基于IDS(Intrusion Detection System)和IPS(Intrusion Protection System)S技术及其他各个组件的审计日志。

DevOps实现了产品的快速迭代和发布，这些离不开自动化工具的支撑。在这种工作方式下，手工进行安全扫描和测试是行不通的，DevSecOps本质上就是需要将安全内嵌到CI/CD管道中。即使部分工作没有办法自动化，但是整个部分可以而且应该是自动化的。从开发到试产，安全性应该是优先考虑的，并且应该是自动化的、可重复的和一致的。如果能正确处理，对安全漏洞的响应会更琐碎，因为每一步都会减少修复和减轻漏洞所需的时间。这就是Security Shift Left的精髓，会避免把安全问题留到最后解决。

所幸的是针对上面的安全门，大部分都有对应的自动化工具可以使用，例如针对SCA可以使用OWASP Dependency Check，vulnerability-assessment-tool等，他们可以扫描开源软件的漏洞，静态代码安全扫描（SAST）可以使用FindSecBugs（有IDE相关的插件和Jenkins插件可以集成），动态外部扫描（DAST）使用OWASP ZAP等等。交互式应用测试（IAST）使用Seeker工具等。针对各个工具扫描出来的漏洞由Faraday进行统一集中管理。

• 容器安全

- CIS Docker Bench用于检查生产环境中部署Docker容器的许多常见最佳实践。基于CIS Docker Benchmark的检查工具

- Anchore, clair 等也是扫描Container镜像的工具

XRay(JFrog)公司出品集成到Artifactory，这个会比较方便，特别是是使用Artifactory作为内部仓库

• SCA

- Eclipse Steady，该工具分析Java和Python应用程序，以便检测它们是否依赖于有已知漏洞的开源组件，以及支持开发人员减少此类依赖。它是一个活跃的开源项目

- OWASP Dependency Check 检测包含在项目依赖项中的公开暴露的漏洞。它通过确定给定依赖项是否有公共平台枚举(CPE)标识符来做到这一点。如果找到，它将生成一个链接到相关CVE条目的报告。

• SAST

- FingSecBugs

- Sona

• DAST

- OWASP ZAP

- Arachni是一款开源Web应用程序安全扫描程序框架，支持主流操作系统，其简单的REST API使集成变得轻而易举。官网 http://www.arachni-scanner.com

• IAST

- Seeker（商业）

• 漏洞及端口扫描

- Nmap 除了可以扫描暴漏的端口外，还能使用特定的脚本进行漏洞扫描。

- Openvas

- Nessus

不可能一开始就有一个完全顺利的过程。许多组织放弃，因为时间被浪费在试图使事情完美运作。采用DevSecOps是一个漫长的过程，但是一旦完成，它可以显著地改进整个操作过程。试图在开发的每个阶段都获得完美的安全性只会妨碍开发人员的工作。比如安全门，我们可以先把简单的容易实现的集成到我们的CI/CD管道中，持续改进应该是DevSecOps的实践最重要的原则。

现在市场上有很多工具可以实现DevSecOps中的安全检测和控制。第一个挑战是选择合适的。第二个挑战是正确地集成它们，以便以持续的方式构建、部署和测试。将不同工具汇集到一起并在一个平台上同步不是一件容易的事情。特别把工具的报告汇总在一起管理的时候会面临很大的困难。

在我们实践过程中往往工具会扫描出大量的误报漏洞（false positives）。这些漏洞需要安全团队的分析，但是有时候这些漏洞并不能完全确定准确性。有的时候一些较严重的漏洞是否接受还是修复需要主要的SA进行审核做决策。这些会花费大量的时间。所以需要采取持续优化的过程来尽可能减少这种假阳性。安全团队建立安全知识库，对重复的假阳性漏洞进行排查。

一种根深蒂固的观点，认为安全是“以后”才会发生的事情，但是DevSecOps是要考虑安全前置，能在前期解决的问题就不会放在后面来解决。还有一种大众化的观点就是安全会阻碍创新。认为一旦实施安全控制会让一切都慢下来。实际上这也是DevSecOps的驱动力，尽量快速的使得安全内置到产品中并减少对开发流程的阻碍。

DevSecOps强调的是安全人人有责，实际上大部分的员工并没有相关的觉悟。这些都需要公司文化的引导。

Reference: