最近几年随着软件供应链攻击和数据安全事件的频繁出现，企业面临着重大的软件供应链安全和数据泄露风险，这间接促使了越来越多的企业开始关注DevSecOps，并且期望借此来解决相关的安全风险。

在开始今天的分享之前，先简单介绍一下DevSecOps的定义，这里主要采用援引于DoD（美国国防部）的一段定义，即DevSecOps实际上是一种旨在统一软件开发、安全、运维运营的有组织的软件工程文化和实践。

DevSecOps is an organizational software engineering culture and practice that aims at unifying software development (Dev), security (Sec) and operations (Ops).

由于DevSecOps理念是将安全防御思维贯穿到整个软件开发和运维运营阶段，这就使得DevSecOps体系的构建变成一个可能的解决数据安全和供应链安全的有效途径。今天的这篇文章主要来谈谈大型互联网企业DevSecOps体系构建的总结和思考，为了方便读者理解笔者将会以一个虚拟的公司Parana来做说明。

组织与文化

导读：正如DoD的定义中所讲，DevSecOps不是指具体的技术或者工具平台而是一种软件工程文化和实践，因此对于期望构建DevSecOps体系的企业来说首先需要建设这样的组织和文化。

早在2002年Parana公司的创始人就开始在全公司top-down推广SOA（service-oritented architecture）文化[1]：

• 所有团队必须通过服务接口公开他们的数据和功能
• 团队间必须通过这些接口相互通信
• 不允许其他形式的进程间通信：不允许直接链接、不允许直接读取另一个团队的数据存储、不允许共享内存模型、不允许任何后门；唯一允许的通信是通过网络上的服务接口调用
• 每个团队可以根据自己的需求使用任何技术来实现
• 所有服务接口，无一例外，都必须从头开始设计为可外部化的，也就是说，团队必须进行规划和设计，以便能够将接口暴露给外界的开发人员

此外，Parana公司的理念是Two-Pizza团队[2]，即每个团队是一个不超过两个Pizza可以喂饱人数的最小独立组织。团队越小，协作越好。而协作非常重要，因为软件发布的速度比以往任何时候都快。团队交付软件的能力可能是组织在竞争中脱颖而出的一个因素。设想一下需要发布新产品功能或需要修复错误的情况，往往都希望这尽快发生，这样就可以有更短的上市时间。  这样的理念 在某种意义上也非常 契合DevSecOps的内在逻辑， 每个应用的开发运维运营 团队 应该是一个整体 而不是 割裂的组织，这样既减少了跨组织间的沟通成本也大大提升了软件交付的敏捷性及软件运行的安全性。

通过在公司top-down推行SOA企业文化和Two-Pizza团队组织形态，Parana公司具备了构建DevSecOps体系的基础，每个Two-Pizza团队类似于军队中的最小作战单元（班），“麻雀虽小但五脏俱全”，每个团队中基本上都配备了以下角色。

• 软件开发工程师：负责软件架构和开发
• 技术项目经理：负责软件立项、周边协作及项目管理
• 软件支持工程师：负责软件测试、运维和运营

流程与工具

导读：有了相应的组织和文化，接下来就是如何通过流程和工具将DevSecOps的理念固化下来，并持续运作。本节将从计划、开发、编译与测试、发布与交付、部署与运维、监控与反馈几个阶段进行介绍。

一、计划阶段

Parana公司在计划阶段要求每个软件项目立项后需要在应用服务安全评估系统中进行注册，该系统会根据《数据分类分级要求》、《数据分级处理标准》、《TOP威胁风险库》等生成应用服务风险评估问卷，通过回答问卷系统会自动根据问卷结果生成应用服务等级（Red、Orange、Yellow、Green），不同的级别对应着不同的安全要求，如：

• Red / Orange ： 需要有授权的安全评估人员 完成应用服务的 威胁建模分析 并提交 相应的 修复方案，且必须在上线前完成内部的渗透测试
• Yellow/Green：研发团队可以自行进行威胁建模分析，不强制上线前需要完成渗透测试，但是必须提交应用服务的应急响应计划和关键业务联系人以备出现安全事件后可以及时响应和跟进修复

对于威胁建模能力的构建，Parana公司建立了安全BP威胁评估培训与分层授权（Security Certifier Training）机制。简而言之，就是在每个业务研发团队中培养具备威胁建模分析能力的研发人员。通过绩效考核权重（提升安全能力在研发工作中的正向考核权重）、业务主管推荐（提升安全能力在业务考核中的负向考核权重）鼓励研发人员主动申请成为威胁建模分析专员，再举行定期的安全技术培训、考试及威胁建模实战演练选出合格的威胁建模分析专员进入专家池，且对专家池中的人员每年进行能力复核和刷新，后续主要依赖专家池中的人员对Red/Orange级别的应用进行威胁建模分析和评估。

二、开发阶段

