Author：DevSecOps联盟 0XFE1FE1

01 金融行业安全面临的挑战

随着互联网技术与金融行业结合越发紧密，互联网金融已经是金融行业发展的热点，技术创新扮演着越来越重要的角色，越来越多的系统通过互联网为客户提供服务。金融科技的出现频率正在高速增长，伴随其技术变革与创新加速。但随着金融科技日渐成为金融产品的重要支撑手段，攻击者也在不断丰富其攻击目标和攻击手段，以图提升自身的攻击变现能力。众所周知，金融行业是我国网络安全重点行业之一，因其行业特殊性金融机构一直是网络犯罪的主要目标。

图1 金融行业安全面临的挑战

合规。金融行业是牌照行业，接受严格的监管，典型特征是各项业务开展以及IT发展，必须遵守各项管理规定，合规是金融企业的底线和最低要求。除了国家法律法规层面，证券经营机构还需要接受人行、证监会、中证协等的监管。随着《网络安全法》的正式施行，国家对公民个人信息的保护法律要求和监管层对保护投资者个人信息等权益的重视，已经达到了新的高度，这在等级保护2.0、国标《个人信息安全规范》等法规上都有所体现。

图2 金融行业网络安全制度示例

内外部威胁。金融行业面临着境外黑客组织的带有特定目的的攻击或高级持续威胁（APT）。为了提高效率、扩大攻击面，攻击者也开始针对性地利用行业软件与供应链安全等影响面广的问题或漏洞，实施犯罪，甚至网络攻击与电信诈骗配合，黑色产业链配合。内、外部威胁变化快，从过去试图炫耀技能的小黑客已发展成全产业链的黑色产业，以高效盈利为目的，以入侵系统或者利用系统缺陷获取公民个人信息或其他金融信息为主要场景。

Freebuf《2019年金融行业网络安全报告》数据显示，2019年金融行业漏洞势头有增无减，呈上升势头。敏感信息泄露上升至最为热门的漏洞，近年来用户数据泄露事件更是频发，对于数据安全提出了更高的要求。

图3 金融行业热门漏洞TOP 10

证券行业拥有海量的用户数据，是国内金融中最活跃的市场，安全建设同样不容忽视。

图4 证券行业漏洞TOP N

IT成熟度相对低。根据《证券经营机构信息系统生命周期安全管理现状调研报告2017》（机构、兴业证券及上交所联合课题组）对部分经营机构调研显示，56%的证券经营机构，自研比例在10%以下。自有IT研发人员少，依靠大量外购或驻场外包人员，IT软件成熟度较低。从攻击面资产管理还大量依靠文本工具管理方式，也可以看出安全成熟度更低。

图5 证券经营机构IT系统中自研系统（自行开发或合作开发）比例

图6 证券经营机构攻击面资产管理方式

安全人才缺乏。从证券经营机构安全管理来看，大多数证券公司，专职安全人员只有1-3人，多数在系统运行管理条线下开展安全工作，其工作与系统运行结合的较为紧密，日常工作主要承担防火墙、安全检测、补丁管理、病毒管理等较为传统的网络安全工作，经常会出现“一个人的安全部”。近年随着安全越来越得到重视，经营机构开始成立独立的安全团队，但随着IT技术部门人员的扩张，安全团队人员占比却持续降低。

图7 《中国DevOps现状调查报告（2019年）》专业安全团队比例低

图8 证券经营机构安全与IT人员占比(2017)

02 DevOps转型及遇到的挑战

随着技术的不断发展，软件开发模式也在不断变化，从传统的瀑布式到敏捷(Agile)、精益(Lean)，目前越来越多公司开始采用DevOps。中国信通院（CAICT）发布的《中国DevOps现状调查报告（2019年）》显示，采用DevOps实践获得了研发效率的显著提升，极大提升了交付速度。因为DevOps能够给企业带来的诸多益处，目前DevOps已经成为企业软件研发的主流，被众多企业所采用。

机构从2017年开始全面向敏捷及DevOps转型，DevOps平台也在同步自研中，目前已经具备较完善的功能，大量的项目在逐步迁移到DevOps平台。

图9 机构DevOps数字化转型

但是， DevOps的转型使得软件开发的速度与质量都在快速提升，传统的安全运营模式（上线前安全扫描，人工渗透等），已经严重影响到产品交付的速度，延长了系统上线周期，最终在业务的压力下，很多应用未进行安全测试或“带病”就上线，带来了极大的安全风险。

Gartner在2015年数据中心和信息安全峰会的调研报告显示，安全已经成为IT DevOps发展的阻碍。如图9和图10所示，经过调研，安全人员和研发人员都认为，安全降低了IT对于业务需求的响应速度。

图10 信息安全专家：安全是否阻碍IT速度？

图11 IT运营专家：安全是否阻碍IT速度？

企业在向DevOps快速转型，产品交付质量和速度都在快速提升，而安全资源的缺乏以及传统安全运营模式，都阻碍了DevOps的发展，因此，安全必须要积极转型，适应DevOps全新的开发过程。在此趋势下，DevSecOps应运而生，DevSecOps的出现是为了改变和优化之前安全工作的一些现状，比如安全测试的孤立性、滞后性、等问题，通过固化流程、加强不同人员协作，通过工具、技术手段将可以自动化、重复性的安全工作融入到研发体系内，让安全及合规作为属性嵌入到DevOps开发运营一体化中，在保证业务快速交付价值的同时实现安全内建（Build Security In），降低IT安全风险。

