简单先阐述下瀑布式开发，敏捷式开发以及DevOps

瀑布式开发和敏捷式开发

瀑布式开发

基本流程是 需求 → 设计 → 开发 → 测试 ， 是一个更倾向于严格控制的管理模式 。 要求有明确的需求，大家按照需求一步步做好规划，每一阶段工作的完成是下一阶段工作开始的前提，每一阶段都要进行严格的评审，保证各阶段的工作做得足够好时才允许进入下一阶段。这种模式一般适用于需求比较明确、to B 端的项目。(传统制造业适用)

敏捷式开发

以用户需求进化为核心、迭代、循序渐进的开发方法。首先把 用户（客户 ）最关注的软件原型做出来，交付或上线，在实际场景中去 快速 修改弥补需求中的不足，再次发布版本。通过一些敏捷实践方式，细化story ，提供更小的迭代。如此循环，直到用户（客户）满意。适用于需求不明确、创新性或者需要抢占市场的项目。(大部分互联网产业适用)

瀑布式与敏捷式的一个比对

DevOps

还需介绍下DevSecOps前身DevOps。

DevOps主张在软件开发生命周期的所有步骤实现自动化和监控，缩短开发周期，增加部署频率。

一个软件从零开始到最终交付，大概包括以下几个阶段：产品规划、开发编码、构建、QA测试、发布、部署和维护。(《研发运营一体化（DevOps）能力成熟度模型》中标准分为敏捷开发管理、持续交付、技术运营、应用设计、安全风险管理和组织结构7个部分，涵盖了全软件的开发和运维生命周期)

最初大家说到DEVOPS，都是指的‘开发运维一体化’

现在大家说的 DevOps 已经是扩大到“端到端”的概念了，如下图：

DevOps 的三大支柱之中，即人（People）、流程（Process）和平台（Platform）。即

DevOps = 人 + 流程 + 平台

人 + 流程 = 文化

流程 + 平台 = 工具

平台 + 人 = 赋能

无论是瀑布式开发、敏捷开发还是DevOps，整个流程都分为设计、开发、测试和部署四个部分，只不过各个部分的开始和结束时间节点不同而已。

DevSecOps

而我们的DevSecOps模型，主要就是在DevOps上增加了安全的概念。

相对于 DevOps 而言，DevSecOps 增加了安全要求，可以帮助企业在软件研发阶段便关注信息安全，从而解决大部分安全隐患。但 DevSecOps 并非简单地增加安全要求。通常来说，效率与安全是存在冲突的，重视安全便可能降低效率。DevSecOps 的目标是在不影响效率的前提下提升软件系统安全性，使两者能够相得益彰。首先，DevSecOps在明确业务系统安全需求的前提下，制定贯穿软件系统全生命周期的实践方案，通过在软件开发的不同阶段将安全工具或安全活动进行整合，将各个信息安全孤岛进行串联，协同作战，实现安全开发、安全测试、安全部署和安全运营的统一融合，在提升软件系统研发过程标准化与自动化的同时，降低对效率的影响，也降 低安全的成本。

另外，DevSecOps 的实践，也对企业、研发人员、安全人员和运维人员有着重要的意义。对于企业整体，实践DevSecOps，可以帮助企业保持良好的合规记录，避免安全事件导致的资产损失；对于研发人员，实践DevSecOps，可以在一开始就开展安全的软件开发，减少返工、降低成本，并提升效率；对于安全运维人员，实践 DevSecOps，可以提升软件质量，降低安全事故，减少低价值的重复任务。

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

DevSecOps主要分为10个阶段，分别是计划（Plan）、创建（Create）、验证（Verify）、预发布（Preprod）、发布（Release）、预防（Prevent）、检测（Detect）、 响应（Respond）、预测（Predict）、适应（Adapt），其中预防（Prevent）在之前的版本里也有叫做配置（Configure）。

计划（Plan）

