应用安全状况报告：当开发速度超越安全成熟度 2026

应用安全状态报告 当发展速度超过安全成熟度时 ©2026 ORCA SECURITY. 所有权利保留。 应用安全已发生根本性变化，但许多程序仍像什么都没发生一样运行。软件构建于开源依赖、自动化流水线和基础设施即代码之上，而人工智能正同时扩大其规模和风险。然而，安全团队却期望用过时的方法来管理这种复杂性。 在真实的生产环境中，风险是可见的，但在缺乏上下文的情况下，很少能采取行动。人工智能正在加速开发并扩大攻击面，从生成的代码到模型依赖，这使得优先级变得至关重要。本报告帮助组织了解传统方法存在哪些不足，以及如何专注于那些能实质性降低风险的变化。 2026 应用安全报告 本报告内 5.182021CI/CD流水线安全5.1 采用CI/CD平台5.2 GitHub Actions 安全性 6. 基础设施即代码安全 22 6.1 基础设施即代码平台采用 246.2 存储与数据保护 25 1.供应链攻击的兴起 051.1 主要的供应链攻击 07 2.人工智能包中的漏洞 082.1 严重远程代码执行漏洞 10 7. 代码库与版本控制安全管理 29 7.1 代码审查与批准差距 317.2 分支保护弱点 32 3.容器漏洞态势 123.1 高/关键漏洞补丁更新速度 14 8. 主要建议 34 8.1 立即行动（0-30天） 358.2 中期举措（30-90天） 36 4.1 The AI/ML Secrets Crisis174.15密钥管理 2026 应用安全报告 前言 随着组织通过云原生架构、开源依赖项和自动化管道加速软件交付，应用程序攻击面正以安全实践无法跟上的速度扩张。AI辅助开发进一步加剧了这种速度，其生成代码、依赖项和配置的速率，是传统安全流程所无法管控的。 现代应用程序由数千个第三方组件构建，并以机器速度部署。这种速度带来了规模和创新能力，但也使得代码一旦进入生产环境就难以修复所有问题。易受攻击的依赖项、暴露的机密信息以及不安全的配置已不再是边缘情况；它们是当今软件构建方式的结构性现实。与此同时，人工智能系统带来了新的风险，并使得不安全代码模式和模型依赖能够在不同环境中快速传播。 这些挑战因软件供应链攻击的兴起而加剧，后者已被证明是导致大规模安全事件的最有效途径之一。单个被污染的依赖项或工作流可能波及数千家组织，将应用程序安全失败转化为运营风险。 本应用安全状况报告旨在帮助团队了解这些风险是如何被引入的，以及如何有效应对。该报告基于Orca研究小组的现实发现，为当今企业所需速度下保障现代应用安全提供了清晰的现状视图和实用指导。 吉尔·格罗诺 奥克拉安全公司的首席执行官兼联合创始人 2026 应用安全报告 关于虎鲸研究舱 奥拉卡研究小组是一群安全研究员，他们发现和分析安全风险与漏洞，以强化奥拉卡安全平台并推广CNAPP安全最佳实践。 研究方法 本报告基于来自超过1000家采用Orca Security云安全平台的、经过聚合和匿名化的安全遥测数据。 所有呈现的指标均代表表现出每种发现的组织百分比，该百分比是通过对各组织进行加权平均计算得出的。数据收集时间介于2025年第三季度至2026年第一季度，专注于生产环境，以确保发现能够反映现实世界的安全态势，而非测试或开发配置。 安全发现涵盖多个领域：CI/CD流水线安全、密钥管理、仓库配置、软件成分分析（SCA）、静态应用安全测试（SAST）、基础设施即代码（IaC）以及容器安全。 报告数据集： ● 云工作负载和配置数据● 数以亿计的真实世界生产云资产● 本报告引用的数据收集时间范围为2025年第三季度至2026年第一季度● 亚马逊云科技（AWS）、微软Azure、谷歌云、甲骨文云和阿里云环境 执行摘要 利用超过1000个生产组织的真实世界遥测数据，本报告考察了现代软件交付生命周期中应用安全现状。调查结果揭示，当今应用程序的构建方式与应用安全实践之间存在日益扩大的脱节，导致持续存在的风险、修复工作停滞以及生产环境中的暴露面不断扩大。我们的主要调查结果摘要包括： 应用风险普遍存在，并常规性地波及生产。 CI/CD流水和基施即代默情况下都在大。74%的组织通过代码部署基础设施，配置错误已不再是孤立的失误，而是可重复的生产风险。超过80%的IaC环境缺乏适当的日志记录和监控，84%部署了未加密的存储，将安全漏洞直接嵌入到交付流水线中。 超过78%的组织的应用程序在运行时存在严重漏洞。即使在披露多年后，像Log4Shell这样具有高影响的问题仍然影响着近半数的生产环境，这凸显了传统应用安全方法难以跟上依赖关系的蔓延。 秘密泄露依然普遍存在，而人工智能的采用正在加剧其影响。近三分之一的组织在代码中暴露了有效的、活动的秘密，而超过41%的组织泄露了人工智能/机器学习凭证。这些泄露为直接访问专有模型、敏感数据和基于使用的服务提供了途径，从而增加了安全和财务风险。 供应链攻击如今已成为常规的生产风险。 超过11%的组织在生产环境中使用了臭名昭著的恶意软件包，其中包括多年前公开披露并已移除的依赖项。像2025年Shai-Hulud蠕虫这样的自我复制攻击，就证明了单个受感染的依赖项如何级联影响数千个下游环境。 检测并不等同于采取补救措施 尽管识别出了漏洞，但很少得到解决。90天后，仍有超过77%的组织存在高或关键性的容器漏洞，这表明当团队无法有效优先处理风险时，漏洞就不会得到修复。 关键发现 随着人工智能的采用加速，泄露的模型和API凭证带来了新的风险，包括未经授权的访问、数据泄露以及意外的财务影响。 仍有组织的生产环境依赖受Log4Shell影响的组件而存在漏洞。 一些组织通过代码来管理基础设施。 软件供应链攻击已不再是边缘案例，恶意依赖在公开披露并从注册表中移除后仍持续传播。 公开披露后数年仍持续存在的高影响漏洞，显示了传递性依赖是多么根深蒂固且难以修复。 供应链攻击的兴起 18,000+ 供应链攻击的兴起 软件供应链攻击已从边缘威胁转变为大规模沦陷最可靠的途径之一。通过攻击共享依赖项、构建系统和自动化工作流，攻击者可以从一次入侵中实现指数级影响。 下游组织 2020年的SolarWinds入侵标志着一个转折点，它展示了攻陷一个构建管道如何能让攻击者获得对18000多家下游组织的访问权限，其中包括《财富》500强企业和政府机构。自那以后，攻击者越来越关注软件包仓库、CI/CD平台和维护者凭证，这些地方通常隐含信任关系，且验证往往有限。 2025年，随着自复制供应链恶意软件的出现，这一演变进程加速。Shai-Hulud行动引入了一种新型攻击，该攻击通过从受感染环境收集npm令牌和GitHub凭证实现自主传播。仅Shai-Hulud 2.0就攻陷了超过796个npm包，这些包每周下载量超过2000万，导致487家组织中的14000个敏感信息泄露。 这些攻击凸显了一个新现实：现代软件的安全程度取决于其依赖的最薄弱的依赖项、维护者账户或自动化工作流。 供应链攻击的兴起 主要供应链攻击 软件供应链攻击已从孤立事件演变为大规模入侵的最有效途径之一。在过去五年中，随着攻击者利用共享依赖项、构建系统和自动化工作流所产生的乘数效应，其复杂性和影响急剧增加。 2020年的SolarWinds入侵事件是一个转折点，它表明一个被攻破的构建管道可能使攻击者获得对超过18,000个下游组织的访问权限，其中包括政府机构和《财富》500强公司。自那以后，攻击者越来越针对包管理仓库、CI/CD平台和维护者凭证，因为这些领域往往隐含着信任关系，且安全控制通常是最薄弱的环节。 这种升级在2025年因自复制的供应链恶意软件的出现而加速。像Shai-Hulud这样的活动引入了能够通过从受感染环境收集npm令牌和GitHub凭证来自主传播的攻击。仅Shai-Hulud 2.0就攻陷了超过796个npm软件包，这些软件包每周下载量超过2000万，导致487个组织中的14000个秘密信息泄露。这标志着一种向持久化、可扩展运营的转变，这些运营利用信任来武器化整个软件生态系统。 02 依赖与脆弱性管理 依赖关系和脆弱性管理 现代应用程序建立在多层第三方代码之上，其中大部分都带有已知风险。开源依赖项加速了开发，但也引入了难以在复杂的依赖项树中进行追踪、优先处理和修复的漏洞。我们的研究表明，易受攻击的软件包并非孤立发现，而是在生产环境中普遍存在。 超过78%的组织的应用程序正在运行存在严重漏洞。随着依赖关系的蔓延加剧，传统的应用安全方法——这些方法依赖于基于严重性的警报——难以区分理论风险和在生产环境中构成实际风险的问题。 结果，团队意识到了越来越多的漏洞，但由于缺乏必要的背景信息，他们无法自信且高效地处理这些漏洞，导致漏洞积压越来越多。 2.1 严重远程代码执行漏洞 Log4j Additional RCE (CVE-2021-45046) 某些漏洞因其严重性和易被利用性而需要立即关注，然而许多漏洞却未能得到修复。 Log4Shell (CVE-2021-44228) 在 Log4Shell 漏洞披露近四年后，它仍影响着 46% 的组织，这凸显了现代应用安全（AppSec）领域的一项更广泛挑战：即使漏洞被广泛公开且补丁可用，修复工作仍可能停滞不前。与此同时，像 React2Shell（CVE-2025-55182）这样的新型远程代码执行（RCE）漏洞正在迅速扩大现代应用框架的攻击面——该漏洞影响 29% 的组织，并适用于所有默认使用 React Server Components 的 React 19 和 Next.js 15/16 应用。 Apache Commons Text RCE (CVE-2022-42889) Spring4Shell (CVE-2022-22965) React/Next.js RCE (CVE-2025-55182) Apache Struts RCE (CVE-2024-53677) 综合来看，这些发现表明，仅凭严重程度不足以推动有效的修复。缺乏验证、优先级排序和生产环境背景，即使是最关键的安全漏洞也依然悬而未决，因为团队难以收集到所需的洞察力，以判断哪些风险真正可被利用并需要立即采取行动。 n8n Workflow RCE (CVE-2025-68613) 2.2 恶意软件包：仍在生产环境中潜伏 尽管已进行公开披露并从软件包注册表中移除，但确认的恶意软件包仍在生产环境中持续存在，有些甚至可追溯到2018年。生产环境中单个恶意软件包的存在可能导致凭证窃取、数据泄露或完整系统被攻破。这使得即使是有限的暴露也构成了重大的组织风险。我们的分析表明，各组织仍在运行已知的供应链威胁，这暴露了依赖管理及修复实践中的持续漏洞。 值得注意的是，所识别的最普遍威胁均源自同一受信任的维护者，这进一步表明，现代供应链攻击并非总是来自未知的外部行为者。在许多情况下，威胁是通过应用程序生态系统中已嵌入的受信任依赖项引入的。 容器 x 漏洞态势 容器漏洞态势 容器是现代应用交付的基础组件，但许多生产镜像建立在过时且易受攻击的基础层之上。我们的研究表明，关键漏洞深深嵌入了常用容器软件包中。 超过60%的组织在其核心系统包（如tar占61%，glibc占55%）中运行容器，存在关键漏洞。这些组件位于容器镜像的基础，并在应用程序中继承，这意味着一个有漏洞的基础镜像可能会在整个环境中传播风险。 外派人员-2.1.0（关键漏洞） 43%的组织仍在使用受Heartbleed及其他高危漏洞影响的OpenSSL 1.0.1f版本容器，这反映出基础镜像未定期更新的普遍现象。这使得知名的高严重性漏洞得以在生产环境中持续存在。 高/关键漏洞修补速度 未修复的时间 尽管容器漏洞已被广泛检测，但修复工作仍进展缓慢且不一致。我们的研究发现，90天后仍有77%的组织存