03 DevSecOps落地实践

3.1 DevSecOps 理念

在2017 RSA大会中，专门为“DevSecOps”设置了议题和讨论会，“DevSecOps”逐渐被大家所关注。

图12 DevSecOps@RSA Conference 2017

DecSecOps机构总监Shannon Lietz在DecSecOps专题研讨会上分享了《Next Gen Security Needs You》，详细解释了DevSecOps的概念：DevSecOps是一种实践，通过在创造性过程中引入所有需要的干系人更快速地开发更安全的软件，并且通过真实可靠、可落地的反馈来进行持续改进。

DevSecOps，一种全新的安全理念与模式，从DevOps的概念延伸和演变而来，其核心理念为安全是整个IT团队（包括开发、运维及安全团队）每个人的责任，需要贯穿从开发到运营整个业务生命周期的每一个环节。

图13 DevSecOps模型

DevOps的核心价值是快速交付价值，灵活响应变化。相应的，DevSecOps价值是在不牺牲所需安全性的前提下，快速和规模地交付安全决策。

从RSAC 2017到RSAC 2020， DevSecOps实践在不断的进化，越来越多的方法论进入大众的视角，如”Shift Left” 安全左移、”Golden Pipeline”黄金管道、安全专家Larry Maccherone的DevSecOps宣言及9个关键实践点等，这些都有助于企业快速落地DevSecOps实践。

图14 DevSecOps RSAC演进

Gartner在一篇分析报告中，提出了DevSecOps模型中应用安全活动一些参考。

图15 DevSecOps 应用安全活动参考

Gartner建议，DevSecOps中安全活动聚焦到4个领域：安全设计、开发验证、外部安全及生产安全监控。

1）安全设计：非常强调过程和“内建安全性”。安全需求的收集和执行、威胁建模、安全编码实践以及提倡使用可信的外部组件。

2）开发验证：重点验证是否遵循安全编码实践、安全需求是否满足以及应用程序没有弱点或漏洞。使用软件组成分析（SCA）和应用程序安全测试（AST）等工具进行验证。

3）外部安全：重点关注离开代码库后，在生产或运行时确保应用程序安全。各种各样的技术开始发挥作用，包括Web应用防火墙（WAF）、运行时应用自我保护（RASP）、API网关、机器人缓解和应用加固。同时还包括工作负载规范的安全机制，例如通过持续配置自动化来确保服务器构建加固。

4）生产安全监控：在本地网络或CSP内，持续发现和监控应用程序和系统。这同样也是安全操作中心（SOC）、漏洞评估和漏洞管理的领域。

3.2 落地DevSecOps困难点

机构从2016年就建立了完整的软件安全开发生命周期SDL体系建设，并于2017年进行DevSecOps研究和实践落地。由于DevSecOps仍然处于初始阶段，还没有一个通用化的标准或实践指南，并没有很多成熟经验可以借鉴，在落地之初主要遇到的困难如下。

第一：安全人才短缺。由于DevSecOps需要安全左移，安全需要和研发更紧密的协作。比如安全需求及安全架构设计、安全编码规范、源代码审计等，这些都需要安全人员既懂安全，也要懂研发和架构，而这类安全人才市场也短缺，缺乏安全专业技能人才，到导致和研发沟通不畅，影响安全和DevOps嵌入的效率。解决方法一方面从市场上招聘具备此类技能的安全人员，一方面对安全人员进行培养。

第二：文化的挑战。安全通常是作为独立组织存在，且与研发和运营分开，潜在的就有“一堵墙”。对传统开发和运营模式来说，DevSecOps实质上改变了IT的观念，在IT人员概念中，安全都是安全团队的事，安全都是“背锅侠”。安全往往会增加IT人员额外的工作量（这些工作量他们认为对业务没有价值），拖累项目的进度甚至延期，因而IT人员与安全往往站在对立面。而研发人员和运营人员大都不懂安全。由此造成的理念与意识壁垒，一时间很难打破。实践的推动需要获取上层支持，通过意识宣贯及安全培训等手段，改变只有安全人员对安全负责的态度和观念，让研发团队及运维团队到每个人都需要对安全负责。

第三：安全知识和技能薄弱。DevSecOps需要研发、运维及安全人员协作，一起对安全负责，可以站在对方的视角看待问题。对于研发和运维人员来说，缺少安全意识及技能，在系统设计开发及部署运维等环节，不了解如何保证其安全性。所以需要通过安全培训等方式提升研发及运维人员技能。

第四：安全与研发流程割裂。安全测试工具有很多种类，如源代码安全扫描、黑盒安全测试、开源组件安全测试、主机安全测试等，而这些安全测试工具都是独立的工具，及单独的web页面，需要研发人员分别登录查看漏洞及修复。而如源代码安全扫描工具，有些扫描时间长达小时级，对于CI来说也无法接受。为了实现DevOps的快速迭代，需要将安全测试工具及流程无缝嵌入到研发人员工具及流程(build security in)，如安全需求导入至统一需求管理流程与工具，安全测试工具集成到Ci持续集成和CD持续部署，安全漏洞结果导入到缺陷管理工具等。

3.3 机构DevSecOps落地实践

