DevSecOps 企业实践白皮书.pdf

DevSecOps2020DevSecOpsDevSecOps企业实践白皮书关于安全聚合力系列独行难、众行远。安全聚合力系列报告旨在凝聚网络安全业内甲方安全专家，共同产出指导性、前瞻性的技术及行业实践研究报告，为企业提供更详实、更易落地的同行业安全建设参考。关于报告DevSecOps作为安全领域中逐渐步入成熟期的技术体系，从最初的理念到如今少量的成功实践案例，中间经历了大量的探索与发展。如今，很多企业已经意识到DevSecOps的重要性并想要有所实践，但仍然面临大量挑战。本次FreeBuf咨询邀请 研发运营一体化（DevOps）能力成熟度模型 部分编者及国内DevSecOps实践先行者携程、腾讯、国内某知名金融机构等分别从DevSecOps工具链及企业落地实践等方面深入探索研究，共同输出一份DevSecOps企业实践白皮书，为企业CSO提供安全建设的有效参考。关于 FreeBuf 咨询FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析，分享国内外安全资源与行业洞见，是网络安全从业者与爱好者广泛关注的行业社区平台。FreeBuf咨询集结了安全行业经验丰富的安全专家和分析师,依托FreeBuf 安全智库，常年对信息安全技术、行业动态保持追踪,洞悉安全行业现状和趋势,呈现最专业的研究与咨询服务。DevSecOps企业实践白皮书报告出品团队甲方专家（按姓名首字母排序）FreeBuf咨询出品人/尤文、鲍弘捷、高冰洋编者/武文婧、周雪静、张志鹏 顾问/徐钟豪行业分析师/宋丹丹设计指导/姚媛携程信息安全高级总监，15年信息安全工作经验，大学时便活跃于各类黑客论坛和黑客杂志，曾在多个技术峰会Qcon、Gitc、Xfungfoo发表主题演讲凌 云赵 锐世界500强企业中国区信息安全和风险负责人，国家网络安全周（上海）网络安全金牌讲师、DevOps标准工作组核心编写专家，CSA云安全联盟专家、CCSF优秀首席信息安全官庄 飞金融机构应用安全负责人，15年+产品研发及安全从业经历，DevOps峰会金牌讲师，DevOps标准编写专家，曾在EISS、DOIS、TiD，CIS等峰会发表主题演讲张 祖 优腾讯云产品安全负责人，腾讯安全云鼎实验室高级安全工程师，12年安全攻防经验，曾在KCon、WOT、ISF、QCon、BlackHat、网络安全创新大会、DevOps在线峰会等发表主题演讲，Seebug创始人，Pocsuite核心开发者DevSecOps企业实践白皮书CHAPTERONE第一章 2020DevSecOps国内发展现状1.1 DevOps 安全挑战及转型1.2 DevSecOps 国内发展现状0202052CHAPTERTWO第二章DevSecOps 合规趋势：研发运营一体化（DevOps）能力成熟度模型 3CHAPTERTHREE第三章企业 DevSecOps落地与指导 07080809073.1 DevSecOps 落地挑战3.2 DevSecOps 落地与指导3.2.1 安全文化变革3.2.2 安全左移流程3.2.3 构建DevSecOps工具链目 录C A T A L O GDevSecOps企业实践白皮书4CHAPTERFOUR第四章某金融机构DevSecOps 实践4.1 安全背景简介151521221414156CHAPTERSIX第六章总结与展望 5.4 企业安全工具链实践5.4.1 开源组件安全扫描(SCA)5.4.2 源代码安全扫描（SAST）5.4.3 交互式应用安全测试（IAST）5.4.4 越权检测5.4.5 数据库审计5.4.6 漏洞全生命周期管理5CHAPTERFIVE第五章携程 DevSec-Ops 实践 5.1 安全背景介绍5.2 企业安全文化建设5.3 企业安全流程建设6.1 头部行业加快实践步伐6.2 实践需贴合企业属性6.3 安全是每个人的责任262627283031252526333334264.2 企业安全文化建设4.3 企业安全流程建设4.3.1 安全策略4.3.2 安全活动及工具链应用4.3.4 企业安全平台实践4.3.5 DevSecOps安全度量指标CHAPTERONE第一章 2020DevSecOps国内发展现状第一章 2020 DevSecOps 国内发展现状安全必须要积极转型，适应DevOps全新的开发过程，在此趋势下，DevSecOps应运而生。随着技术的不断发展，软件开发模式也在不断变化。从传统的瀑布式到敏捷(Agile)、精益(Lean)，越来越多的公司开始采用DevOps。DevOps主张在软件开发生命周期的所有步骤实现自动化和监控，缩短开发周期，增加部署频率。根据中国信息通信研究院发布的 中国DevOps现状调查报告（2019年）显示，采用DevOps实践可获得研发效率的显著提升，极大提升交付速度。因为DevOps能够给企业带来的诸多益处，目前已成为企业软件研发的主流模式。1.1 DevOps 安全挑战及转型企业在向DevOps快速转型，产品交付质量和速度都在快速提升，而安全资源的缺乏以及传统安全运营模式，却阻碍了DevOps的发展。对于大部分开发团队而言，安全是比较孤立的，大部分开发和运维人员没有接受过安全编码和安全实践的培训，使得安全与开发是分割的。Gartner在2015年数据中心和信息安全峰会的调研报告显示，安全已经成为IT DevOps发展的阻碍。如下图所示，经过调研，大部分安全人员和研发人员都认为，安全降低了IT对于业务需求的响应速度。0202图：信息安全专家：安全是否阻碍 IT 速度？图：IT 运营专家：安全是否阻碍 IT 速度？DevSecOps最早由Gartner咨询公司研究员David Cearley在2012年首次提出。2016年9月，Gartner发布报告 DevSecOps:How to Seamless-ly Integrate Security into DevOps，对该模型及配套解决方案进行详细分析，核心理念为：安全是整个IT团队（包括开发、测试、运维及安全团队）所有成员的责任，需要贯穿整个业务生命周期的每一个环节。DevOps的核心价值是快速交付价值，灵活响应变化。相应的，DevSec-Ops价值是在不牺牲所需安全性的前提下，快速和规模地交付安全决策。1.2 DevSecOps 国内发展现状DevSecOps的出现是为了改变和优化之前安全工作的一些现状，比如安全测试的孤立性、滞后性、等问题，通过固化流程、加强不同人员协作，通过工具、技术手段将可以自动化、重复性的安全工作融入到研发体系内，让安全及合规作为属性嵌入到DevOps开发运营一体化中，在保证业务快速交付价值的同时实现安全内建（Build Secuirty In），降低IT安全风险。根据GitLab近期发起的第四次年度全球DevSecOps年度调查，超过25的开发人员表示对安全性完全负责，而33的安全团队成员表示他们拥有安全性。共有29的人认为每个人都应对安全负责。2020 DevSecOps企业实践白皮书可以看到，DevSecOps逐渐深入人心。虽然国内的DevSecOps落地仍然处于发展阶段，但很多国内企业已经意识到DevSecOps的重要性。随着DevOps的深度实践，工作流程越来越规范、工具和应用场景也越来越丰富。在此趋势下，国内陆续涌现出了一批专注DevSecOps的创新安全厂商，通用技术方案被越来越多的行业头部用户所采纳。此外，DevSecOps的合规和治理也在国内持续推动中，关键标志之一就是全球首个DevOps标准的发布 研发运营一体化（DevOps）能力成熟度模型。其中第六部分 安全及风险管理 对DevOps全链路中开发、交付、运营等过程的安全风险控制进行规范要求，为企业安全风险管控手段和能力提升提供有效引导，帮助企业更好的落地实践DevSecOps。CHAPTER ONE032020 DevSecOps企业实践白皮书2020 DevSecOps企业实践白皮书2CHAPTERTWO第二章DevSecOps 合规趋势：研发运营一体化（DevOps）能力成熟度模型 CHAPTER TWO052020 DevSecOps企业实践白皮书第二章 DevSecOps 合规趋势：研发运营一体化 （DevOps）能力成熟度模型DevOps 标准的雏形 互联网应用运维框架及能力模型 初稿于2015年开始编写，七位专家在编写过程中发现，仅靠运维无法解决所有问题，无法真正体现业务价值，因此开始寻求更好的方向。2017年底，为了更多的中小互联网企业以及传统企业能复用互联网、通信及金融等企业在DevOps领域积累的先进技术，中国信息通信研究院云计算开源产业联盟（OSCAR）联合高效运维社区、DevOps时代、腾讯、京东等行业顶级技术专家100多名，共同编写制定了全球首个DevOps系列标准 研发运营一体化（DevOps）能力成熟度模型。该系列标准分为敏捷开发管理、持续交付、技术运营、应用设计、安全风险管理和组织结构7个部分，涵盖了全软件的开发和运维生命周期，为构建云时代下的新型软件开发与运营模式奠定坚实的基础。2018年7月16-27日，在瑞士日内瓦举行的ITU-T*（国际电信联盟）Study Group13 Future networks(&cloud)全会上，来自中国、美国、英国、德国、几内亚、日本、韩国、俄罗斯联邦、沙特阿拉伯、泰国、塞内加尔等20多个国家的90多名代表参与了此次会议。由中国信息通信研究院主导的DevOps国际标准项目成功立项，立项名称为：“Cloud comput-如上图，信通院在 中国DevOps现状调查报告（2019年）中，曾针对企业实施安全管理的现状、添加自动化安全分析的阶段、专业安全团队的配比等方面做了调研：近7成的企业在安全与风险管理成熟度分布上仍处于初始级与基础级，仅有5.2%的企业达到了优秀级。由此也能看出大部分企业仍未给予安全管理足够的重视。随着 研发运营一体化（DevOps）能力成熟度模型 框架的逐渐完善，将对DevOps全链路中开发、交付、运营等过程的安全风险控制进行规范要求，为企业安全风险管控手段和能力提升提供有效引导，并真正助力DevOps应用的全生命周期安全管理。ing-Requirements for cloud service development and operation management”。研发运营一体化（DevOps）能力成熟度级别分成五级，分别是：1级-初始级：在组织局部范围内开始尝试DevOps活动并获得初期效果；2级-基础级：在组织较大范围内推行DevOps实践并获得局部效率提升；3级-全面级：在组织内全面推行DevOps实践并贯穿软件全生命周期获得整体效率提升；4级-优秀级：在组织内全面落地DevOps并可按需交付用户价值达到整体效率最优化；5级-卓越级：在组织内全面形成持续改进的文化并不断驱动DevOps在更大范围内取得成功。DevSecOps相关细则作为风险管理主题出现在 研发运营一体化（DevOps）能力成熟度模型 的第六章节。主要是安全考量和全局规划，包括：控制总体风险、控制开发过程风险、控制交付过程风险、控制运营过程风险。安全与风险管理成熟度分布39.41%35.87%19.52%5.20%0.00%初始级基础级全面级优秀级卓越级注释：ITU 和 ISO、IEC 并称国际三大标准化组织。ITU（国际电信联盟）是联合国的国际标准组织，成立于1865年（比联合国还早80年），是193个主权国家的政府间组织。ITU 和 国际原子能机构、国际货币基金组织和教科文组织并列，均为联合国专门机构。3CHAPTERTHREE第三章企业 DevSecOps落地与指导 CHAPTER THREE07未建立专业安全团队65.02%第三章 企业 DevSecOps 落地与指导由于DevSecOps仍然处于初始阶段，还没有一个通用化的标准或实践指南，并没有很多成熟经验可以借鉴，企业在落地之初主要遇到的挑战如下：安全人才短缺根据 中国DevOps现状调查报告（2019年），有65.02%的企业仍未建立专业安全团队。事实上，大多数企业仍处于“一个人的安全部”的现状，日常工作主要承担防火墙、安全监测、补丁管理、病毒管理等较传统的网络安全工作。近年随着安全越来越被重视，企业开始成立独立的安全团队，然而大部分仅仅是IT人员的扩张，专业的安全人员比例却在降低。3.1 DevSecOps 落地挑战图 中国 DevOps 现状调查报告（2019 年）-专业安全团队比例低由于DevSecOps需要安全左移，安全需要和研发更紧密的协作。而安全人才市场面临着极大的缺口，缺乏专业的安全人员，便可能导致和研发沟通不畅，因而影响安全和DevOps嵌入的效率。文化的挑战安全通常是作为独立组织存在，且与研发和运营分开。此外，在IT人员的概念中，安全往往会增加IT人员额外的工作量，拖累项目的进度甚至延期，因而IT人员与安全往往站在对立面。同时研发人员和运营人员大都不懂安全。由此造成的文化与意识壁垒，一时间很难打破。安全知识和技能薄弱DevSecOps需要研发、运维及安全人员协作，共同承担安全职责，可站在对方的视角看待问题。但是对于研发和运维人员来说，往往缺少安全意识及技能，在系统设计开发及部署运维等环节，无法高效协同保障安全性。安全与研发流程割裂安全测试工具有很多种类，如源代码安全扫描、黑盒安全测试、开源组件安全测试、主机安全测试等。这些安全测试工具通常为独立的工具及单独的Web页面，需要研发人员分别登录查看漏洞及修复，部分测试工具的扫描时间可能还会长达小时级。由于安全与研发流程的割裂，便会影响DevOps的快速迭代。专业安全团队比例已建立专业安全团队34.98%CHAPTER THREE072020 DevSecOps企业实践白皮书3.2 DevSecOps 落地与指导伴随着DevSecOps战略框架的日趋完善，国内相关行业的建设也迅速开展起来。总体来说，基于Gartner DevSecOps理念，企业需要从文化、流程及技术三方面切入，通过固化流程、加强人员协作以及工具化、自动化技术手段将安全无缝内嵌到研发流程中，从而实现企业DevSecOps落地。DevSecOps实质上是对传统IT文化的变革，因此落地的推动往往需要获取上层支持，通过意识宣贯及安全培训等手段，改变只有安全人员对安全负责的态度和观念，让研发团队及运维团队到每个人都需要对安全负责。好的DevSecOps文化能够支持更严格的安全策略的贯彻执行。在有着优良企业安全文化的团队中，安全自然成为了一种共同的责任，在这种文化之下，不同业务部门间的鸿沟会相对更为容易跨越，在问题出现的时候，也会得到最早地解决。3.2.1 安全文化变革Gartner给出建议，不要强制DevOps开发人员采用安全人员的旧的流程。相反地，将安全保证措施无缝集成到开发的持续集成（CI）和持续部署（CD）的工具链中。详细来讲，针对安全工作的阶段左移，需要在软件开发的初期就介入进来。从安全需求定义、威胁建模、安全扫描、安全黑盒测试等多个方面进行安全能力内建，如安全需求导入至统一需求管理流程与工具、安全测试工具集成到CI持续集成和CD持续部署、安全漏洞结果导入到缺陷管理工具等，由此顺利衔接安全与研发相关工具及流程。3.2.2 安全左移流程图 安全建设安全活动干系人082020 DevSecOps企业实践白皮书图 DevSecOps 工具链企业从关注安全到实现落地，需要切实地进行投入，包括开发、测试、运营过程中的流程规范、实践，在此过程中，离不开各项工具平台的建设。将流程和工具完美结合，通过将安全能力内建到工具中，也是DevSecOps 落地中关键的一环。在DevSecOps理念的发展过程中，一直是在不断演变且逐渐成熟，但不同阶段的理论成熟度与实践也存在较大的差异化。在本报告中我们尝试基于Gartner输出的DevSecOps工具链对其不同阶段进行解读。DevSecOps主要分为10个阶段，分别是计划（Plan）、创建（Create）、验证（Verify）、预发布（Preprod）、发布（Release）、预防（Prevent）、检测（Detect）、响应（Respond）、预测（Predict）、适应（Adapt），其中预防（Prevent）在之前的版本里也有叫做配置（Configure）。计划阶段是DevSecOps的第一个阶段，其包含了SDL模型里培训、需求、设计等几个阶段，主要关注的是开发前的安全动作。根据Gartner官方工具链模型可以看出其主要是包含有偿还技术安全债务、安全开发衡量指标、威胁建模、安全工具培训。技术债务指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。那么对应的技术安全债务就是相关技术架构中一些考虑不完善的点而潜藏的安全风险，一般就是在安全设计或者需求阶段没有进行相关的安全设计和评估而导致，在后续的安全工作里都是需要认识其风险并且给出安全解决方案逐渐偿还。举个例子，比如在一些项目的开发过程中为了快速实现功能，选用了一些不安全的框架，那么在后续的维护过程中可能会不断受其安全问题影响而需要不断的进行修复，比如说struts2，那么安全团队应该给出方案，比如说禁用替换该组件。安全开发衡量指标为需要制定对应的安全开发的衡量指标，以便于评估安全开发模型实施的效果，比如漏洞发现率，统计上线前后漏洞的发现情况，来评估安全开发流程是否有效在安全开发过程中有效收敛安全漏洞。威胁建模是在需求和设计阶段识别和消减安全威胁的一种手段，如SDL里微软提出的“STRIDE”，基于数据流图去识别不同环节是否存在仿冒、篡改、抵赖、信息泄露、拒绝服务、权限提升几个维度的安全威胁，并制定对应的消减措施，落实并验证。这里还有个概念是轻量的威胁建模，相对比“STRIDE”这种传统意义上比较复杂的威胁建模过程，轻量的威胁建模通常通过安全checklist等方式进行简单快速的实现设计、需求阶段的安全风险识别并处3.2.3 构建DevSecOps工具链3.2.3.1 Plan 计划阶段CHAPTER THREE092020 DevSecOps企业实践白皮书置，一般也容易落地与实行，并且也能取得一定的效果，而不至于让这个安全动作名存实亡。安全工具培训则就是字面的意思，由于DevSecOps相对比SDL等更强调自动化，所以相关安全动作通常由安全工具实现，同时安全动作不再只是安全团队执行，所以也要针对开发等同学进行安全工具使用的培训，以便于帮助其在不同阶段使用安全工具进行检查。当然，除了DevSecOps工具链所标记的四点，其实在计划阶段，类似安全编码规范、安全编码培训、安全流程的学习、安全需求定义、制定和发布标准化安全功能等需求、设计阶段实际安全动作都可以归入这个阶段，并不存在明显的冲突或者矛盾。3.2.3.2 Create 创建阶段创建阶段主要就是指编码阶段。编码阶段主要进行安全编码及检查，旨在在编码阶段进行安全风险的消除。主要包含参考安全编码规范进行安全编码，通过IDE安全插件进行源代码的安全检测，也可以进行安全编码规范的自动化检查，如是否使用不安全或禁用的函数等；甚至是检查代码中是否引用使用了不安全或不合规的第三方组件。3.2.3.3 Verify 验证阶段验 证 阶 段 其 实 就 是 测 试 阶 段，主 要 以 自 动 化 的 应 用 安 全 测 试（AST，Application Security Testing）和 软 件 成 分 分 析（SCA，Software Composition Analysis）为主。应用安全测试主要分为动态应用安全测试（DAST）、静态应用安全测试（SAST）、交互式应用安全测试（IAST,）。DAST 是一种黑盒测试方式，是在应用测试或运行环境模拟黑客构造特定的恶意请求从而分析确认应用是否存在安全漏洞的一种方式，也是过去最常用的一种应用测试方式，比如我们常见的 APPSCAN、AWVS、W3AF 等 Web 漏洞扫描器就是属于这种类型；而 SAST 是针对源代码的一种分析测试方式（部分工具也会依赖于编译过程甚至编译后文件进行分析测试），常见的 Coverity、Checkmarx、CodeQL 等自动化静态代码审计工具就属于这个类型；而 IAST 是Gartner 在 2012 年提出的一种应用安全测试方式，寻求结合 DAST 和 SAST 的优势，其实现原理通常通过插桩的方式在应用环境安装 Agent，在特定位置插入探针，然后通过测试用例执行触发请求，探测获取请求、代码数据流、控制流等，然后进行综合的判断分析是否存在漏洞。相对比DAST 和 SAST，IAST 既能识别漏洞所在代码位置，又能记录触发漏洞的请求。相对比其他两类应用安全测试，IAST 的一些现有成熟工具会比较少，但国内外也开始涌现相关厂商在输出这块的工具。软件成分分析主要是关注应用中引入使用的第三方组件的情况。根据 Gartner 和 Synopsys 调研报告显示，99%的组件在企业 IT 系统以及 99%的软件中使用第三方组件，而 Synopsys 2020 年开源安全报告更是指出 75%的开源代码存在漏洞，49%包含高风险漏洞，所以第三方组件安全问题成为影响软件安全问题的核心点之一。SCA 通过分析软件成分，识别软件中使用的第三方组件是否存在安全问题或者合规风险，以此消除第三方组件带来的安全风险。该类工具主要有 OWASP Dependency Check、BlackDuck Hub、FOSSID 等。3.2.3.4 Preproduction 预发布阶段预发布阶段一般是测试阶段及正式发布阶段的中间阶段，其与测试阶段不同的是预发布阶段所发布的预发布环境是连接的正式环境的数据库等，其等同于独立部署的非对外公开的正式环境。在DevSecOps工具链中预发布阶段主要包含有混沌工程（Chaos Engineering）、模糊测试（Fuzzing）、集成测试三个安全动作。混沌工程，是一种提高技术架构弹性能力的复杂技术手段，以实验发现系统性弱点，简单的解释就是通过主动制造故障，测试系统在各种压力下的行为，识别并修复故障问题，避免造成严重后果。模糊测试是将自动或半自动生成的随机数据输入到一个程序中，并监视程序异常，如崩溃，断言（assertion）失败，以发现可能的程序错误，比如内存泄漏等。跟SAST、DAST、IAST等不同的是，AST是基于已知经验发现安全问题，模糊测试捕捉的是未知的安全问题。102020 DevSecOps企业实践白皮书CHAPTER THREE113.2.3.5 Release 发布阶段集成测试是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。其中混沌工程和集成测试都是软件及测试工程中一些专用的动作，这里映射到安全动作的话更多是通过这些工程方法实现一些安全测试的目的。同时在预发布阶段，除了以上三种动作，其实类似主机安全测试、容器镜像检查等都可以是在预发布执行的安全动作。在实际执行和落地过程，通常也会有一些安全动作比较难以清晰的划分是在验证或者预发布阶段进行，两个阶段在一些特殊场景下可能会出现互相融合的情况。针对发布阶段，在DevSecOps的流程中主要动作是软件签名，与预防阶段结合来看，主要是软件防篡改。3.2.3.6 Prevent 预防阶段预防阶段在过去版本的DevSecOps模型中也被叫为配置（Configure）阶段，在最新的模型中被调整为预防（Prevent），从调整也可以看得出，该阶段理论和实践性还有待进一步发展和细化。该阶段主要包含有签名验证、完整性检查和纵深防御。其中签名验证是呼应发布阶段的软件签名，以及进行完整性检查，两者都是保障软件的一致性，避免传输等过程软件被篡改、替换等情况。而纵深防御（Defence-in-Depth,DiD）其核心思想简单来说就是层层防御。采用分层的机制，通过层层的安全防护和监控手段而非指望单一的安全手段来建立安全防御体系，纵深防御的目标是确保每层都知道如何在可疑的攻击事件中采取行动，限制恶意或意外破坏的机会，并最大限度地提高快速识别任何安全漏洞的机会。3.2.3.7 Detect 检测阶段从预防阶段，就已经从开发切换到运维阶段，而检测阶段则更符合传统安全中相关的安全监控动作，该阶段主要包含有RASP、UEBA、网络流量监控、渗透测试几个安全动作。RASP(Runtime Application Self-Protection，应用运行时自我保护)，Gartner在2014年引入RASP这个概念。RSAP将自身注入到应用程序中，与应用程序融为一体，实时监测、阻断攻击，使程序自身拥有自保护的能力。RASP的注入方式类似于某些IAST，但其更强调的是安全防护和阻断能力，国内比较出名的有百度的OpenRASP。UEBA（User and Entity Behavior Analytics，用户行为分析）其也是Gartner提出并的一个安全名称，说白了就是通过行为分析来识别恶意行为，一般在讲述这个概念的时候会提及用户画像、机器学习等自动化学习、分析和预测能力。网络流量监控其实是类似于UEBA的一个东西，其核心是通过对流量进行监控分析，识别其中恶意的流程，即一些攻击行为等。而渗透测试通常就是指通过人工等方式进行软件或者系统的测试仪发现攻击者可以利用的攻击途径或者安全问题。引申的话其实还涉及到红蓝对抗，在渗透测试的基础上更强调攻击方与防御方的对抗过程，以此验证整体安全防御体系及相应机制等。其实除了以上4个安全动作，在运维阶段可以进行的安全检测或者监控远不止如此，过去在安全落地过程通常通过相关安全监控来进行补偿性的安全问题发现，一般就是位于该阶段，如高危端口开放检测、系统漏洞扫描等。2020 DevSecOps企业实践白皮书3.2.3.8 Respond 响应阶段而渗透测试通常就是指通过人工等方式进行软件或者系统的测试仪发现攻击者可以利用的攻击途径或者安全问题。引申的话其实还涉及到红蓝对抗，在渗透测试的基础上更强调攻击方与防御方的对抗过程，以此验证整体安全防御体系及相应机制等。其实除了以上4个安全动作，在运维阶段可以进行的安全检测或者监控远不止如此，过去在安全落地过程通常通过相关安全监控来进行补偿性的安全问题发现，一般就是位于该阶段，如高危端口开放检测、系统漏洞扫描等。在DevSecOps的响应阶段，安全动作主要包含有安全编排、基于RASP/WAF的防护、以及混淆。基于RASP/WAF安全防护是指通过WAF或RASP的方式，针对 Web 攻击进行拦截阻断，以实现避免由于Web 攻击导致的拖库等后果。而混淆主要是指代码混淆，更多是针对移动APP的混淆操作，避免APP反编译等。安全编排一般是指安全编码自动化和响应(SOAR)，也是Gartner在2017年提出的概念，它是安全编排与自动化（SOA，Security Orchestration and Automation）、安全事件响应平台（SIRP，Security Incident Response Platform）和威胁情报平台（TIP，Threat Intelligence Platform）三种技术/工具的融合，目的是快速准确的响应和预测安全事件。3.2.3.9 Predict 预测阶段3.2.3.10 Adapt 适应阶段预测阶段主要涉及漏洞相关性分析与威胁情报（开发消耗（Dev Consumable）是新版本的 DevSecOps 工具链中新引入的点，概念与含义还不够清晰）。漏洞相关性分析（Application Vulnerability Correlation，AVC）也是 Gartner 提的一个概念，是一种应用程序安全性工作流和流程管理工具，旨在通过将来自各种安全测试发现的不同数据源的漏洞进行统一管理和自动关联，从而简化漏洞的修复。通俗的解释，由于存在不同类型的应用安全测试工具，如上文的 SAST、DAST、IAST 等，那么不同工具的使用会产生不同标准和格式的漏洞结果，会存在重复扫出同一个漏洞等情况，漏洞相关性分析通过自动分析和关联合并漏洞，这样开发人员就可以更便捷和快速的修复安全问题，提升安全效率。威胁情报（Threat Intelligence，TI），根据 Gartner 对威胁情报的定义，威胁情报是某种基于证据的知识，包括上下文、机制、标示、含义和能够执行的建议，这些知识与资产所面临已有的或酝酿中的威胁或危害相关，可用于资产相关主体对威胁或危害的响应或处理决策提供信息支持。业内大多数所说的威胁情报可以认为是狭义的威胁情报，其主要内容为用于识别和检测威胁的失陷标识，如文件 HASH，IP，域名，程序运行路径，注册表项等，以及相关的归属标签。威胁情报旨在为面临威胁的资产主体(通常为资产所属企业或机构)提供全面的、准确的、与其相关的、并且能够执行和决策的知识和信息。其中 IOC（Indicators of Compromise）叫做入侵威胁指标，是威胁情报的关键信息，通常是如恶意文件指纹、进程信息、恶意域名、C&C 服务器 IP 等。由于威胁情报可能有不同的来源，那么意味着其有不同的结构和标准，为了统一威胁情报表达和交换标准，方便进行不同来源威胁情报的使用，就诞生了对应的威胁情报标准，其中结构化威胁信息表达式（StructuredThreatInformationeXpression，STIX）和指标信息的可信自动化交换（TrustedAutomatedeXchangeofIndicatorInformation，TAXII）就是其中的核心的两个标准。前者提供了基于标准 XML 语法描述威胁情报的细节和威胁内容的方法，后者则定义了威胁情报的交换协议。所以通常使用 STIX 来描述情报，而使用 TAXII 来传输交换情报。适应阶段主要强调了安全技术债务、修改应急响应方案、安全防御方案等几个点。其实这个阶段也可以称作优化阶段，主要是基于DevSecOps实施的整个流程的情况，进行持续的适配改进和项目调整优化，对应到过去安全动作，可以理解为持续运营反馈调整的过程，包含对相关安全问题的持续跟踪、闭环，对DevSecOps过程中相关安全动作如策略的调整等。在此，我们分别国内某知名金融机构和国内在线旅游行业龙头企业携程的企业DevSecOps落地为例，串联文化、流程及技术三要素，给出具有行业及企业特色的实践参考。122020 DevSecOps企业实践白皮书4CHAPTERFOUR第四章某金融机构DevSecOps 实践 高层支持：借助监管要求、外部咨询、安全案例等形式，强化应用系统生命周期安全管理的必要性，争取高层的认同与支持，获得更多的人力及预算等资源。软件安全方法论：确立了自有软件安全开发生命周期管理框架，规定在软件安全开发的不同阶段需要开展的安全活动。安全活动干系人：明确项目安全建设过程中涉及的干系人的主要活动、职责和义务，让研发及运维人员意识到安全是整个IT团队每个人的责任，需要贯穿从开发到运营整个软件生命周期的每一个环节。安全培训：开展了一系列线上线下信息安全技能培训，提升IT人员安全专业技能。并且基于不同的角色，定制了不同的培训课程。安全积极分子：在内部信息安全门户建立了漏洞修复知识库，鼓励安全积极分子将日常漏洞修复过程分享出来，共同维护该漏洞修复知识库。以史为鉴：通过收集和总结历史上发生的真实漏洞案例，形成“漏洞-以史为鉴”，用实际发生的安全案例对研发及运维人员进行安全宣贯。该金融机构安全部门下设应用安全、数据安全、安全技术攻防、安全事件响应相关职能团队，覆盖应用安全、GRC(治理、风险和合规)、数据安全、业务安全、安全运营、安全攻防及安全响应等分支。其中，应用安全团队负责DevSecOps的研究与落地，应用安全职能专设安全顾问“ISO”的角色，扎口管理项目安全评估与咨询，负责项目安全建设的全流程跟踪。此外，为了解决安全方向较多而安全人力不足的问题，机构跨团队成立了六大虚拟组织“大运营体系”，采用融合SCRUM敏捷方法的安全大运营模式，提升安全人力协作和运营效能。2017年开始，该机构已全面向敏捷及DevOps转型，DevOps平台也在同步自研中，目前已经具备较完善的功能，大量的项目在逐步迁移到DevOps平台。作为国内较早实施DevSecOps实践的金融企业，具备丰富的安全管理及建设经验。4.1 安全背景简介图 某金融机构 DevOps 数字化转型4.2 企业安全文化建设142020 DevSecOps企业实践白皮书图 研发运营一体化过程中安全活动4.3 企业安全流程建设安全团队和质量团队合作，对应用系统进行分类分级，针对不同的系统分类分级，定义不同的安全策略，将安全活动内嵌到项目流程中。包括安全调查问卷、轻量级威胁建模、源代码安全扫描、开源组件安全扫描、黑盒安全测试、内外部渗透测试、生产环境部署验证、剩余风险评级与接受等。4.3.1 安全策略在DevOps研发运营一体化过程中进行的安全活动如下图，选取一些主要活动进行说明。4.3.2 安全活动及工具链应用4.3.2.1 轻量级威胁建模安全团队对威胁建模过程进行了优化，将安全需求分析和架构设计过程结合，设计了轻量级威胁建模，主要包括攻击面分析和安全威胁库。Step 1-问卷调研：调研问卷主要包括系统架构、使用场景、重要数据、部署方式 4部分。其中系统架构关注统架构图、技术实现方案等，使用场景关注用户场景、用户群体、角色、访问方式等，数据关注是否有敏感数据，而部署关注部署架构及物理资产。Step 2-攻击面分析：采用简化的数据流图，关注系统与外部系统的边界。Step 3-威胁识别：将识别出的攻击面，基于业务场景与威胁库进行匹配，识别出系统面临的威胁点。Step 4-安全设计方案：根据威胁分析结果，匹配安全需求标准库，输出进行威胁缓释需要实施的安全需求基线，制定最终的安全设计方案。CHAPTER FOUR152020 DevSecOps企业实践白皮书当前机构的轻量级威胁建模仍然处于手工阶段，为了提供效率，安全团队已经在SDL安全开发全流程赋能平台中，进行自动化轻量级威胁建模功能开发。图 SonarQube 集成 Find Security Bugs 插件4.3.2.2 源代码安全扫描（SAST）源代码安全扫描在 DevOps 过程中的检测点主要有：开发人员本地源代码安全检测、代码提交时进行源代码安全检测、CI 构建过程中进行源代码安全扫描。针对 SAST，安全团队最初采用了商业工具 Fortify 及 Appscan Source。但在实际应用中存在两个问题：误报太多及扫描速度太慢，这些因素都会拖累 DevOps 交付速度。基于软件开发成熟度现状，为了更好的集成到 DevOps 流程，安全团队放弃商用工具，转而使用开源 SonarQube+Find Security Bugs 插件取代。2020 DevSecOps企业实践白皮书图 轻量级威胁建模164.3.2.3 黑盒安全测试（DAST）安全团队目前采用的黑盒安全测试工具有 AppScan、AWVS、OWASP ZAP 和 Arachni，通过自研三叉戟自动化安全测试平台进行封装和分布式扫描调度，提供 API 方式给 DevOps 平台进行集成。不过由于研发测试环境没有统一的测试 Token，无法有效进行登录式扫描，因此也在探索基于流量代理或镜像方式的黑盒安全测试技术。4.3.2.4 交互式应用安全测试(IAST)IAST可在软件集成测试阶段无缝集成到DevOps，测试人员在执行功能测试的同时，无感知的完成应用安全测试。对此，引入了IAST工具Contrast Security，集成至DevOps平台中进行自动化安全测试。4.3.2.5 开源组件安全扫描(SCA)针对开源组件的安全治理实践如下：-引入开源组件的安全扫描工具：引入商业的BlackDuck，支持安全风险及许可证合规检测。-自动