Parana公司主要依赖零信任网关（midway-auth）和基于FIDO协议的硬件token的多因素认证（MFA）确保仅合法的内部研发人员可以接入到公司内的源代码开发平台；另外通过统一权限管理平台（Bindle）动态管理研发人员与所有artifacts的访问权限确保仅授权的人员可以访问指定的内部artifacts，主要包括：

• Permission Groups: 包含操作内部特定系统的权限组
• Codes: 源代码
• Package s: 包含多个代码文件的代码包
• VersionSets: 包含所需依赖关系的代码包集合，类似于docker镜像
• Environments: 包含微服务安装、配置、启动所需的所有信息的集合，类似于k8s的pods
• Hostclasses: 服务部署和运行的主机组，类似于k8s的nodes

公司通过内部 Code  Review平台强制要求研发的 每个commit在 push之前都需要人工进行Peer Review， 防止潜在恶意代码进入主干代码。为了实现开发的默认安全，降低已知安全风险，Parana公司花了很大力气提升开发阶段的公共安全能力：

• 公共安全组件：加解密模块、统一认证鉴权模块、凭据管理模块
• 默认安全的开发框架：内置了隐私敏感数据脱敏、凭据管理、常见漏洞默认防御能力的适配各种开发语言的应用开发框架
• 分层分级的数据仓库服务：满足不同分类分级数据安全要求的统一存储服务，可供开发团队按需选择，最大限度地降低因研发团队自行设计开发而导致的安全风险

公司禁止直接使用或者引用外部代码仓或者依赖库，使用前必须先引入内部代码仓，具体体现在以下几点：

• 遵循”谁引入、谁负责“的原则，确定内部owner
• 引入前需要确保符合公司开源软件许可政策
• 引入时同步三方依赖的名称、版本等信息至软件物料清单系统（SBOM）进行持续的漏洞监控
• 持续监控指定版本的三方依赖的漏洞信息，并 及时通知三方 依 赖 的内部owner更新升级

三、编译与测试阶段

Parana公司在代码 每次编译阶段都需要经过IAST/SAST/DAST的安全测试，重要应用代码上线前还需要经过专门的渗透测试。

• 使用自研和商用的SAST（静态应用安全测试）和DAST（动态应用安全测试）对自研代码进行安全扫描和测试
• 使用 安全组件分析（SCA）工具扫描代码中 依赖的所有三方开源组件识别已知漏洞使用流水线自动触发二方及三方依赖库版本升级、自动化测试
• 此外，根据 应用服务 安全 风 险 评估的等级 在上线前完成专门的应用服务渗透测试

四、发布与交付阶段

Par a na公 司的所有应用服务源代码最终都会被编译成 VersionSets（即包含了所需依赖关系的代码包集合，类似于docker镜像）进行发布并交付，所有过程都是由编译引擎（Brazil）自动完成的（无人工介入），从而确保了VersionSets的完整性。研发团队自身或者其他团队需要使用这个应用只需要在自己的流水 线上consume这个VersionSets即可[3]。以上这个过程，也可以使用持续交付平台（Pipelines）通过配置流水线自动化完成整个交付过程：代码push-》编译-》测试-》部署。

五、部署与运维阶段

Parana公司使用自动化部署平台[4]（Apollo）将 包含微服务安装、配置、启动所需的所有信息的集合的Environments自动化部署到应用服务运行的主机组Hostclasses上。

• 部署服务
• 无停机部署
• 健康追踪
• 版本化的artifacts和回滚

上述这些过程同样可以通过Pipelines实现自动化安全配置（Security Config）、工作负载（workload）加固与扫描、安全补丁与漏洞修复。

六、监控与反馈阶段

Parana公司通过默认安全的开发框架引导应用服务自身进行应用、性能等日志收集与异常监控，针对潜在的安全异常要求研发团队通过公共的数据收集与融合组件（Sushi）统一上报到安全运营中心处理，同时会持续对开发人员的角色及职责与被访问 代码仓关联度行为进行分析以识别潜在的软件供应链和内部威胁者（ Insider Threat ） 等风险。

实践与安全

导读：DevSecOps流程的各个阶段中也面临着一些常见的威胁类型，本节将重点讲讲Parana公司的应对策略和落地措施。

综上，我们较详细地解读了Parana公司是如何构建自己的DevSecOps体系，相信对于希望构建此类体系的企业来说有一定的借鉴意义。

参考：

[1] https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/

[2] https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html

[3] https://gist.github.com/terabyte/15a2d3d407285b8b5a0a7964dd6283b0

[4] https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html

[5] AWS re:Invent 2015: DevOps at Amazon: A Look at Our Tools and Processes (DVO202): https://www.youtube.com/watch?v=esEFaY0FDKc

[6] DevOps Culture at Amazon: https://www.youtube.com/watch?v=mBU3AJ3j1rg

[7] Automating safe, hands-off deployments: https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/