2012 年，Gartner首次提出 DevSecOps 理念。四年后，它发布了一份名为《DevSecOps: How toSeamlessly integrate Security into DevOps》的报告。这份报告的核心理念是：安全是整个IT团队（包括开发、运维及安全团队）每个人的责任，需要贯穿从开发到运营整个业务生命周期的每一个环节。对应 DevOps 快速交付和灵活响应变化，DevSecOps 的价值是在不牺牲安全性的前提下，快速和规模地交付安全决策。基于Gartner关于DevSecOps的理念，机构从文化、流程及技术等方面探索、实践并落地了DevSecOps，通过固化流程、加强人员协作以及工具化、自动化技术手段将安全无缝内嵌到研发流程中。首先，要培养自己的安全团队，建设自身的专业安全能力。设立约有20个专业安全人员的团队，覆盖应用安全、GRC(治理、风险和合规)、数据安全、业务安全、安全运营等方向。其中应用安全团队负责DevSecOps的研究与落地，设置专门的安全顾问，负责项目安全评估与咨询，以及项目安全建设的全流程跟踪。高层支持。借助监管要求、外部咨询、安全案例等形式，积极和高层沟通，强化应用系统生命周期安全管理的必要性，争取高层的认同与支持，获得更多的资源。确立软件安全开发生命周期管理方法论。借鉴业界成熟的安全生命周期管理方法论，结合企业现状，形成一套信息系统生命周期安全管理的框架，规定在软件安全开发的不同阶段需要开展的安全活动，且该框架各个活动模块是灵活可裁剪的，根据IT成熟度决定采取的安全活动。安全活动干系人。通过安全宣贯、BSI白皮书、安全顾问、项目安全评估等形式，对IT人员进行软件生命周期安全开发实践的推广，并明确项目安全建设过程中涉及的干系人的主要活动、职责和义务，让IT人员意识到安全是整个IT团队每个人的责任。安全培训。开展一系列的信息安全技能培训，提升IT人员安全专业技能。基于不同角色，定制不同的培训课程。除了线下活动，还要在网络培训学院及信息安全门户，提供培训视频、技术指南、漏洞知识库、最佳实践等，让IT人员可自主学习，提升安全技能，主动在日常研发和运营过程融入安全要素，降低安全风险。安全积极分子。将开发人员培养成安全积极分子，通过其潜移默化的影响，带动其他开发人员的安全意识，在日常开发过程中融入安全要素，同时也能解决安全人员不足的问题。另外，在内部信息安全门户建立了漏洞修复知识库，鼓励开发人员将日常漏洞修复过程分享出来，共同维护该知识库，其他开发人员修复漏洞时，可参考知识库进行快速修复，降低修复成本。以史为鉴。收集和总结以往发生的真实漏洞案例，形成“漏洞-以史为鉴”，对研发及运维人员进行安全宣贯，可以引发其共鸣，达到更好的安全意识宣贯的效果。另一方面，共性的漏洞问题也反馈给研发，从架构等层面进行优化，从根源上解决此类安全问题。安全策略。安全团队和质量团队合作，对应用系统进行分类分级，定义不同的安全策略，将安全活动嵌入到项目流程中。系统分类分级维度有研发模式、网络模式、用户场景等。通过在项目过程定义中加入安全策略，可以督促开发人员在研发过程中主动进行安全活动，潜移默化提升其安全意识。安全活动。机构在DevOps研发运营一体化过程中通常会进行以下安全活动，选取部分主要活动进行说明。1）安全需求标准库
安全需求标准库，以等保2.0为基础框架，汇总各种安全需求而形成的安全通用需求库，主要需求来源有：
- 国家法律法规及标准，如《网络安全法》、《网络安全等级保护基本要求》等；
- 行业监管法令、指引及技术标准，如《证券期货业信息系统安全等级保护基本要求（试行）JR-T 0060-2010》、《证券公司网上证券信息系统技术指引》等；
- 公司自有信息安全策略、标准及指南，如《xxxx公司信息技术数据管理规范》；
- 业界安全实践，如OWASP ASVS、OWSAP TOP 10等。
安全需求标准库可以提供项目进行安全需求与架构设计时，安全考虑的依据和范围，降低安全需求活动执行的难度，提高效率。
威胁建模是分析应用程序安全性的一种结构化方法，通过识别威胁，定义防御或消极威胁控制措施的一个过程。威胁建模属于微软SDL中核心部分，微软一直是这一过程的强有力倡导者。但传统的威胁建模流程过于繁琐，且对人工投入要求较高，很难适应业务的敏捷、快速迭代开发模式。故在实际使用中，对威胁建模进行了优化，结合安全需求分析和架构设计过程，进行轻量级的威胁建模，主要包含攻击面分析和安全威胁库。
第一步，问卷调研。目的是要了解系统的关键信息，为后面的攻击面分析及威胁建模做准备。调研问卷主要包括系统架构、使用场景、重要数据、部署方式 4部分。第二步，攻击面分析。进行基本的攻击面分析，采用简化的数据流图，关注系统与外部系统的边界等。第三步，威胁识别。将识别出的攻击面，基于业务场景与威胁库（安全专家经验、长期积累而形成的安全威胁库，也可以直接采用安全需求标准库）进行匹配，识别出系统面临的威胁点。第四步，安全设计方案。根据威胁分析结果，匹配安全需求标准库，输出进行威胁缓释需要实施的安全需求基线，制定最终的安全设计方案。当前的轻量级威胁建模仍处于手工阶段，为了提高效率，安全团队在SDL安全开发全流程赋能平台中，可以进行自动化轻量级威胁建模功能开发。项目组自主填写安全调查问卷，然后平台根据安全威胁库，自动输出安全设计方案。其中，安全人员要不断丰富安全威胁库。未来，可考虑结合代码分析、多维度安全测试以及人工智能、NLP等技术，进行智能化威胁建模。
源代码安全扫描，即静态应用程序安全测试（SAST，Static Application Security Testing），是指分析应用程序的源代码或二进制文件的语法、结构、过程、接口等来发现程序代码存在的安全漏洞，有些工具也会依赖于编译过程，通过一些抽象语法树、控制流分析及污点追踪等技术手段来提升检测覆盖度和准确。
SAST的优点是广泛支持多种语言和架构，对漏洞类型的覆盖率比较高；缺点是误报率高、扫描速度慢、依赖安全专家对结果进行过滤和确认。基于软件开发成熟度现状，直接用开源SonarQube+FindSecurityBugs插件(最新版共138条安全规则，https://find-sec-bugs.github.io/)。研发已经部署有代码质量管理平台SonarQube，基于该平台安全团队采用find security bugs插件进行安全漏洞扫描，将安全规则集和代码质量规则集集成，形成“ht-sonar”profile，项目组只需要一次集成sonar扫描，即可以兼具代码质量及安全扫描功能。SonarQube中Vulnerabilities即是安全规则扫描出来的安全漏洞，对于项目组来说，对应的项目只需要集成了sonar扫描，既可在日常构建过程中自动进行安全扫描，根据SonarQube中的安全测试结果，自行进行漏洞的修复工作。项目上线前，只需要提交最终的SonarQube源代码安全测试结果给安全人员审核即可。由于Find Security Bugs插件规则还不是太全，且只支持Java，所以需要进行调优。本年度引入白盒厂家，基于sonar进行源代码安全扫描插件的定制化开发，主要调优方向有：
- 覆盖和增强Find Security Bugs插件所涉及的安全检测能力并中文化安全风险提示；
- 支持Python、JavaScript、PHP语言的安全规范检测；
- 支持更多编程语言安全扫描，支持C、C++语言的安全问题检测；
- 增加商业扫描器所能检测的安全缺陷类型（如Checkmarx能检测的主流安全漏洞类型）。
定制化sonar安全插件在使用上不影响原有的研发构建过程（仍然为mvn sonar:sonar）。源代码安全检测可以在多个环节进行集成，集成点主要有：
- 开发人员本地源代码安全检测，可以采用IDE插件方式。
- 代码提交时进行源代码安全检测，如gitlab通过webhook触发源代码扫描，设置代码安全漏洞门禁，对于有中高危漏洞的拒绝commit。安全编码规范是否遵从可以在这里管控。
在这三个阶段，前两个阶段安全规则可以更全面，即使有些误报也可以接受，而在CI构建过程中，为了构建的速度以及成功率，如果有安全质量门限，安全扫描规则要尽可能精简并准确。
黑盒安全测试，即动态应用程序安全测试（DAST，Dynamic Application Security Testing），是指在测试或运行阶段分析应用程序的动态运行状态。它模拟黑客行为对应用程序进行动态攻击，分析应用程序的反应，从而确定该Web应用是否易受攻击。
DAST，优点是测试结果准确率较高；缺点是扫描速度偏慢，漏洞覆盖率低，无法有效支持API及微服务。机构目前采用的黑盒安全测试工具有AppScan、AWVS、OWASP ZAP和Arachni，可以通过自动化安全测试平台进行封装和分布式扫描调度，提供API方式给DevOps平台集成。从使用效果来看，黑盒扫描出来的漏洞有限，只能作为一种补充，后继考虑引入基于流量的黑盒安全测试技术。IAST集成测试效果更好。
IAST交互式安全测试技术是一种实时动态交互的漏洞检测技术，通过在服务端部署Agent程序，收集、监控Web应用程序运行时函数执行、数据传输，并与扫描器端进行实时交互，高效、准确的识别安全缺陷及漏洞，同时还可精准确定漏洞所在的代码文件、行数、函数及参数。IAST，融合了SAST和DAST技术的优点，无需源码，支持对字节码的检测，提高了应用安全测试的准确性。
IAST极大的提升了安全测试的效率和准确率，适用于敏捷开发和DevOps，可以在软件的开发和测试阶段无缝集成到DevOps，让研发人员在执行功能测试的同时，无感知的完成安全测试，实时输出安全测试结果。而IAST的缺点就是需要特定语言的支持，目前主流支持语言是JAVA、C#等，因此在整个软件开发生命周期中，需要SAST、DAST及IAST共同使用，结合各自的优势，及时、准确的发现更多的安全风险。IAST工具使用时可由测试人员自行安装agent，在功能测试同时就可以完成安全测试，自行进行漏洞修复。与DevOps平台集成后，在版本发布到SIT或者提测环节，自动化将agent部署到测试环境中，在研发测试人员无感知下完成安全测试。
Gartner调查显示，应用程序中最终需要开发人员编写的代码数量平均少于10%，然而，开源软件中存在大量的安全隐患，企业在享受开源软件带来便利的同时，也承担着巨大的安全风险。调研发现，有不少企业在研发阶段还未开展开源组件安全治理。
开源组件的安全漏洞愈发引起大家重视，机构也很早就进行开源组件的安全治理，主要实践如下：
引入开源组件的安全扫描工具。引入商业的BlackDuck，支持安全风险及许可证合规检测。开源的有OWASP Dependency Check。
自动化集成。将开源组件扫描工具和研发DevOps平台工具链CI过程集成，实现DevOps流程中的开源组件安全自动化。
识别组件，建立开源组件资产库。项目在CI日常构建过程中，开源组件扫描工具会进行软件组成分析，包括框架、模块和第三方库等，形成应用程序的开源组件清单。同时，所有扫描的项目开源组件清单、项目信息等，都会统一集中到开源组件资产库，并进行开源组件的资产管理。当有开源组件安全漏洞信息披露时，安全团队可以立即做出判断，了解哪些应用系统受漏洞的影响，通知项目组快速修复漏洞。
建立内部安全开源组件仓库。应用构建时，第三方组件都从该仓库获取，这样可以保证应用不包含已知漏洞的组件，降低了安全风险。
制定开源组件使用策略。只允许开发人员从内部的安全开源组件仓库获取第三方组件，并设置专人管理。如果内部仓库没有所需的第三方组件，开发人员则向管理员申请，由管理员和安全人员合作，从外网下载相应的第三方组件，并经过开源组件安全扫描工具检测为安全版本后，提交到内部仓库。
持续监测开源组件威胁。由于开源组件威胁在持续变化，因此需要在应用系统的生命周期内对其组件进行持续监控。如果组件出现安全漏洞，需要通知相应的项目组及时修复，同时移除内部仓库中不安全版本组件，更新为安全版本。
但是要注意，开源组件在治理初期比较困难。由于组件之间的依赖性较强，以及兼容性问题，开源组件的漏洞修复比较困难，尤其对于存量老系统。因此，开源组件的治理策略是从上往下，首先常规扫描收集开源组件资产数据，根据现状制定改进策略，如内部安全开源组件仓库、架构组件标准化等。
随着容器技术的兴起，越来越多的应用选择容器部署，因此容器的安全性也受到了广泛的关注。基于此，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中获取镜像的副本，实施安全测试。整个过程可分解为以下关键步骤：
- 当开发团队自动提交构建或构建触发器时，构建工具将从源代码控制工具中提取源代码；
- 构建工具可以在构建过程中运行一些测试，当测试成功时，镜像将推送到企业私有Registry；
- 容器安全扫描器从私有Registry获取相关容器镜像，分析元数据清单，进行安全扫描；
- DevOps平台通过容器安全扫描器API接口获取扫描报告。
容器安全风险度量及可视化。为了对项目组的容器安全风险进行度量及直观展示，从容器镜像的项目分布、安全漏洞、操作系统等纬度进行了可视化展示，便于项目组进行容器安全风险的持续监控及容器安全漏洞的修复。企业在安全运营过程中，需要面对的安全数据越来越多，如流量数据、安全防护设备与网络基础设施数据、终端数据、资产与漏洞信息、情报数据等，各种告警数据分散且没有打通，有限的安全人员和海量日志告警是突出矛盾，而安全效能越高就需要更多的数据。如何从海量告警数据中高效发现极少量的真实事件线索，也是对安全团队的极大考验。而在实际的安全运营中，常常缺少高效的安全业务运营工作平台，无法实现网络安全、数据安全和业务安全等多领域的闭环运营。安全态势感知是近几年的一个热点，但是在调研安全感知态势产品过程中，会发现存在一些问题：厂商的普遍性标准化产品与多样的行业运营需求难对齐；厂商设备“面向告警”而非“面向风险和运营效能”，自动化运营程度和效能有限；单一安全厂商的技术实力有限，多源技术引入是趋势，但是厂商间技术集成性和互通性差，充分技术整合异构外部能力就成了迫切需求。要满足企业要求可以基于开源技术实现，同时进行商业产品的能力集成，主要的功能有海量安全日志集中化管理、NTA网络流量分析、网络安全威胁态势可视化、UEBA内部用户行为分析、TI情报中心、EDR端点检测与响应、SOAR安全编排与自动化响应等。通过收集、处理、分析企业安全数据，借助外部威胁情报和大数据分析技术提高效率，赋能公司安全响应中心运营人员检测、响应和预测内外部威胁和事件。随着人员能力和产品成熟度螺旋式上升，持续降低公司的攻陷检测时间（MTTD）和攻陷响应时间（MTTR），实现对企业面临的内外部威胁快速检测、实时分析和自动化处置能力，使得企业具备安全可知、可见、可控的全网安全态势感知能力。通过该平台的海量数据实现快速有效发现威胁的能力，使得安全运营人员持续专注优先威胁，利用自动化手段，弥补安全人员限制，最终提升了运营驱动的威胁和事件快速响应支撑能力。
漏洞响应的主要流程如下（以weblogic漏洞响应为例）：
a）漏洞情报。从厂商公告、安全情报厂商、安全社区和朋友圈等渠道获取漏洞情报。b）漏洞评估。根据漏洞影响的资产类型、公司资产数据库，确定受影响的服务器以及应该参与响应的系统管理员。有风险的漏洞按照严重（严重可被exp的RCE漏洞）、高危（其他可被exp的远程利用漏洞）、中危（可被exp的本地其他漏洞）和低危（其他漏洞）四级分类。c）预警定级。依据安全响应中心漏洞响应应急预案中的设定，确定本次漏洞响应级别为3级“黄色”。（预警通告等级分为三级，由高到低依次用红色、橙色和黄色表示，分别对应发生或可能发生一级、二级和三级事件）d）发布预警。通过邮件方式对全IT发布“橙色”预警。邮件正文直接给出已知受影响的系统名称、IP地址、人和团队等信息，同时要求其他人员开展自查，防止遗漏。e）组织修复。系统管理员根据官方给出的修复方式组织修复；安全运营人员联系网络层IPS厂商获取IPS特征签名，并下发全网。f）验证修复。利用漏洞扫描器、POC脚本等方式对漏洞进行修复验证。使用漏洞扫描器就该漏洞进行全网扫描。为了提升漏洞应急响应能力，重点关注漏洞情报的获取、精细化的资产管理（特别是高危组件的使用情况）、应急响应流程的制定、漏洞快速检测能力等。在安全运营过程中，为了实现安全漏洞的快速响应，对漏洞响应过程进行了工程化，实现了安全漏洞响应RPA。DevSecOps核心理念之一，是要工具化和自动化，所以工具必不可少。机构已经初步建立了端到端完整的安全工具链，并自动化集成到DevOps流程中。目前DevOps中安全工具自动化部分，主要有DEV环境的源代码安全扫描、开源组件安全扫描、移动APP加固，SIT阶段的Docker安全扫描、黑盒安全扫描及交互式安全扫描。团队目前也在开发自动化安全测试平台，将各种商业/开源安全工具，如源代码安全扫描、黑盒安全扫描、渗透测试工具等集成进来，对外提供集成安全测试能力支持，并通过API接口方式集成到DevOps平台。机构已经具有较完备的安全武器库，给IT提供火力支撑。管理学大师彼得·德鲁克曾经说过，“你如果无法度量它，就无法管理它”。要想提高DevSecOps效能，自然要首先解决效能的度量问题。DevSecOps过程度量指标。应用安全团队制定了DevOps过程中安全活动对应的门限及度量指标，通过门限控制软件进入制品库的度量标准，通过度量指标来衡量项目的安全成熟度。指标驱动运营。为了提高端到端安全交付效能，制定了项目安全建设运营指标，如项目安全评估的覆盖率、端到端安全交付效能、安全工具链DevOps集成率、安全测试能力覆盖率、安全漏洞修复率、安全漏洞漏出率、标准化安全组件、软件安全能力成熟度等。设计指标以能够指导行动为基本原则。在运营过程中，不断用指标数据来验证成效，使得安全更加聚焦于重点方向。常态化风险报告机制。常态化项目风险报告运营，建立安全风险响应度量机制，对响应效能等进行度量，驱动团队改进优化。基于度量识别的安全问题自动反馈到问题团队，并周期性总结安全风险报告，对改进效果进行度量并持续反馈，实现安全问题的闭环管理。软件安全成熟度。每年应用安全团队都会进行软件安全成熟度自评估。软件安全成熟度评估模型基于BSIMM(软件安全构建成熟度模型)，BSIMM分为4个领域12类实践，总共包括120多项活动。安全团队对每一项进行解读，依据行业属性进行自身评估指标的制定，每年会根据BSIMM变化，同步回顾并修订评估指标。评估时，基于自定义的指标，应用安全团队多人对每个活动的成熟度进行打分，最终以蜘蛛图的方式呈现出当前的软件安全成熟度。基于成熟度评估结果，会进行差距分析，和业界领先进行比较，发现不足之处，结合实施的成本和收益，确定下一年度可行的改进方向，制定成熟度行动计划，不断提升软件安全成熟度。为了提升安全运营效能，安全团队可以自主研发人工智能安全平台、内部用户行为分析平台、应用安全工程中台等。应用安全工程中台，包括安全SDK组件武器库、SDL安全开发全流程赋能平台、自动化安全测试平台、漏洞全生命周期管理平台及应用资产安全风险感知平台等，助力DevSecOps安全运营效能提升。
2）人工智能安全态势感知平台
可以主要基于开源技术实现，同时具备集成其他商业产品的能力，通过安全能力的集成，进行协同防御。采集的数据源包括流量数据（http、dns等）、安全防护设备与网络基础设施数据（NGFW、WAF、IPS、IDS等）、终端数据（操作系统日志、防病毒日志、EDR等）、资产与漏洞信息、情报数据（第三方开源、商业威胁情报）、数据库日志、业务与用户认证数据等。
基于资产测绘、IT资源管理平台、防火墙策略、流量监控、API集市、应用系统目录、安全评估记录等数据，建立应用资产图谱。从项目安全设计、源代码扫描、黑盒扫描、开源组件风险、渗透测试、API监控、安全监控、威胁情报等纬度，对DEV研发及OPS运维qua全生命周期风险数据进行自动化采集、智能分析、可视化、告警及联动响应等。基于资产、风险、威胁等多维度风险模型，构建应用安全风险画像，实时感知应用安全风险态势，及时发现应用的风险点，如上传接口未加固、web管理后台暴露、敏感接口认证弱等，快速响应从而缓释风险。如今，敏捷和DevOps已经相当成熟，如何在快速交付价值的同时控制安全风险，仍是很多企业面临的挑战。本文的DevSecOps实践可以作为参考指南，降低企业学习及实践成本。在DevSecOps实践中，安全人员应该积极主动的融入进去，秉承DevOps的精神，拥抱“团队协作、敏捷和职责共当”的哲学，将安全更好的内嵌到软件研发过程中，通过安全赋能IT，在提高安全工作效率的同时，降低IT系统信息安全风险。