计划阶段是DevSecOps的第一个阶段，其包含了SDL模型里培训、需求、设计等几个阶段，主要关注的是开发前的安全动作。根据Gartner官方工具链模型可以看出其主要是包含有偿还技术安全债务、安全开发衡量指标、威胁建模、安全工具培训。 技术债务指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。那么对应的技术安全债务就是相关技术架构中一些考虑不完善的点而潜藏的安全风险，一般就是在安全设计或者需求阶段没有进行相关的 安全设计和评估而导致，在后续的安全工作里都是需要认识其风险并且给出安全解决方案逐渐偿还。举个例子，比如在一些项目的开发过程中为了快 速实现功能，选用了一些不安全的框架，那么在后续的维护过程中可能会不断受其安全问题影响而需要不断的进行修复，比如说struts2，那么安全团 队应该给出方案，比如说禁用替换该组件。

安全开发衡量指标为需要制定对应的安全开发的衡量指标，以便于评估安全开发模型实施的效果，比如漏洞发现率，统计上线前后漏洞的发现情况， 来评估安全开发流程是否有效在安全开发过程中有效收敛安全漏洞。

威胁建模是在需求和设计阶段识别和消减安全威胁的一种手段，如SDL里微软提出的“STRIDE”，基于数据流图去识别不同环节是否存在仿冒、篡改、 抵赖、信息泄露、拒绝服务、权限提升几个维度的安全威胁，并制定对应的消减措施，落实并验证。这里还有个概念是轻量的威胁建模，相对比“STRIDE” 这种传统意义上比较复杂的威胁建模过程，轻量的威胁建模通常通过安全checklist等方式进行简单快速的实现设计、需求阶段的安全风险识别并处置，一般也容易落地与实行，并且也能取得一定的效果，而不至于让这个安全动作名存实亡。

安全工具培训则就是字面的意思，由于DevSecOps相对比SDL等更强调自动化，所以相关安全动作通常由安全工具实现，同时安全动作不再只是安全团队执行，所以也要针对开发等同学进行安全工具使用的培训，以便于帮助其在不同阶段使用安全工具进行检查。

当然，除了DevSecOps工具链所标记的四点，其实在计划阶段，类似安全编码规范、安全编码培训、安全流程的学习、安全需求定义、制定和发布标准化 安全功能等需求、设计阶段实际安全动作都可以归入这个阶段，并不存在明显的冲突或者矛盾。

有关SDL叙述文章可以参考 https://xz.aliyun.com/t/11922

创建（Create）

创建阶段主要就是指编码阶段。编码阶段主要进行安全编码及检查，旨在在编码阶段进行安全风险的消除。主要包含参考安全编码规范进行安全编码，通过IDE安全插件进行源代码的安全检测，也可以进行安全编码规范的自动化检查，如是否使用不安全或禁用的函数等；甚至是检查代码中是否引用使用了不安全或不合规的第三方组件。

验证（Verify）

验证阶段其实就是测试阶段，主要以自动化的应用安全测试（AST，Application Security Testing）和 软件成分分析（SCA，Software Composition Analysis）为主。 应用安全测试主要分为动态应用安全测试（DAST）、静态应用安全测试（SAST）、交互式应用安全测试（IAST,）。

DAST 是一种黑盒测试方式，是 在应用测试或运行环境模拟黑客构造特定的恶意请求从而分析确认应用是否存在安全漏洞的一种方式，也是过去最常用的一种应用测试方式，比如我们常见的 APPSCAN、AWVS、W3AF 等 Web 漏洞扫描器就是属于这种类型。

而 SAST 是针对源代码的一种分析测试方式（部分工具也会依赖 于编译过程甚至编译后文件进行分析测试），常见的 Coverity、Fortify Static Code Analyzer、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 等。

预发布（Preprod）

预发布阶段一般是测试阶段及正式发布阶段的中间阶段，其与测试阶段不同的是预发布阶段所发布的预发布环境是连接的正式环境的数据库等，其等同于独立部署的非对外公开的正式环境。在DevSecOps工具链中预发布阶段主要包含有混沌工程（Chaos Engineering）、模糊测试（Fuzzing）、集成测试三个安全动作。

混沌工程，是一种提高技术架构弹性能力的复杂技术手段，以实验发现系统性弱点，简单的解释就是通过主动制造故障，测试系统在各种压力下的行为，识别并修复故障问题，避免造成严重后果。

模糊测试是将自动或半自动生成的随机数据输入到一个程序中，并监视程序异常，如崩溃，断言（assertion）失败，以发现可能的程序错误，比如内存泄漏等。跟SAST、DAST、IAST等不同的是，AST是基于已知经验发现安全问题，模糊测试捕捉的是未知的安全问题。

