2023年全球DevSecOps现状报告

概述

关于Synopsys《2023年DevSecOps现状调查》报告

2023年初，Synopsys网络安全研究中心(CyRC)联合国际市场研究咨询公司Censuswide，对负责安全事务的 1,000名IT专业人士开展了一项调查。受访者包括开发人员、AppSec专业人员、DevOps工程师、CISO以及在技术、网络安全和应用/软件
开发领域担任各种职务的专家，受访者来自美国、英国、法国、芬兰、德国、中国、新加坡和日本。
所有的受访者都有资格参与调查，与其所属行业和公司规模无关。开发本次调查面临的挑战之一是“DevSecOps”一 词涵盖了多个学科，其中许多学科都有自己独特的角色。本次调查希望覆盖不同专业背景的人士，既包括“直接”编写代码的开发者，也包括从事软件安全相关工作的CISO级别的人员

关于DevOps和DevSecOps

加速开发、持续交付、管道弹性、可扩展性和端到端透明度是实现DevOps的关键原则。满足这些标准需要开发、安全和运维人员共同努力。

DevSecOps是DevOps方法论的延伸，旨在向多个团队灌输安全文化，并且尽早在DevOps环境中通过一致的方式来解决安全总是，通过将安全实践集成 到软件开发
生命周期（SDLC）和CI管道中，DevSecOps旨在将安全性从一个独立的阶段转变为开发生命周期的一部分。

DevSecOps在涉及软件开发的各个组织中都广受欢迎。SANS《2023年DevSecOps现状调查》显示，DevSecOps已 经成为一种重要的业务实践和风险管理方法。但在过去，当安全团队和开发团队试图把安全性纳入他们的流程时，经常会有不同意见，这很大程度上是因为这种

做法会把传统的应用安全测试(AST)工具引入软件开发生命周期(SDLC)。开发者经常抱怨AST工具太复杂、难以学习、性能低下以及产生大量“噪音”，这些都会给DevOps带来“摩擦”⸺ 也就是，那些在软件开发过程中阻止开发人员轻松快速构建代码的各种东西。大多数受访者表示，他们对自己使用的AST工具普遍感到不满。

自动化的好处

DevOps的核心原则是在SDLC的每个阶段都自动执行手动流程。对任何组织而言，自动化都是通过持续集成或持续部署来加速开发和交付代码的基本前提。
成功的DevSecOps需要集成和自动化的相互作用，以及标准和策略的指导。这样，既能让安全团队相信安全利益得到了保障，又能让DevOps团队保持工作状态，相信不会发生管道中断的情况。与手动测试不同，自动安全测试可以快速一致地执行，使开发人员能够在开发过程的早期阶段发现问题，不会影响到交付进度或工作效率。

• 一致性
  自动测试可确保对每一次的构建和部署一致地进行安全检查。手动测试可能会导致测试过程和覆盖范围不一致。
• 可扩展性
  随着软件复杂性的增长，手工测试将变得不切实际。自动测试容易扩展，以便跨越不同组件进行大量测试。
• 持续集成和持续部署(CI/CD)
  自动测试在CI/CD管道中至关重要，因为这些管道中会发生快速而频繁的代码变更。自动测试可以快速验证变更，防止错误代码进入生产环境。
• 持续改进
  自动测试提供数据和洞察，可以帮助开发和安全团队随时间的推移改进安全实践，允许他们系统地分析和处理漏洞模式。
• 记录
  自动测试可以记录整个测试过程，从而更容易跟踪和审计安全措施与合规要求。
• 减少人为错误
  由于疲劳或疏忽，手动测试容易出错。自动测试遵循预定义的脚本，能够降低人为错误的风险。
• 节省时间和成本
  在开发过程的后期或生产过程中识别和修复安全问题既耗时又昂贵。自动测试可将这些费用降至最低。
• 改进开发者体验
  自动的应用安全测试允许开发者采取主动的、全面的、有助于学习和提高安全知识和技能的方式来解决安全问题，从而增强开发者体验，最终提高软件安全性并提升整个开发过程的效率。

ASOC/ASPM在 DevSecOps中的应用日益增长