机构基于Gartner DevSecOps理念，从文化、流程及技术三方面探索、实践并落地了DevSecOps，通过固化流程、加强人员协作以及工具化、自动化技术手段将安全无缝内嵌到研发流程中。

图16 DevSecOps 成功关键要素

3.3.1 人（People）

组织架构。首先要培养自己的安全队伍，建设自身的专业安全能力。机构2015年成立安全团队，从最初的5人，现在已经发展到近20人，形成了信息安全中心。下设工程效率与应用安全、操作风险与数据安全、安全技术运营与攻防及安全威胁与事件响应职能团队。各个团队负责不同的职能方向，覆盖应用安全、GRC(治理、风险和合规)、数据安全、业务安全、安全运营、安全攻防及安全响应等分支。工程效率与应用安全团队负责DevSecOps的研究与落地。应用安全职能专门设置了安全顾问“ISO”角色，扎口项目安全评估与咨询，负责项目安全建设的全流程跟踪。

图17 安全组织架构

大运营体系。安全分支方向很多，而安全人力远远不足，因此，跨团队成立了六大虚拟组织“大运营体系”，采用融合SCRUM敏捷方法的安全大运营模式，提升安全人力协作和运营效能。

3.3.2 文化（Culture）

高层支持。首先要争取高层的认同和支持。借助监管要求、外部咨询、安全案例等形式，积极和高层沟通，强化应用系统生命周期安全管理的必要性，争取高层的认同与支持，这样才能获得更多的人力及预算等资源。

软件安全方法论。确立软件安全开发生命周期管理方法论。2016年通过借鉴业界成熟的安全生命周期管理方法论（如微软SDL、BSIMM、OWASP OpenSAMM及NIST SP800-64），以及国内外成熟可靠的标准、方法和实践，同时结合企业信息系统的开发和运维现状，形成了一套信息系统生命周期安全管理的框架，该框架规定了在软件安全开发的不同阶段需要开展的安全活动，且该框架各个活动模块是灵活可裁剪的，根据IT成熟度决定采取的安全活动。

图18信息系统生命周期安全管理BSI框架

安全活动干系人 。通过安全宣贯、BSI白皮书、安全顾问项目安全评估沟通等形式，对研发及运维人员进行软件生命周期安全开发实践的推广，并明确项目安全建设过程中涉及的干系人的主要活动、职责和义务，让研发及运维人员意识到安全是整个IT团队每个人的责任，需要贯穿从开发到运营整个软件生命周期的每一个环节。

图19 项目安全建设安全活动干系人

安全培训。同时，开展一系列的信息安全技能培训，提升IT人员安全专业技能。并且基于不同的角色，定制了不同的培训课程。

图20 安全培训

除了线下活动，在网络培训学院及信息安全门户，提供安全培训视频、安全技术指南、漏洞知识库、最佳实践等，IT人员可以自主进行安全知识学习，提升自身的安全技能，在软件研发和运营过程中，有意识的融入安全要素，主动降低安全风险。

图21 安全技术文档

安全积极分子。同时，通过对安全感兴趣的开发人员进行安全培训，培养安全积极分子（security champion），通过其潜移默化带动其他开发人员的安全意识，将安全要素融入日常的开发过程中，同时也可以解决安全人员不足的问题。在内部信息安全门户建立了漏洞修复知识库，鼓励开发人员将日常漏洞修复过程分享出来，共同维护该漏洞修复知识库，其他开发人员修复漏洞时，由于技术栈类似，可以参考知识库进行快速修复，降低修复成本。

以史为鉴。通过收集和总结机构历史上发生的真实漏洞案例，形成“漏洞-以史为鉴”，用实际发生的安全案例对研发及运维人员进行安全宣贯，可以引起其共鸣，达到更好的安全意识宣贯的效果，另一方面，共性的漏洞问题也反馈给研发，从架构等层面进行优化，从根源上解决此类安全问题。

图22 漏洞-以史为鉴

3.3.3 流程（Process）

Gartner给出建议，不要强制DevOps开发人员采用安全人员的旧的流程，相反地，计划把持续的安全保证措施无缝地集成到开发的持续集成（CI）和持续部署（CD）的工具链中。

安全策略。安全团队和质量团队合作，对应用系统进行分类分级，针对不同的系统分类分级，定义不同的安全策略，将安全活动内嵌到项目流程中。

系统分类分级维度有研发模式（自研、合作开发、外购等）、网络模式（面向互联网、面向办公网、核心网等）、用户场景（机构、客户、员工等）等。安全策略定义了在项目建设过程中，需要进行的安全活动，主要有安全调查问卷、轻量级威胁建模、源代码安全扫描、开源组件安全扫描、黑盒安全测试、内外部渗透测试、生产环境部署验证、剩余风险评级与接受等。

图23 项目过程安全策略

通过在项目过程定义中加入安全策略，可以督促开发人员在研发过程中主动进行安全活动，潜移默化提升其安全意识。

安全活动。机构在DevOps研发运营一体化过程中进行的安全活动如下图，选取一些主要活动进行说明。

图24 研发运营一体化过程中安全活动

1）安全需求标准库。

安全需求标准库，以等保2.0为基础框架，汇总各种安全需求而形成的安全通用需求库，主要需求来源有：

l 国家法律法规及标准，如《网络安全法》、《网络安全等级保护基本要求》等；