集成测试是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。

其中混沌工程和集成测试都是软件及测试工程中一些专用的动作，这里映射到安全动作的话更多是通过这些工程方法实现一些安全测试的目的。

同时在预发布阶段，除了以上三种动作，其实类似主机安全测试、容器镜像检查等都可以是在预发布执行的安全动作。在实际执行和落地过程，通常也会有一些安全动作比较难以清晰的划分是在验证或者预发布阶段进行，两个阶段在一些特殊场景下可能会出现互相融合的情况。

发布（Release）

针对发布阶段，在DevSecOps的流程中主要动作是软件签名，与预防阶段结合来看，主要是软件防篡改。

预防（Prevent）

预防阶段在过去版本的DevSecOps模型中也被叫为配置（Configure）阶段，在最新的模型中被调整为预防（Prevent），从调整也可以看得出，该阶段理论和实践性还有待进一步发展和细化。

该阶段主要包含有签名验证、完整性检查和纵深防御。

其中签名验证是呼应发布阶段的软件签名，以及进行完整性检查，两者都是保障软件的一致性，避免传输等过程软件被篡改、替换等情况。

而纵深防御（Defence-in-Depth, DiD）其核心思想简单来说就是层层防御。采用分层的机制，通过层层的安全防护和监控手段而非指望单一的安全手段来建立安全防御体系，纵深防御的目标是确保每层都知道如何在可疑的攻击事件中采取行动，限制恶意或意外破坏的机会，并最大限度地提高快速 识别任何安全漏洞的机会。

检测（Detect）

从预防阶段，就已经从开发切换到运维阶段，而检测阶段则更符合传统安全中相关的安全监控动作，该阶段主要包含有RASP、UEBA、网络流量监控、 渗透测试几个安全动作。

RASP(Runtime Application Self-Protection，应用运行时自我保护)，Gartner在2014年引入RASP这个概念。RSAP将自身注入到应用程序中，与应用程序融为一体，实时监测、阻断攻击，使程序自身拥有自保护的能力。RASP的注入方式类似于某些IAST，但其更强调的是安全防护和阻断能力，国内比较 出名的有百度的OpenRASP。

UEBA（User and Entity Behavior Analytics，用户行为分析）其也是Gartner提出并的一个安全名称，说白了就是通过行为分析来识别恶意行为，一般在讲述这个概念的时候会提及用户画像、机器学习等自动化学习、分析和预测能力。

网络流量监控其实是类似于UEBA的一个东西，其核心是通过对流量进行监控分析，识别其中恶意的流程，即一些攻击行为等。

而渗透测试通常就是指通过人工等方式进行软件或者系统的测试仪发现攻击者可以利用的攻击途径或者安全问题。引申的话其实还涉及到红蓝对抗，在渗透测试的基础上更强调攻击方与防御方的对抗过程，以此验证整体安全防御体系及相应机制等。

其实除了以上4个安全动作，在运维阶段可以进行的安全检测或者监控远不止如此，过去在安全落地过程通常通过相关安全监控来进行补偿性的安全问题发现，一般就是位于该阶段，如高危端口开放检测、系统漏洞扫描等。

而渗透测试通常就是指通过人工等方式进行软件或者系统的测试仪发现攻击者可以利用的攻击途径或者安全问题。引申的话其实还涉及到红蓝对抗，在渗透测试的基础上更强调攻击方与防御方的对抗过程，以此验证整体安全防御体系及相应机制等。

其实除了以上4个安全动作，在运维阶段可以进行的安全检测或者监控远不止如此，过去在安全落地过程通常通过相关安全监控来进行补偿性的安全问题发现，一般就是位于该阶段，如高危端口开放检测、系统漏洞扫描等。

响应（Respond）

在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）三种技术/工具的 融合，目的是快速准确的响应和预测安全事件。

预测（Predict）

预测阶段主要涉及漏洞相关性分析与威胁情报。

漏洞相关性分析（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 来传输交换情报。

适应（Adapt）