本报告对处于DevSecOps不同成熟阶段的组织进行了考察，包括他们的特征，以及他们采用的安全工具/实践。我们将根据调查结果为其提供指导性建议，帮助他们进一步提高软件安全的成熟度。
有趣的是，从调查结果中可以看出，应用安全编排与关联(ASOC) — 现在一般称为“应用安全态势管理”(ASPM) —的使用越来越普遍。根据Gartner的说法，对于使用多种开发和安全工具的任何组织而言，ASPM都应该是优先考虑的重要事项。

从开发到部署，ASPM解决方案能够持续管理各种应用风险，包括安全问题的检测、关联和优先级排序。ASPM工具可以从多个来源获取数据，然后关联并分析它们，以实现更轻松的解释、分类和补救。
ASPM还充当安全工具的管理和编排层，支持安全策略的控制与实施。ASPM拥有应用程序安全结果的综合视角，从而提供了整个应用程序或系统的安全与风险状态的完整视图。
鉴于这1,000名受访者中的大多数人都对其正在使用的AST工具普遍感到不满 — 抱怨这些工具无法根据业务需求确定修复的优先级 (35%)，也无法合并/关联数据来帮助解决问题(29%) — 因此，ASOC/ASPM的使用呈现快速增长趋势也在情理之中。

synopsys《2023年DevSecOps现状调查》的主要发现

大多数DevOps团队都在某种程度上采用了DevSecOps，共有91%的受访者表示，他们已将开展DevSecOps活动的某些安全措施纳入到了软件开发管道中。可以肯定地说，采用DevSecOps方法论现已成为软件开发的一部分。
拥有更成熟的安全计划的组织有专人负责安全事务29%的受访者表示，他们拥有跨职能部门的DevSecOps团队—由开发、安全和运维部门成员构成的协作团队，这是安全计划取得成功的重要因素。专注于安全、与开发人员/ 软件工程师和/或 QA 和测试合作的人员可能处于拥有成熟安全计划的组织中安全测试的第一线。

有效实施DevSecOps存在许多障碍

超过33%的受访者指出，缺乏安全培训是主要障碍。紧随其后的是安全人员短缺(31%)、开发/运维工作缺乏透明性(31%)以及优先事项的不断变化(30%)。

超过三分之一的受访者表示，将自动安全测试集成到构建/部署工作流中是安全计划取得成功的关键，其他的主要成功因素还包括通过基础架构即代码来执行安全/合规策略，在开发和运维团队中培养安全支持者(security champions)，以及加强开发、运维和安全团队之间的沟通等。

在SDLC后期处理重大漏洞，会极大地削弱收益

超过80%的受访者表示，2022-2023年间，已部署软件中的重大漏洞/安全问题以某种形式影响了他们的工作进度。
28%的受访者表示，他们的组织需要长达三周的时间来修补已部署应用程序中的重大安全风险/漏洞；另有20%的受访者表示，这可能需要一个月的时间
考虑到现在的漏洞利用速度比以往任何时候都要快，这些数字尤其令人感到不安。最新研究表明 超过一半的漏洞在披露后的一周内即被利用。

超过洞70%的受访陷者是表一示种，有通用过的自安动全扫措描施代，码来查的找受对代码进行安全漏洞和其他缺陷的自动化扫描，在“工具/流程的有用性”类别中排名第一，紧随其后的是“在SDLC的需求挖掘阶段明确安全需求”以及“通过BSIMM和SAMM等模型对软件安全计划进行正式评估”。

几不乎符所有的受访者都认为AST工具与其业务需求

在1,000名受访者中，大多数人都认为AST工具存在各种各样的问题是他们面临的主要挑战，包括这些工具无法根据业务需求对修复措施进行优先级排序(35%)，也无法合并/关联数据来帮助解决问题(29%)。
52%的安全专业人员已经开始在DevSecOps活动中积极合作AI，但超过四分之三的人担心AI的使用问题，
调查结果表明，安全团队正在积极使用AI、机器学习、自然语言处理和神经网络。然而，随着生成式AI工具（如AI驱动的编码建议）的使用日益增多，引发了围绕AI所生成代码的一系 列知识产权、版权和许可问题，某些情况下甚至引起了诉讼。

2023年DevSecOps现状调查

DevSecOps部署

在1,000名受访者中，超过三分之一的受访者认为其安全计 划已经达到了成熟度的第三级，即整个组织的安全流程都 是文档化的、可重复的和标准化的。另有25%的受访者认为 其安全计划已经达到了第四级，即安全流程也被记录，同时 还被监控和评估。
共有91%的受访者表示，他们已将某种类型的DevSecOps 活动应用到软件开发管道中，采用DevSecOps似乎已成为 DevOps的既定组成部分。