l 行业监管法令、指引及技术标准，如《证券期货业信息系统安全等级保护基本要求（试行）JR-T 0060-2010》、《证券公司网上证券信息系统技术指引》等；

l 公司自有信息安全策略、标准及指南，如《xxxx公司信息技术数据管理规范》；

l 业界安全实践，如OWASP ASVS、OWSAP TOP 10等。

安全需求标准库可以提供项目进行安全需求与架构设计时，安全考虑的依据和范围，降低安全需求活动执行的难度，提高效率。

图25 安全需求标准库

2）轻量级威胁建模。

威胁建模是分析应用程序安全性的一种结构化方法，通过识别威胁，定义防御或消极威胁控制措施的一个过程。威胁建模属于微软SDLC中核心部分，微软一直是这一过程的强有力倡导者。但是传统的威胁建模流程太重，过于繁琐，且对于人工投入要求较高，很难适应业务的敏捷快速迭代开发模式。因此在实际使用中，我们对威胁建模过程进行了优化，将安全需求分析和架构设计过程结合，设计了轻量级威胁建模，主要包括攻击面分析和安全威胁库。

第一步，问卷调研。目的是要了解系统的关键信息，为后面的攻击面分析及威胁建模做准备。调研问卷主要包括系统架构、使用场景、重要数据、部署方式 4部分。其中系统架构关注统架构图、技术实现方案等，使用场景关注用户场景、用户群体、角色、访问方式等，数据关注是否有敏感数据，而部署关注部署架构及物理资产。

第二步，攻击面分析。进行基本的攻击面分析，采用简化的数据流图，关注系统与外部系统的边界等。

第三步，威胁识别。将识别出的攻击面，基于业务场景与威胁库（安全专家经验、长期积累而形成的安全威胁库，也可以直接采用安全需求标准库）进行匹配，识别出系统面临的威胁点。

第四步，安全设计方案。根据威胁分析结果，匹配安全需求标准库，输出进行威胁缓释需要实施的安全需求基线，制定最终的安全设计方案。

图26 轻量级威胁建模

自动化威胁建模。当前的轻量级威胁建模仍然处于手工阶段，为了提供效率，安全团队已经在SDL安全开发全流程赋能平台中，进行自动化轻量级威胁建模功能开发。基本思路是项目组自主进行安全调查问卷的填写，然后平台根据安全威胁库，自动化输出安全设计方案。

图自动化轻量级威胁建模

3）源代码安全扫描(SAST)。

源代码安全扫描，暨静态应用程序安全测试（SAST，Static Application Security Testing），是指分析应用程序的源代码或二进制文件的语法、结构、过程、接口等来发现程序代码存在的安全漏洞，有些工具也会依赖于编译过程，通过一些抽象语法树、控制流分析及污点追踪等技术手段来提升检测覆盖度和准确。

SAST优点是广泛支持多种语言和架构，对漏洞类型的覆盖率较高；但是存在缺点有误报率高、扫描速度慢及依赖安全专家对结果进行过滤和确认。

机构最初采用了Fortify及Appscan Source，但是，一方面，误报太多，需要耗费大量人力进行漏洞筛选和确认。中间也进行扫描过程优化，如定义漏洞规则，对扫描结果，按照关注优先级，如OWASP TOP 10中的SQL注入等，进行自动化过滤，筛选出少量漏洞给研发人员。另一方面，扫描速度太慢。这些因素都会拖累DevOps交付速度。

后来基于软件开发成熟度现状，为了更好的集成到DevOps流程，放弃商用工具，直接用开源SonarQube+FindSecurityBugs插件(共128条安全规则)取代。

图27 SonarQube集成Find Security Bugs插件

研发已经部署有代码质量管理平台SonarQube，安全团队基于该平台，采用find security bugs插件进行安全漏洞扫描，将安全规则集和代码质量规则集集成，形成“ht-sonar”profile，项目组只需要一次集成sonar扫描，即可以兼具代码质量及安全扫描功能。

图28 sonar扫描报告

SonarQube中Vulnerabilities即是安全规则扫描出来的安全漏洞，对于项目组来说，对应的项目只需要集成了sonar扫描，既可在日常构建过程中自动进行安全扫描，根据SonarQube中的安全测试结果，自行进行漏洞的修复工作。项目上线前，只需要提交最终的SonarQube源代码安全测试结果给安全人员审核即可。

由于Find Security Bugs插件规则还不是太全，且只支持Java，所以需要进行调优。本年度引入服务，进行sonar源代码安全扫描插件的定制化开发，主要调优方向有：对已有扫描器的检测效果和误报漏报进行分析调优；覆盖和增强Find Security Bugs插件所涉及的安全检测能力并中文化安全风险提示；支持更多编程语言安全扫描，支持C、C++语言的安全问题检测；支持Python、JavaScript、PHP语言的安全规范检测；安全编码规范执行自动化检测；增加商业扫描器所能检测的安全缺陷类型（如Checkmarx能检测的主流安全漏洞类型）。

源代码安全扫描的集成点主要有：

l 开发人员本地源代码安全检测，可以采用IDE插件方式

l 代码提交时进行源代码安全检测

l CI构建过程中进行源代码安全扫描

在这三个阶段，前两个阶段安全规则可以更全面，即使有些误报也可以接受，而在CI构建过程中，为了构建的速度以及成功率，如果有安全质量门限，安全扫描规则要尽可能精简并准确。

