100+企业调研 | 洞察云原生安全趋势，详解DevSecOps建设-轻识

随着云原生技术和应用程序组件的不断发展，安全团队需要通过优化安全技术和组织流程，以降低安全风险。我们调研了100+不同云原生安全成熟度的企业，发现了一些云原生安全的主要趋势以及成功的安全实践，输出了《2022云原生安全白皮书》，详细内容可扫描图片二维码查看。

四大洞察显示云原生安全发展趋势

通过调研100+云原生应用组织的安全建设情况，我们总结了这些组织安全建设的主要趋势。

洞察1：云原生安全管理方式

集中的、自上而下的安全采购和管理模式

利用管理平台整合安全工具统一管理策略
安全管理与DevOps流程集成

图1不同云原生安全管理方式的比例

洞察2：不同安全成熟度组织的特点

更高安全成熟的组织能够更有效地修补漏洞：超过75%的组织会在全生命周期过程中扫描代码，对漏洞的响应速度提高了28%。
随着组织安全成熟度越高，开发人员越认可安全的价值：安全成熟度高的组织的开发团队认为安全团队是业务推动者的概率比其他的组织要高出4.2倍。
安全成熟度与高效运营正相关：安全成熟度较高的组织认为他们的安全能力对应用程序的可靠性、可见性和安全性有显著的积极影响。
安全成熟度越高的组织遭受的安全事件更少：通过调研发现，2021年安全成熟度较高的组织遭受的安全事件减少了31%。
安全成熟度会影响产品的功能和准时交付：安全成熟度较高的组织对按时交付安全代码的信心增加了4.3倍。
安全成熟度高的组织业务收入明显超过预期目标：高成熟度阶段的组织相比于低成熟度阶段的组织增加业务收入的可能性高出55%。

洞察3：组织应用云原生技术所面临的主要安全风险

利用已知软件漏洞进行攻击
利用0Day漏洞进行攻击
利用配置错误的云服务、工作负载或特权账户进行攻击
由第三方进行的未经授权的访问
恶意软件包括勒索软件和加密软件，它们可以横向移动到云工作负载中
有针对性地渗透攻击
由于API的不安全使用而导致数据丢失的攻击
滥用特权账户或通过被盗的凭证进行访问
对象存储中显示的公开数据

洞察4：组织使用安全供应商和安全工具的数量

在调研中发现各组织在将应用扩展到云环境时，还整合了他们的云原生安全供应商。如图2所示，2021年使用1到5个安全供应商的组织数量增加了27%，使用6到10个安全供应商的组织数量与2020年相比下降了19%。

图2 组织合作安全供应商数量的变化

组织减少了安全供应商的数量，同时也对利用的安全工具做了简化。近四分之三的组织使用10个或更少的安全工具，这表明组织希望通过更少的安全供应商，获得更广泛的安全功能。因为依赖多个供应商的不同工具可能会出现安全盲点增加风险。

两大属性实现成功的云原生安全建设

为了得出成功应用云原生技术组织的安全建设特点，我们通过两个安全属性来比较不同组织的安全特点：

安全态势：指组织如何评价其云原生安全工作的有效性。
安全摩擦：指组织认为云原生安全支持或限制其业务的程度。

如图3所示，为了衡量云原生安全态势，我们通过6个调查问题，调研了各组织的安全人员，受访者对这些问题的认可度越高，表明该组织的安全工作越有效。如图4所示，调查发现55%的组织安全能力较弱，比如在获得多云可见性、跨应用的统一安全管理或者简化事件响应流程等方面需要优化。

图3 影响安全态势的因素

图4 不同安全态势组织的百分比

如何在整个云原生系统中建立强大的安全态势？通过调研成功的云原生安全建设组织，整理了《101文档：全生命周期云原生安全关键指标》，详细内容扫描图片二维码查看。

如图5所示，为了分析云原生安全方面的摩擦，我们通过对2个问题进行调研，受访者越强烈地同意这些观点，表明该组织的安全摩擦越高。如图6所示，通过调研发现只有48%的组织认为他们的安全摩擦很低。

图5导致组织安全摩擦的因素

图6 具有高、中、低摩擦的组织的百分比