您认为贵组织当前的软件安全项目/计划的成熟度处于哪一级？

安全实践的实施代表更高级别的成熟度

DevSecOps成熟度的另一个衡量标准如图所示，表明受 访者已经采用了广泛的安全实践，从持续监控和评估(30%) 到自动测试(28%)。
作为被358名受访者(35.1%)提及的最佳实践，“安全风险管 理”涉及在开发过程中的每个阶段整合安全考虑因素，以识 别、评估和减轻与软件应用相关的潜在安全风险。在SDLC 的框架下，整体安全风险管理涵盖以下活动:

• 需求分析。在SDLC中尽早识别安全需求和限制，并定义安全目标。
• 设计。将安全原则纳入到系统架构和设计中，以确保应用 程序的设计包含针对常见漏洞的适当防护措施。
• 开发。实施安全编码实践，并遵守解决安全问题的编码 标准。使用集成的安全测试工具，如静态应用安全测试 (SAST)和软件组成分析(SCA)，在编写代码和引入开源 或第三方代码时捕获漏洞。
• 测试。执行各种类型的安全测试来识别应用程序中的漏 洞，如SAST、动态应用安全测试(DAST)、SCA和渗透测 试。
• 部署。安全地配置应用程序的运行环境。实施访问控制、 网络安全以及适当的身份验证和授权机制。
• 监控与评估。持续监控生产环境中的应用程序，以发现安 全事件和异常情况。实施日志记录和监控解决方案，以检
• 测和响应潜在的违规行为。30%的受访者表示，这是其组 织采用的主要安全实践。
• 响应和补救。制定事件响应计划，以快速有效地处理安全 事件。修复在测试阶段检测到的问题。
• 透明度和安全性。建立明确的规范、标准和策略，并报告 安全风险和风险容忍度。
• 培训。为开发团队提供安全编码实践、常见漏洞和最佳 安全实践方面的培训，以使开发人员能够主动解决安 全问题。遗憾的是，34%的受访者认为，“开发人员/工程 师的安全培训不足/无效”是导致其组织无法有效实施 DevSecOps的主要障碍之一。
• 持续改进。定期审查和改进SDLC中的安全流程和实践。

贵组织采用哪些安全实践?(选择所有的适用项)

评估安全计划

近70%的受访者表示，通过软件安全构建成熟度模型 (BSIMM)等评估工具来评估其安全计划是有用的，超过三 分之一的受访者认为此类评估“非常有用”。
对安全态势进行外部评估，有助于您分析软件安全计划，并 将其与其他组织和同行进行比较。BSIMM等工具能够提供 数据驱动的客观分析，可以帮助您在此基础上做出资源、时 间、预算和优先级决策。无论您是刚开始实施安全计划，还 是想让现有计划适应不断变化的业务和安全需求，与其他 软件安全计划进行比较都能为您的策略提供指导。
如果您正在负责软件安全计划或刚刚开始制定软件安全 计划，了解同行的AppSec趋势可以帮助您对自己的安全 工作做出战略性的改进。如果您从技术角度来管理安全 计划，可以借助BSIMM或软件保障成熟度模型(Software Assurance Maturity Model, SAMM)评估所获得的信息，为 人员和流程制定战术性的改进方案，例如制定安全支持者 (Security Champions)计划。

事实上，根据 BSIMM报告 许多软件安全团队首先要做的 事情之一就是找出那些在软件安全方面起到推动作用但与 软件安全团队没有直接联系的人员。这些人统称为“软件安 全支持者”，能够支持和推动软件安全工作。例如，工程团队 中的安全支持者可以鼓励工程师对自己的软件交付件的安全负责。33%的受访者认为，制定安全支持者计划是软件安全计划取得成功的关键因素之一。

通过BSIMM和SAMM等模型对软件安全性进 行正式评估的有效性.

跨职能团队对DevSecOps取得成功的重要性