4）黑盒安全测试(DAST)。

黑盒安全测试，暨动态应用程序安全测试（DAST，Dynamic Application Security Testing），是指在测试或运行阶段分析应用程序的动态运行状态。它模拟黑客行为对应用程序进行动态攻击，分析应用程序的反应，从而确定该Web应用是否易受攻击。

DAST有点是测试结果准确率较高，但是缺点是扫描速度偏慢，漏洞覆盖率低，无法有效支持API及微服务。

机构目前采用的黑盒安全测试工具有AppScan、AWVS、OWASP ZAP和Arachni，通过三叉戟自动化安全测试平台进行封装和分布式扫描调度，提供API方式给DevOps平台进行集成。但是由于研发测试环境没有统一的测试token，无法有效的进行登录式扫描。目前自动化方式时采用非登录扫描。目前也在探索基于流量代理或镜像方式的黑盒安全测试技术。

图29 自动化安全测试平台

4）交互式应用安全测试(IAST)。

IAST交互式安全测试技术是一种实时动态交互的漏洞检测技术，通过在服务端部署Agent程序，收集、监控Web应用程序运行时函数执行、数据传输，并与扫描器端进行实时交互，高效、准确的识别安全缺陷及漏洞，同时可准确确定漏洞所在的代码文件、行数、函数及参数，IAST融合了SAST和DAST技术的优点，无需源码，支持对字节码的检测。IAST是通过插桩将动态应用安全测试（DAST）和静态分析安全测试（SAST）技术结合起来，以提高应用安全测试的准确性。插桩技术可以获得DAST所能达到的准确性和SAST所能实现的代码覆盖率。

IAST极大的提高了安全测试的效率和准确率，良好的适用于敏捷开发和DevOps，可以在软件的开发和测试阶段无缝集成到DevOps，让研发人员在执行功能测试的同时，无感知的完成安全测试，实时输出安全测试结果。而IAST缺点就是需要特定语言的支持，目前主流支持语言是JAVA、C#等，因此，在整个软件开发生命周期中，需要SAST、DAST及IAST共同使用，结合各自安全检测能力优势，及时、准确的发现更多的安全风险。

机构今年已经引入了IAST工具Contrast Security，集成到DevOps平台中，进行自动化安全测试。

图30 IAST扫描结果

5）开源组件安全扫描(SCA)。

据Blackduck调查显示，96%的组织在其IT商用系统中使用了开源软件，在参与调查的1000个商用项目中，平均每个项目使用147个开源组件。Gartner调查显示，应用程序中最终需要开发人员编写的代码数量平均少于10%，然而，开源软件中存在大量的安全隐患，企业在享受开源软件带来的便利的同时，也在承担着巨大的安全风险。金融服务和金融技术的应用程序中漏洞是最高的。每个金融产品含52个漏洞，60%的应用程序含高危风险。很多非常流行组件的高危漏洞出现在经常使用的版本中，包括Apache Common Collections和Spring Framework。

开源组件的安全漏洞愈发引起大家重视，机构也很早就进行开源组件的安全治理，主要实践如下：

l 引入开源组件的安全扫描工具。引入商业的BlackDuck，支持安全风险及许可证合规检测。开源的有OWASP Dependency Check。

l 自动化集成。将开源组件扫描工具和研发DevOps平台工具链CI过程集成，实现DevOps流程中的开源组件安全自动化。

l 识别组件，建立开源组件资产库。项目在CI日常构建过程中，开源组件扫描工具会进行软件组成分析，包括框架、模块和第三方库等，形成应用程序的开源组件清单。同时，所有扫描的项目开源组件清单、项目信息等都会统一集中到开源组件资产库。通过该开源组件资产库，可以进行开源组件的资产管理。当有开源组件安全漏洞信息披露出来的时候，安全团队根据开源组件信息库可以立即做出判断，了解哪些应用系统受漏洞的影响，可以快速通知项目组进行漏洞修复。

l 建立内部安全开源组件仓库。建立内部的安全开源组件仓库，应用构建时，第三方组件都从该仓库获取，这样可以保证应用不包含已知漏洞的组件，降低了安全风险。

l 制定开源组件使用策略。制定开源组件使用策略，不允许开发人员私自从外网下载第三方组件，必须从内部的安全开源组件仓库获取。设置专人进行开源组件仓库管理。如果内部仓库不存在需要的第三方组件，则开发人员向管理员提交申请，由管理员及安全人员合作，从外网下载相应的第三方组件，并经过开源组件安全扫描工具检测安全为安全版本后，提交到内部仓库。

l 持续监测开源组件威胁。由于开源组件威胁在持续变化，因此需要在应用系统的生命周期内对其组件进行持续监控。如果组件出现安全漏洞，需要通知相应的项目组进行漏洞的及时修复，同时移除内部仓库中不安全版本组件，更新为安全版本。

图31 开源组件安全扫描

但是要注意到，开源组件的治理初期会比较困难。因为组件之间的依赖性较强，以及兼容性问题，开源组件的漏洞修复比较困难，尤其对于存量老系统。因此，开源组件的治理策略是从上往下，首先常规扫描收集开源组件资产数据，根据现状制定改进策略，如内部安全开源组件仓库、架构组件标准化等。

6）容器安全扫描