结合这两个指标，可以发现实现低安全摩擦对于提高组织安全态势至关重要。组织通过优化安全工具和流程进行安全建设的同时，要尽可能减少对业务的影响。强大的安全能力，不但可以提高运营效率，而且具有高安全态势和低摩擦的组织可以提高生产力和员工满意度。如图7所示，调研发现超过80%的安全摩擦水平较低的组织报告员工满意度显著提高。

图7 整体安全态势对组织的积极影响

两大要素助力组织实现强大安全态势

通过调研发现，提高组织安全态势减少安全摩擦主要有两个核心因素：

DevSecOps集成——将云原生安全能力集成到从构建到运行时的整个开发生命周期中。
安全自动化——云原生安全自动化的程度可以有效提高组织的安全能力降低安全摩擦。

组织实施DevSecOps方法并实现安全自动化是提高安全态势的主要因素。将DevSecOps原则紧密集成到开发生命周期中的组织，拥有更强大的安全态势和更低的安全摩擦。如图8、9所示，我们总结了有助于提高DevSecOps集成度和自动化程度的一些因素。

图8 影响DevSecOps集成度量的因素

图9 提高云原生安全自动化的因素

七大原则实现DevSecOps自动化安全建设

DevSecOps是组织云原生安全建设的重要部分，它是由开发、运营和安全人员组成的联合团队，使组织在一个确定的范围内快速地向市场交付安全的应用。复杂的、动态的云原生项目需要这种方式的协作，但大多数组织仍然很难有效地实施DevSecOps模式。问题是，DevSecOps不仅仅是一种技术转变，也是一种文化变革。组织实施DevSecOps主要存在以下安全挑战：

难以评估安全风险：在复杂的云原生环境中每天会发生大量的安全告警，如果不能很好地评估风险进行优先级排序，并实现风险闭环管理，大多数安全风险告警就会被简单地忽略了。

缺乏开发过程的风险解决能力：大多数安全工具主要针对运行时，这时风险已经暴露出来。如果能在开发过程中解决发现的安全风险，会更容易而且影响更小。

自动化程度低减缓开发速度：假设DevOps团队在检测到问题时有修复问题的能力，但如果依赖人工检查和手动修复问题，这不仅效率极低，而且减缓了开发速度。

高效、成功的DevSecOps模式中开发人员能够在开发过程中独立通过可靠、简单的方式修复漏洞解决安全风险，通过改进团队内部的协作，从而使整个组织实现技术和文化的全面变革，带来业务和安全的双重提升。想要成功地实施DevSecOps，组织需要在文化上和技术上重新思考如何安全地构建、部署和运行应用程序，主要遵循以下七个原则。

原则一：利用IaC实现可重复性和文档化

随着云原生环境的规模和复杂性的增长，组织非常需要一些工具来实现快速、统一的部署。同时，需要从开发到运行整个生命周期中保护基础设施安全。一方面，基础设施即代码(IaC)允许在被测试、应用和审计的基础上对环境进行更改，从而提高敏捷性和安全性。另一方面，它还提供了可重复性和文档化的重要好处。随着部署环境的增多，每个环境都有自己独特的特性和标准。IaC通过对基础设施进行持续地版本控制和审查，从而更容易理解基础设施如何以及为什么会发生变化。

通过IaC不仅可以帮助DevOps团队快速、大规模地实现业务目标，还可以将安全更早地集成到整个生命周期中。通过这两个因素使组织更容易实现不可变的基础设施，在这种状态下，基础设施在部署后永远不会被修改。不可变的基础设施实践进一步提高了云原生环境的安全性和合规性。

原则二：通过IaC尽早开始安全管理

调查显示，67%的数据泄露问题是由于云配置错误导致的。这可能是因为没有及早地修复问题或因为安全团队和开发团队沟通不及时。解决这两个问题就需要将安全尽早地集成到DevOps流程中。

通过威胁建模可以主动识别威胁，并建立针对这些威胁的安全控制。威胁模型可以通过分析IaC来构建，以确定需要定义哪些资源、如何配置它们以及它们之间的关系。通过IaC提供的上下文，可以更好地了解生产环境中的漏洞路径，以及它的风险等级。通过使用IaC，在部署流程之前就开始风险检测，尽早开始风险管理。