29%的受访者指出，跨职能的DevSecOps团队 — 由开发、 安全和运维人员组成的协作团队 — 是安全计划取得成 功的关键(见附录Q16)。安全专业人员，与开发人员/软件 工程师及/或质量保证和测试团队协作(无论是正式加入 DevSecOps团队还是其他方式)，都可能成为安全测试的第 一道防线，助力组织打造更成熟的安全计划。
在部署前后仅由安全团队进行单一的流水线式测试已成为 过去式。在当今的软件开发环境中，安全测试是整个工程团 队的责任，包括质量保证、开发和运维团队，并且大多数团 队都会在软件开发生命周期的不同阶段将安全性构建到他 们的软件中。
33%的受访者表示，他们的组织也会聘请外部顾问进行安 全测试。这里的最佳实践是定期进行安全审计。委托第三方 审计人员或渗透测试人员开展此类测试，有助于客观了解 整个组织的安全态势，这是非常宝贵的。

贵组织由谁负责安全测试?(选择所有的适用项)

手动和自动测试相结合，以取得最佳结果

调查结果显示，大多数受访者认为，将手动和自动安全测试 相结合，可以提供一个更全面的方法来评估关键业务应用 的安全性。自动测试虽然对于保持一致性、可扩展性以及节 省时间和成本很重要，但人工参与可以增加一层洞察力和 适应性，这对识别复杂和微妙的安全问题是必不可少的。例 如，作为“黑盒”测试(即，在不了解应用内部结构的情况下 开展测试)，DAST就需要开发者和安全专家对测试结果进 行验证和分类。
同样，44%的受访者将外部渗透测试视为其安全测试的关 键组成部分，这一事实证明了渗透测试对内部测试起到重 要的补充作用。外部渗透测试通常是为了符合行业规范和 标准，能够带来额外的好处，例如提供有关贵组织安全态势 的客观评估，以及对外部攻击者可能利用的潜在威胁和漏洞的准确模拟。

您如何评估或测试关键业务应用的安全性?(选择所有的适用项)

关键绩效指标

本次调查要求受访者选择评估其DevSecOps计划成功与 否的前三个关键绩效指标(KPI)。首当其冲的是“公开漏 洞的总体减少”，被295名受访者提到(29%)，紧随其后的 是“SDLC后期发现的安全相关问题的减少”，被288名受访 者提到(28%)，排在第三位的“问题解决时间”，有281名受 访者提到了这一点(28%)。

正如调查结果所示，时间、生产率和成本是前面几个KPI的 三个共同点，也是组织在实现安全SDLC时面临的挑战。或 者，换句话说，DevSecOps参与者面临的三个主要问题是:

• 我们如何减少遇到的漏洞/问题的数量?
• 我们如何在SDLC中更早地发现漏洞?
• 我们如何缩短解决问题所需的时间，以减少构建延迟并 提高开发效率?

您用来评估DevSecOps活动成功与否的主要KPI是什么?(最多可选3项)

您正在使用哪些AST工具?它们有用吗?

调查结果显示，成功的DevSecOps策略使用完整的安全工具集来处理整个软件开发生命周期中的代码质量和安全问 题，包括动态应用安全测试(DAST)、交互式应用安全测试 (IAST)、静态应用安全测试(SAST)和软件组成分析(SCA)工具。
调查结果显示，SAST是最欢迎的AST工具，72%的受访 者认为它很有用。紧随其后的是IAST(69%)、SCA(68%)和 DAST(67%)。
SAST和DAST采用不同的测试方法，适用于不同的 SDLC 阶段。SAST对于在SDLC早期(即应用部署之前)发现和消 除专有代码中的漏洞至关重要。而DAST则适用于在部署之 后发现运行过程中出现的问题，如身份验证和网络配置缺 陷。IAST则结合了SAST和DAST的某些功能，适用于检测无 法被其他类型的测试识别到的重大安全缺陷。
SCA适用于识别和管理开源安全和许可风险，这是现代软 件开发中的一个关键需求，尤其是在任何给定应用中可能 都有超过四分之三的代码是开源代码的情况下。由于许多 组织都在使用从独立软件供应商处购买的打包软件，以及 物联网(IoT)设备和嵌入式固件，因此，他们可能还需要在 其AST工具箱中开展某种形式的SCA二进制分析。

贵组织使用的下列应用安全工具有用吗(如果有的话)?

何时进行测试？何时打补丁？这对我们的工作进度有何影响？