随着容器技术的兴起，越来越多的应用选择容器部署，与此同时，容器的安全性问题也受到了越来越广泛的关注。基于此，DevOps项目组和安全团队结合双方专业优势，形成了一套行之有效的容器安全最佳实践，建立了容器全生命周期安全管理方法论，利用完整的安全工具链对容器进行检测、监控及修复，保障容器镜像及运行环境的安全。

图容器安全生命周期管理

Docker安全配置基线。根据CIS的Docker安全标准整理了Docker容器安全实践指南，该指南包括了主机安全配置、Docker守护进程配置、Docker守护程序配置文件、容器镜像和构建、容器运行安全、Docker安全操作等方面多个控制点，给研发及运维人员提供Docker安全加固指南，降低Docker安全风险。

Kubernetes安全。部门在开发测试环境和生产环境中，采用了Kubernetes作为容器云的编排服务和集群运行环境，Kubernetes安全直接关系到容器的运行安全。Kubernetes 提供了很多能够提高应用安全的方法，根据实践总结了Kubernetes部署安全指南，用于指导Kubernetes的安全部署。

内部安全镜像仓库。通过内部安全镜像仓库，避免了研发人员从互联网拉取带有安全漏洞的镜像到运行环境，从源头消除已知含有漏洞组件的使用，提高了容器安全性。

1）内部所有容器构建，只能基于内部安全镜像仓库；禁止开发人员从公共网络直接下载镜像，而是维护一个安全的内部镜像仓库。开发团队和安全团队合作，建立和维护内部的镜像仓库。架构师、容器项目组和安全团队持续维护镜像库为最新版本，同时建立了开发人员请求新镜像的流程。

2）开发测试环境和生产环境所有依赖的统一管理：开发测试环境和生产环境的公开基础映像，统一由平台团队管理，开发团队在构建映像过程中可能用到的开源组件依赖包统一由质量团队管理,需要进行升级和特定支持应用安全所需要的操作系统和相关应用包统一由安全团队管理。各团队在开发测试及生产环境专门搭建本地私用库，由固定服务器外连指定的少数可信源（官方或官方认证站点）；

3）从互联网Docker镜像仓库拉取镜像时，必须经过Docker安全扫描，确认无安全漏洞，才可以拉取到内部安全镜像仓库；

4）第三方开源组件入库时，触发开源组件安全扫描工具，进行已知开源组件漏洞检测，如有漏洞则进行隔离和提示管理员，确定下一步操作，经过确认无安全漏洞的开源组件才可以入库。

容器安全扫描工具自动化集成。机构自有的DevOps平台承载公司所有容器的CI/CD，DevOps平台通过与容器安全扫描工具集成，在容器构建过程中融入安全要素，解决了镜像的安全问题，同时CI构建报告中直接集成容器安全扫描结果，提高了安全漏洞修复效率及易用性。

目前机构生产环境的Docker主机均从机构内部私有Registry中提取生产镜像。当构建工具上传镜像到私有Registry后，容器安全扫描器会从该Registry中获取镜像的副本，实施安全测试。整个过程可分解为以下关键步骤：

1) 当开发团队自动提交构建或构建触发器时，构建工具将从源代码控制工具中提取源代码；

2) 构建工具可以在构建过程中运行一些测试，当测试成功时，镜像将推送到企业私有Registry；

3) 容器安全扫描器从私有Registry获取相关容器镜像，分析元数据清单，进行安全扫描；

4) DevOps平台通过容器安全扫描器API接口获取扫描报告。

容器安全风险度量及可视化。为了对项目组的容器安全风险进行度量及直观展示，从容器镜像的项目分布、安全漏洞、操作系统等纬度进行了可视化展示，便于项目组进行容器安全风险的持续监控及容器安全漏洞的修复。

图容器安全风险度量可视化

7）威胁监控

在企业安全运营过程中，需要面对的安全数据越来越多，如流量数据（HTTP、DNS等）、安全防护设备与网络基础设施数据（NGFW、WAF、IPS、IDS等）、终端数据（操作系统日志、防病毒日志、EDR等）、资产与漏洞信息、情报数据（第三方开源、商业威胁情报）等，各种告警数据分散且没有打通，有限的安全人员和海量日志告警是突出矛盾，而安全效能越高就需要更多的数据。如何从海量告警数据中高效发现极少量的真实事件线索，也是对安全团队的极大考验。而在实际的安全运营中，常常缺少高效的安全业务运营工作平台，无法实现网络安全、数据安全和业务安全等多领域的闭环运营。

安全态势感知是近几年的一个热点，但是在调研安全感知态势产品过程中，会发现存在一些问题。

l 厂商的普遍性标准化产品与多样的行业运营需求难对齐

l 厂商设备“面向告警”而非“面向风险和运营效能”，自动化运营程度和效能有限

l 单一安全厂商的技术实力有限，多源技术引入是趋势，但是厂商间技术集成性和互通性差，充分技术整合异构外部能力就成了迫切需求

在充分调研国内外产品及技术的基础上，机构基于开源技术实现，同时进行其他商业产品的能力集成，自研了“泰坦”人工智能安全态势感知平台，主要功能有海量安全日志集中化管理、NTA网络流量分析、网络安全威胁态势可视化、UEBA内部用户行为分析、TI情报中心、EDR端点检测与响应、SOAR安全编排与自动化响应等。

图“泰坦”人工智能安全态势感知平台