适应阶段主要强调了安全技术债务、修改应急响应方案、安全防御方案等几个点。其实这个阶段也可以称作优化阶段，主要是基于DevSecOps实施的整个流程的情况，进行持续的适配改进和项目调整优化，对应到过去安全动作，可以理解为持续运营反馈调整的过程，包含对相关安全问题的持续跟踪、闭环，对DevSecOps过程中相关安全动作如策略的调整等。

实践

对上述几个部分应该进行的安全活动和需要采取的安全措施及方法进行了重点分析，并进一步给出了安全运营实践中各项能力的建设方法

DevSecOps 理念是将安全能力内建到研发运营工具中，形成 DevSecOps研发运营安全工具链

DevSecOps所涉及的各个工具链，应与企业的DevOps 平台进行整合。DevOps本身就包含了复杂的多种多样的工具，如果再加上安全 工具，无疑会增加工作复杂性，使得研发运维和安全人员无从下手，进而导致 DevSecOps 无法真正落地。因此，完善的DevSecOps方案不是提供单个工具，而是提供统一平台，打通所需的各种安全工具或产品，并在其中内置最佳实践。

完善的DevSecOps平台，有助于降低入门成本，以高效的方式解决软件研发流程中的安全问题。

风险发现能力建设

安全风险发现能力建设贯穿业务创建到业务交付的全过程，在DevSecOps工具链的创建、验证、预发布、发布这四个阶段，通过使用一系列技术手段，在建设初期发现安全问题，实现安全“左移”， 确保 DevSecOps 团队开发的产品和服务符合安全最佳实践、法律法 规和行业标准要求，并实现安全合规性。

（1）在创建阶段，通过制定安全编码规范及流程，采用相关的安全插件，在本阶段尽可能的消除安全风险；

（2）在验证阶段，通过一系列安全测试工具，比如：DAST、 IAST、SAST、SCA 等，检测漏洞，提高风险发现能力；

（3）在预发布和发布阶段，通过模糊测试和软件签名等方式开 展相应的安全活动。

安全防御能力建设

安全防御能力建设主要集中在工具链的预防阶段和检测阶段，过这两个阶段的相应工具作用，可以达到有效防范不正当的数据访问和操作行为，降低安全风险，确保在发生网络与信息安全事件后 能够及时止损，保障业务系统安全和稳定运行，最大程度的降低安 全事件带来的影响。

（1）在预防阶段，通过开展签名验证和完整性检查来保证应用 及其部署环境的安全性，为检测阶段的开展奠定基础；

（2）在检测阶段，需要在运行时采用应用程序自保护（RASP）、网络流量监控、资产安全监控等方式保护业务安全。

安全运营能力建设

安全运营能力建设是指在遵循安全风险规范的基础上，从内部运营角度出发，覆盖漏洞预警、安全培训、安全流程建设、安全规范建设等内容，搭建内部运营体系；从外部运营角度出发，通过运营 安全应急响应中心、威胁情报平台建设，搭建外部运营安全体系。内外联动完善安全运营体系，提高安全运营能力，实现整体安全水平的飞跃。

（1）在计划阶段，可以从安全培训、威胁建模、制定安全开发衡量指标这几个方面入手，为安全活动的开展奠定基础；

（2）在响应阶段，可以开展安全编排、RASP/WAF 阻断等活动；

（3）在预测阶段，可以通过漏洞相关分析、威胁情报等手段，提高安全预测能力；

（4）在优化阶段，可以从消除技术安全债务、优化应急响应方案入手，提升安全活动的整体水平。

落地实施困难

组织挑战

（1）组织文化难以改变

组织文化是 DevSecOps 在落地实践推进的过程中所面临的一大挑战，如何处理团队之间的沟通协作问题是 DevSecOps 成功的关键因素。在企业实际的工作中，团队间协作相关的冲突屡见不鲜，主要协作问题之一是开发团队和安全团队之间的冲突。比如开发团队认为安全团队成员会不客观地判断和批评他们所做的工作；开发人员对失去开发工作的自主权感到不满等。组织中存在部门间孤岛式的工作文化是实践 DevSecOps 的障碍，这些孤岛阻碍了业务相关者之间频繁和有效的沟通与协作。

另外由于企业不重视安全导致的工作人员的安全意识不足，也阻碍着安全工作的开展。在采用 DevSecOps 时，需要进行许多文化和行为上的改变。在人员安全意识没有完成转变的情况下，就会出现项目成员的意识与DevSecOps的要求不匹配的情况。