应用安全测试的频率取决于多个因素，包括应用程序的业 每天 务关键性、行业和威胁情况等。正如我们的调查结果所示，对于非常重要的应用程序，应定期进行评估(如图)。参与本次调查的大多数受访机构都表示，他们平均每周对业务关键型应用进行两到三天的漏洞扫描。
乍看之下，调查结果显示有28%的组织需要花费长达三周 的时间来修补重大漏洞(图I)，这可能令人担忧，但这要结 每周一次 合其他因素来考虑。有种误解，以为传说中的开发者能够修 复所有漏洞，但没有人会无端地要求开发者去深入研究那些不重要的漏洞。
值得注意的是，关于实施DevSecOps的主要障碍，31%的受 访者认为是“开发/运维工作缺乏透明性”，29%的受访者认为是“开发、运维和安全之间的组织孤岛”(如图)。这两项都表明了安全和开发团队之间的风险沟通问题，以及安全策略快速告警和自动化的需求。
在任何情况下，漏洞修补的优先级排序都要与待修补资产的业务重要性、关键性和资产被利用的风险相一致，尤其是 最后一点。研究表明，超过一半的漏洞在披露后一周内被利用。

贵组织平均多久对关键业务应用的安全性开展一次评估或测试

贵组织平均需要多长时间才能修补/处理已部署或正在使用的应用程序中的重大安全风险/漏洞？

鉴于此，组织需要根据通用漏洞评分系统(CVSS)的分数、 通用弱点枚举(CWE)信息以及漏洞可利用性等因素对漏洞 修复进行优先级排序，这一原则不仅适用于漏洞披露的“第 零天”，还适用于应用程序的整个生命周期。
CVSS分数是评估危险严重性的一个工业标准。国家漏洞 数据库(NVD)中的每个漏洞都有一个基本分数，可以帮助 计算漏洞的严重性，并为漏洞修复的优先级排序提供指 导。CVSS分数是在结合考虑漏洞可利用性和影响的基础上 给出的一个综合性基础分数。
时间分数考虑由于漏洞外部事件而随时间变化的指标。修 复水平(是否有官方的修复方案?)和报告置信度(报告是否 经过确认?)可以帮助将CVSS的总体分数调整到适当的风 险水平。
CWE信息列出了具有安全影响的软件或硬件缺陷。CWE告 诉开发人员哪些缺陷可以被利用(如果有可用的漏洞)。这 些信息可以帮助安全和开发团队了解开发人员安全培训的 重点，在SDLC和生产中实施哪些额外的安全控制，以及是 否需要添加风险严重性评估机制。例如，开发团队可能会根 据应用程序所接触的数据情况、部署位置以及其他环境和 安全因素，对SQL注入、缓冲区溢出或拒绝服务分配不同的 优先级。

漏洞的存在会提高风险分数，有助于工作团队优先安排修 复风险最高的漏洞。在评估了总体风险之后，还需要了解是 否有现成的补丁、缓解措施或补偿控制，这是您需要考虑的 另外一些关键信息。例如，如果您有两个中等风险但未被利 用的漏洞，那么，先修复哪一个漏洞最终可能取决于它们是 否存在现成的补丁或解决方案。
在已部署的应用程序中，重大的安全或漏洞问题往往会产 生连锁效应，不仅会影响组织(或其客户)的业务运营，还会 对整个SDLC造成影响，如图所示。
如果问题在开发早期就被发现，那么，这些问题可能只是小 问题，但如果是在部署后的应用程序中被发现，则这些问题 可能会演变成“全员参与”的重大问题。集成到IDE和CI管道 中的自动安全测试工具可以在代码提交后立即(甚至在提 交之前)识别出代码中的漏洞和缺陷，使开发人员能够在问 题传播到下游之前解决它们。

在过去的一年(2022-2023年)，解决一个重大 安全/漏洞问题对贵组织的软件交付计划产生了多 大的影响(如果有的话)?

有效DevSecOps面临的挑战