通过收集、处理、分析企业安全数据，借助外部威胁情报和大数据分析技术提高效率，赋能公司安全响应中心运营人员检测、响应和预测内、外部威胁和事件。随着人员能力和产品成熟度螺旋式上升，持续降低公司的攻陷检测时间（MTTD）和攻陷响应时间（MTTR），实现对企业面临的内外部威胁快速检测、实时分析和自动化处置能力，使得企业具备安全可知、可见、可控的全网安全态势感知能力。

“泰坦”已成为安全运营的核心工作平台，具备海量数据中威胁快速有效发现能力，使得安全运营人员持续专注优先威胁，利用自动化手段，弥补安全人员限制，最终提升了运营驱动的威胁和事件快速响应支撑能力。

图 “泰坦”技术及运营指标

8）安全响应

机构漏洞响应的主要流程如下（以weblogic漏洞响应为例）：

a）漏洞情报。从厂商公告、安全情报厂商、安全社区和朋友圈等渠道获取漏洞情报。

b）漏洞评估。根据漏洞影响的资产类型、公司资产数据库，确定受影响的服务器以及应该参与响应的系统管理员。有风险的漏洞按照严重（严重可被exp的RCE漏洞）、高危（其他可被exp的远程利用漏洞）、中危（可被exp的本地其他漏洞）和低危（其他漏洞）四级分类。

c）预警定级。依据安全响应中心漏洞响应应急预案中的设定，确定本次漏洞响应级别为3级“黄色”。（预警通告等级分为三级，由高到低依次用红色、橙色和黄色表示，分别对应发生或可能发生一级、二级和三级事件）

d）发布预警。通过邮件方式对全IT发布“橙色”预警。邮件正文直接给出已知受影响的系统名称、IP地址、人和团队等信息，同时要求其他人员开展自查，防止遗漏。

e）组织修复。系统管理员根据官方给出的修复方式组织修复；安全运营人员联系网络层IPS厂商获取IPS特征签名，并下发全网。

f）验证修复。利用漏洞扫描器、POC脚本等方式对漏洞进行修复验证。使用漏洞扫描器就该漏洞进行全网扫描。

g）解除预警。通过邮件方式解除预警。

为了提升漏洞应急响应能力，主要关注点有漏洞情报的获取、精细化的资产管理、应急响应流程的制定、漏洞快速检测能力等。

在安全运营过程中，为了实现安全漏洞的快速响应，对漏洞响应过程进行了工程化，实现了安全漏洞响应RPA。

图安全漏洞响应RPA

3.3.4 技术（Technology）

DevSecOps核心理念之一，是要工具化和自动化，所以工具必不可少。机构已经初步建立了端到端完整的安全工具链，并自动化集成到DevOps流程中。

图32 安全工具链

目前DevOps中安全工具自动化部分，主要有DEV环境的源代码安全扫描SAST、开源组件安全扫描SCA、移动APP加固，SIT阶段的Docker安全扫描、黑盒安全扫描DAST及交互式安全扫描IAST。团队目前也在开发自动化安全测试平台，将各种商业/开源安全工具，如源代码安全扫描、黑盒安全扫描、渗透测试工具等集成进来，对外提供集成安全测试能力支持，并通过API接口方式集成到DevOps平台。

目前比较耗费人力的节点是轻量级威胁建模。团队已经在SDL安全开发全流程赋能平台中，进行自动化轻量级威胁建模功能开发。基本思路是项目组自主进行安全调查问卷的填写，然后平台根据安全威胁库，自动化输出安全设计方案。安全要做的事情，就是不断来丰富安全威胁库。未来，可以考虑结合代码分析、多维度安全测试以及人工智能、NLP等技术，来智能化进行威胁建模。

图33 自动化轻量级威胁建模

“工欲善其事，必先利其器”，支撑DevSecOps过程中安全活动，安全工具必不可少。机构具有较完备的安全武器库，给IT提供活力支撑。

图34 安全武器库

3.3.5 度量（Measurement）

管理学大师彼得 · 德鲁克（Peter Drucker）曾经说过，“你如果无法度量它，就无法管理它”（If you can’t measure it, you can’t manage it）。要想提高DevSecOps效能，自然要首先解决效能的度量的问题。

DevSecOps过程度量指标。安全团队制定了DevOps过程中安全活动对应的门限及度量指标，通过门限控制软件进入制品库的度量标准，通过度量指标来衡量项目的安全成熟度。

图35 DevOps中安全活动门限及度量指标

指标驱动运营。为了提高端到端安全交付效能，安全也在转型，基于运营的思路来进行项目安全建设。制定了项目安全建设运营指标，如项目安全评估的覆盖率、端到端安全交付效能、安全工具链DevOps集成率、安全测试能力覆盖率、安全漏洞修复率、安全漏洞漏出率、标准化安全组件、软件安全能力成熟度等。设计指标的基本原则：能够指导行动的指标才是好指标。

通过运营指标来驱动行动，制定行动计划，并在运营过程中，不断用指标数据来验证成效，使得安全更加聚焦于重点方向。

图36 安全工程效能运营报告

软件安全成熟度。每年安全团队都会进行软件安全成熟度自评估。软件安全成熟度评估模型基于BSIMM(Build Security In Maturity Model，软件安全构建成熟度模型)，BSIMM分为4个领域12类实践，总共包括100多项活动。