威胁建模有助于尽早识别风险，而策略即代码(PaC)提供了一种为这些威胁建立安全控制的方法。PaC可以集成到基础架构开发过程中，从而在整个生命周期中检测和减轻安全和操作问题。将PaC集成到构建管道中可以检测违规操作和风险，从而防止将问题引入运行时环境中。在运行时，PaC可以检测违规操作并强制执行策略，从而实现安全。将PaC工具集成到开发过程中，实现自动执行管道中的安全策略，帮助团队在部署之前发现并修复违规行为。

原则三：部署前扫描IaC发现策略违规行为

除了IaC的操作优势之外，它还能够在开发的早期发现错误配置和策略违规，并向开发人员提供实时反馈。在开发人员向存储库中提交代码时不断扫描IaC，可以及早发现并修复违规行为，而且不会阻碍开发过程。在开发过程中嵌入安全性，并在基础设施的整个生命周期中强制执行安全性。这种模式被称为不可变安全，它可以通过以下三个方式来实现：

在提供云基础设施之前降低风险来保护IaC。
检测可能引入风险的新资源和配置更改，确保运行时的云基础设施安全。
将IaC建立的基线同步应用于运行时，从而消除风险漂移。

原则四：部署前扫描应用程序/容器代码以发现漏洞

容器应用增加了镜像、应用程序和基础设施的攻击面，为安全漏洞提供了更多可利用的机会。扫描将在基础设施内部运行的代码非常重要。SAST、DAST和IAST都用于应用程序安全测试，并且它们各有优缺点。SAST（静态应用程序安全测试）可以在应用程序开发时发现漏洞，但可能有很高的假阳性。DAST（动态应用程序安全测试）可以检测正在运行的应用程序中的漏洞，但不能识别它们在代码中的确切位置。IAST（交互式应用程序安全测试）提供了DAST和SAST都提供的许多好处，但缺点是它需要特定的语言支持。

原则五：为违规行为创建自动拉取请求

开发人员并不是安全专家，需要提供工具帮助他们在不阻碍业务流程的情况下解决风险。当发现错误配置时，应该通知开发人员这个问题，并提供通过拉取请求或合并请求来修复这个问题的代码。例如代码修复(RaC)等技术可以自动完成修复，并将它们直接提交给违规代码所在的存储库。开发人员审查建议，并将更改合并到正常工作流的代码中。这样做，问题就得到解决，使得建立IaC作为安全基线，并部署基础设施，这些流程都不会出现问题。

通过代码修复（RaC）不仅可以解决问题，它也能极大地改善安全状况。在发现错误配置的时候，可以自动修复云基础设施，在不影响开发速度的情况下快速有效地解决问题。

原则六：在部署期间执行安全策略

在处理复杂的动态系统时，关键问题是很难在开发的早期预测在部署过程中可能会遇到的风险。许多组织在开发后期进行安全审查，但如果出现问题，通常手动流程很难修复这些问题。使得部署过程产生安全摩擦。

因此，组织需要在部署前识别漏洞和违规操作，通过自动修复技术（RaC）简单快速修复问题，确保部署阶段的安全性。部署过程通常使用artifacts和IaC部署到运行时环境中，可以建立PaC控件来验证artifacts和IaC在部署过程本身是否兼容。

原则七：在运行时执行安全策略

云基础设施的配置更改会在运行时发生，原因有很多，而且频率非常高。事实上，超过90%的组织都会有这种情况发生。为了提高安全性，需要在运行时阶段执行与开发和部署阶段相同的安全策略。理想情况下，这种强制执行将防止不符合策略的配置更改。

持续监控运行时环境中的配置漂移，并自动将运行时更改重新回传给IaC，使团队能够保持统一性，这有助于避免部署过程中的摩擦，因为开发人员不需要担心覆盖重要的运行时配置。同时在运行时检测到不符合要求的更改，也可以立即从IaC重新部署，以消除有风险的更改。

本文是青藤调研100多家云原生应用企业的安全建设情况，总结的云原生安全发展趋势以及成功的云原生安全建设的实践经验。青藤作为国内最早一批研究云原生安全的厂商，推出自主研发的青藤蜂巢·云原生安全平台，并成功在国央企、金融、运营商、互联网等行业企业落地实践，安全能力获得客户的高度认可。

鉴于不同阶段对容器安全防护的要求不同，且国家对容器安全的重视程度不断增强。如果您想试用容器安全产品，可以点击“阅读原文”进行免费申请。