网络安全人才短缺是DevSecOps面临的一个重大挑战，如 图K所示，许多组织的关键网络安全岗位都无法招聘到合 格人员。一些研究显示，全球有350万个网络安全职位空 缺。随着市场对训练有素的网络安全专业人士的需求日益 增长，供应的稀缺将导致熟练从业人员的工资上涨，使许多 政府机构和中小企业无法负担。但是，正如图K所显示的那 样，“开发人员/工程师的安全培训不足”仍是排在首位的最大挑战。
经证实，建立安全支持者计划是解决这些问题行之有效的 策略，即从组织内部的各个部门挑选出对安全有着高于平 均水平的兴趣或技能的人员(这些人员已经开始利用自己 的专业知识为开发、质量保证和运维团队提供支持)。安全 支持者可以为新项目出谋划策和提供反馈，也可以在新兴 或快速变化的技术领域，帮助安全或工程团队将软件安全 技能与他们可能欠缺的领域知识相结合。敏捷教练(Agile coaches)、敏捷项目管理人员(scrum masters)和DevOps 工程师都是非常适合的安全支持者人选，特别是在发现和 消除流程中的摩擦方面。

贵组织实施DevSecOps的挑战/障碍是什么?(选择所有的适用项)

如本报告前面所述，SAST、DAST、IAST和SCA等AST工具 都已被受访者广泛使用，但将这些工具与业务需求有效挂 钩仍然是一个挑战。
许多受访者都抱怨说，他们使用的安全测试工具无法根据 安全漏洞的暴露程度、可利用性和严重程度等因素对修复 工作进行优先级排序;因为速度太慢而无法适应快速发布 周期/持续部署;不准确且不可靠。
由于无法整合或关联不同安全测试的结果，安全和DevOps 团队花费了太多时间来确定需要率先修复的漏洞 — 这可 能是近四分之三的受访者指出他们的组织需要两周到一个 月的时间来修补已知重大漏洞的原因之一。
不能迅速修补漏洞会影响到根本利益。超过80%的受访者 表示，2022-2023年间，处理已部署软件中的重大漏洞或相 关安全问题影响了他们的工作进度。

AST工具碎片化和修复速度缓慢正是应用安全编排与 关联(ASOC)和应用安全态势管理(ASPM)旨在解决的问 题。Gartner指出ASOC/ASPM可以作为管理层来编排多个 AST工具，自动对发现的问题进行关联和上下文分析，以加 快和优化修复过程。

ASOC/ASPM可以提取并整合多个来源的结果，就整个应 用环境提供统一风险视图，从而允许您基于业务背景(如严重程度)对修补工作进行数据驱动的优先级排序，以促进对 最高风险漏洞的更快修补。ASOC/ASPM还能提供生产环 境的可视化，从而解决已部署应用中漏洞修复时间过长的 问题，帮助有效避免漏洞利用(大多数的漏洞利用都发生在漏洞披露后的几天内)。

贵组织使用的应用安全测试工具的主要问题 是什么?(最多可选3项)

AI的承诺和陷阱

调查结果显示，AI的使用已经深入到许多组织的软件安全 计划中，超过50%的受访者表示，他们正在DevSecOps实践 中积极使用AI。54%的受访者希望通过AI来提高其安全措 施的效率和准确性。48%的受访者希望通过AI来帮助他们 减少对安全测试的人工审查。
考虑到AI可能为DevSecOps提供的主要优势，您会觉得这 是很有道理的。AppSec团队经常陷入两难的境地，一方面 需要进行完整和一致的安全测试，另一方面需要跟上使用 DevOps方法论和CI管道的开发团队的节奏。当截止日期紧 迫时，开发人员很容易跳过关键的安全风险评估过程。
本次调查的受访者表示，“提高安全措施的准确性和 效率”(54%)以及“降低安全数据的人工审查和分析需 求”(48%)是他们将AI引入安全SDLC的两个主要目的。
然而，请注意，受访者还表示，他们预计AI会“增加软件安全 的复杂性和技术要求”，也许有一天，唯一能对AI生成的代 码进行充分审查的实体只有AI自己。

在DevSecOps中实施AI还面临着额外的挑战，例如确保数 据质量以及解决安全和隐私问题。随着AI工具越来越多地 集成到DevOps管道中，它们几乎肯定会成为安全威胁的主要目标。处理用于训练AI的敏感数据也会引发隐私问题。
AI的使用会带来一些潜在风险，例如AI辅助编码可能会围绕着AI创建的代码产生所有权、版权和许可问题。
2022年底，GitHub、Microsoft和OpenAI遭到集体诉讼，指控GitHub Copilot —一款为开发者在编码时提供自动补全式建议的云端AI工具 — 侵犯了版权法和软件许可要求，并且训练Copilot服务所使用的开源代码也侵犯了开发者的权利。该诉讼还声称，Copilot建议的代码使用了有许可的 材料，但没有注明出处、版权声明或遵守原始许可条款。