图37 BSIMM软件安全构建成熟度模型

评估时，基于自定义的标准，对每个活动的成熟度进行打分，最终以蜘蛛图的方式呈现出当前的软件安全成熟度。2020年底基于BSIMM11，机构的软件安全成熟度结果如下图。

图38 机构2019软件安全构建成熟度

基于成熟度评估结果，会进行差距分析，和业界领先进行比较，发现不足之处，结合实施的成本和收益，确定下一年度可行的改进方向，制定成熟度行动计划，不断提升软件安全成熟度。

3.3.6 安全工具及平台（Security Tool And Platform）

为了提升安全运营效能，安全团队自主研发了泰坦人工智能安全平台、棱镜内部用户行为分析平台、三叉戟应用安全工程中台等。

图39 安全工具及平台

1）三叉戟应用安全工程中台

本年度将重点建设三叉戟应用安全工程中台，自主研发打造多元化安全能力平台，包括安全SDK组件武器库、SDL安全开发全流程赋能平台、自动化安全测试平台、漏洞全生命周期管理平台及应用资产安全风险感知平台等，助力DevSecOps安全运营效能提升。

图40 SDL安全开发全流程赋能平台

2）泰坦人工智能安全态势感知平台

习总书记在网络安全和信息化工作座谈会上提到：“全天候全方位感知网络安全态势，知己知彼，才能百战不殆。没有意识到风险是最大的风险。”这段讲话不仅阐明了国家层面对于网络安全的重视程度，也让企业清楚的认识到网络安全的重要程度，以及建设全天候全方位感知网络安全态势能力的必要性。

安全数据越来越多，如WAF、防火墙、DLP、防病毒等告警数据，各种告警数据分散且没有打通，有限的安全人员和海量日志告警是突出矛盾，而安全效能越高就需要更多的数据。如何从海量告警数据中高效发现极少量的真实事件线索，也是对安全团队的考验。而在实际的安全运营中，缺少高效的安全业务运营工作平台，无法实现网络安全、数据安全和业务安全等多领域的闭环运营。

安全态势感知是近几年的一个热点，但是在调研安全感知态势产品过程中，会发现存在一些问题。

l 厂商的普遍性标准化产品与多样的行业运营需求难对齐

l 厂商设备“面向告警”而非“面向风险和运营效能”，自动化运营程度和效能有限

l 单一安全厂商的技术实力有限，多源技术引入是趋势，但是厂商间技术集成性和互通性差，充分技术整合异构外部能力就成了迫切需求

由于大数据技术栈已技术成熟且社区活跃，关键技术获取和应用已经不是瓶颈，在充分调研国内外产品及技术的基础上，决定自研安全态势感知平台 -“泰坦”人工智能安全态势感知平台。

“泰坦”的核心目标是通过收集、处理、分析企业安全数据，借助外部威胁情报和大数据分析技术提高效率，赋能公司安全响应中心运营人员检测、响应和预测内、外部威胁和事件。随着人员能力和产品成熟度螺旋式上升，持续降低公司的攻陷检测时间（MTTD）和攻陷响应时间（MTTR），实现对企业面临的内外部威胁快速检测、实时分析和自动化处置能力，使得企业具备安全可知、可见、可控的全网安全态势感知能力。

“泰坦”的系统架构如下：

图41 “泰坦”系统架构

“泰坦”主要功能如下：

图42 “泰坦”功能

“泰坦”的建设方案，主要基于开源技术实现，同时具备集成其他商业产品的能力，通过安全能力的集成，进行协同防御。“泰坦”采用的开源技术栈如下图：

图43 “泰坦”采用的开源技术栈

“泰坦”平台以后，已成为安全运营的核心工作平台，具备海量数据中威胁快速有效发现能力，使得安全运营人员持续专注优先威胁，利用自动化手段，弥补安全人员限制，最终提升了运营驱动的威胁和事件快速响应支撑能力。

图42 “泰坦”技术及运营指标

3）应用资产安全风险感知平台

“You Can’t Secure What You Can’t See”。

总结

在敏捷和DevOps已经足够成熟的今天，如何在快速交付价值的同时控制安全风险，是很多企业面临的难题。本文的DevSecOps实践可以作为参考指南，降低企业学习及实践成本、少走弯路。

安全人员应该积极主动的融入DevSecOps的实践，秉承DevOps的精神，拥抱“团队协作、敏捷和职责共当的哲学”，将安全更好的内嵌到软件研发过程中，通过安全赋能IT，在提高安全工作效率的同时，降低IT系统信息安全风险。

DevSecOps趋势下，安全，从“守门人”(Gatekeeper) 演变到，赋能(enable)各团队,缺省就处于安全的状态(Security shifts from being a gatekeeper to enabling teams to be secure by default)。

【参考文献】

【1】2017 State of DevOps Report.

https://puppet.com/system/files/2017-10/2017-state-of-devops-report-puppet-dora.pdf

【2】Gartner: DevSecOps: How to Seamlessly Integrate Security Into DevOps.

https://www.gartner.com/document/3463417

【3】RSA Conference.

https://www.rsaconference.com

【4】Gartner: 10 Things to Get Right for Successful DevSecOps.

https://www.gartner.com/document/3811369

【5】Gartner: Structuring Application Security Practices and Tools to Support DevOps and DevSecOps.

https://www.gartner.com