（2）人员缺乏相应技能

DevSecOps 提倡开发人员参与安全保障过程，并承担相应职责。然而，由于开发人员缺乏相应的安全技能与知识阻碍了这一目标的实现。所以，缺乏安全教育和培训的开发人员并不知道该如何实现高安全性的软件，即便他们有意愿加强软件的安全性也无能为力。 与此同时，安全人员由于缺乏开发经验也更进一步增强了开发人员与安全人员之间的冲突。

流程挑战

（1）敏捷性与安全性之间难以平衡

由于 DevSecOps 同时包含了灵活性、复杂性和依赖性，因此要同时实现安全性和敏捷性就成为了一个难题，在很多场景下，安全性和敏捷性之间会表现出不兼容性。DevOps 的关键目标之一是释放速度，但许多安全测试过程不可避免地会消耗一定的时间，特别是那些需要人工输入和确认的环节。例如，早期的自动化渗透测试工具虽然可以快速完成渗透测试过程，但同时还需要人工配置和评估输出。因此在 DevSecOps 落地实践的过程中，使用精简高效、主次分明的 DevSecOps 实践方案更容易获得成功。

（2）缺乏标准化的流程和度量标准

在 DevSecOps 体系下，除去 DevOps 所包含的持续集成、持续部署、持续运营之外，持续安全评估也是不可或缺的实践内容。然而，持续安全评估过程并没有行业权威或标准化的实践方案，组织通常需要亲自设计一套适合于自身的流程，对于如何将安全措施内嵌在 DevOps 管道中，目前缺乏行业标准和共识。由于DevSecOps并没有行业标准的方案，因此组织中只能按照自己的经验，自主设定安全度量指标，其科学性难以评估和验证。（可以与SAMM，BSIMM模型进行参考对比，衡量指标）对安全度量指标看法的分歧，也进一步地加深了安全团队和开发团队之间的矛盾。

技术挑战

（1）传统应用安全工具无法适应新流程

组织在考虑进行DevSecOps实践之前，通常已经进行过应用安全工具的使用，但传统的应用安全工具往往无法适应以敏捷性、流程化为特点的 DevSecOps 体系，传统的安全工具需要经过进一步的优化改造，才能融入到DevSecOps体系中，适应新的流程。

（2）部分安全过程还需要人工的介入

在 DevSecOps 中，由于需要快速和连续的发布，自动化起着重要的作用。为了实现这一目标，DevOps 包含了一组连续的实践，如持续集成、持续交付、持续运营，它们在很大程度上是自动化的。然而，安全实践的自动化有其自身的困难，因为它们中的许多过程，在传统上是需要手动执行的。目前难以完全实现自动化的安全保证 过程包括而不止于：安全隐私设计、安全需求分析、威胁建模和渗透测试等。

维度挑战

（1）团队融合引入新的风险

开发团队、安全团队和运营团队的融合协作，导致风险管理更加的复杂。例如与传统体系相比，开发人员在 DevSecOps 体系中的角色发生了变化，现在他们可以获得部分生产环境的信息和权限。更多的人接触生产环境意味着更大的风险。开发人员可以通过访问用于控制环境的生产设置或治理工具来对生产环境造成影响。因此随着 DevSecOps 中角色的变化和团队的融合，内部威胁所导致的风险会相应增加。

（2）流程打通导致攻击面扩大

与人员融合造成风险提升类似的是，技术与工具通过流程进行的融合，也会导致攻击面的扩大。例如，CD（持续交付）阶段的一个关键安全问题是 CD 管道本身的安全漏洞。CD 管道的大部分技术组件在具有多个开放式 API 的环境中运行，由于其开放性，这些组件容易受到各种恶意攻击。因此理论上，CD管道扩大了额外的攻击面。另外，很多组织中，大多数项目团队成员都可以访问 CD 管道配置，但由于缺乏安全知识和意识，这些成员也对基础设施和应用程序构成了威胁。

reference

2020 DevSecOps 企业实践白皮书 https://www.freebuf.com/articles/243414.html

什么是DevOps？ https://www.zhihu.com/question/58702398/answer/1755254160

CU-DevSecOps 实践白皮书