基于大型语言模型的生成式AI聊天机器人，如ChatGPT和Google Bard，也存在随机产生“幻觉”的问题，即它们的回复虽然看起来可信和自信，但实际上是错误的 — 用通俗的说法，就是“说谎”。
AI幻觉显然会威胁到软件供应链安全。研究人员发 现，ChatGPT可能会为您推荐虚幻的、根本不存在的代码库 或软件包。恶意行为者可以创建具有相同名称的软件包，在 其中填充恶意代码，然后将其分发给听从AI建议的毫无戒 心的开发人员。这可能会对网络犯罪分子产生颠覆性的影 响，让他们能够避开更传统和容易被发现的技术，如拼写错 误或伪装。事实上，研究人员发现，根据 ChatGPT 的幻觉建 议创建的恶意软件包已经存在于 PyPI 和 npm 等流行的软 件包管理程序中。
这种威胁不是理论上的;而是真实存在的，正在发生的。无论供应链攻击是源自AI幻觉还是恶意行为者，要想对其进行防御，就必须了解代码来源、验证开发人员和维护人员的身份、并且只从可靠的供应商或来源下载软件包，这些都是至关重要的。

经验教训

虽然大多数组织在很大程度上采用了某些DevSecOps实 践，但在有效实施方面仍然面临挑战。本次调查显示，问题 主要集中在两个领域。
• 集成和调整多个应用安全测试(AST)工具的结果，使其与 业务优先级相一致
• 减少处理重大漏洞所需的时间
28%的受访者表示，他们的组织需要长达三周的时间来修 补已部署应用中的重大安全风险/漏洞。另有20%的受访者 表示，修补漏洞可能需要长达一个月的时间，但大多数漏洞 都会在披露后的几天内被利用。受访者表示，他们最不能忍 受的是AST工具无法根据业务需求对漏洞修补进行优先级 排序。
正如本报告在引言部分所述，编写调查问卷的挑战之一是 术语“DevSecOps”涵盖多个不同学科，其中许多学科都有 自己独特的角色。就“业务优先级”而言，不同的角色可能对 其有不同的理解。
例如，业务主管最希望了解AppSec工具的效力，他们希望 全面了解其流程及其能给整个团队带来怎样的绩效提升。 开发和运维团队希望AppSec能够帮助他们集中查看所有 问题，以确定最有价值的安全活动。安全专业人士则希望借 此来消除噪音，以便优先安排迅速处理重大问题。
对于那些在满足业务需求的同时，努力使各种孤立的安全 工具形成合力的组织来说，应用安全态势管理(ASPM)可以 提供必要的增强效果。ASPM可以自动协调孤立的工具、提 供上下文并确定优先级，以使组织能够专注于对业务最重 要的应用安全问题。
• ASPM可与开发和安全测试工具以及运维监控工具相集 成，以提供整合好的单一视图来展示组织中各方面的安 全相关信息。
• 通过关联和分组来自分析特定应用程序和漏洞的不同工 具的数据，ASPM 可以提供应用程序整体安全状况的全 面视图。DevSecOps团队可以生成与其角色和职责相关 的数据，而ASPM可以将这些数据以对业务线经理及其 他需要更广阔视角的人有意义的方式展现出来。
• ASPM允许您针对特定应用和漏洞可能带来的特定风 险制定并执行安全策略。当与开发或运维基础设施集成 时，ASPM还允许您尽早地发现并解决安全问题。
2021年的Gartner报告指出。大约有5%的受访组织采用 了ASPM或其前身 — 应用安全编排与关联(ASOC)工 具。Gartner预计其采用速度将会迅速提升，这一预测在 2023年的调查结果中得到了印证 — 28%的受访者已经开 始使用ASOC/ASPM。Gartner还指出，早期采用者往往是拥 有成熟的DevSecOps计划和使用多种安全工具的团队，这 些都是我们DevSecOps调查受访者的特征。

受访者特征

本报告探讨的调查有力地表明，安全工具提供的碎片化结果、不堪重负的工作团队和缓慢的漏洞修复速度是阻碍DevSecOps取得成功的根本挑战。对于那些拥有多元化 DevSecOps团队并使用多种应用安全测试工具的组织来说，ASPM可能是有效应对这些挑战的关键。

受访者行业分布