Datadog 的 DevSecOps 2026 报告验证了我们一直在构建的内容

Datadog 的《2026 年 DevSecOps 现状》报告证实了 StepSecurity 多年来一直在警告的问题：CI/CD 流水线和工作流已成为供应链攻击的首要目标。了解 StepSecurity 平台如何直接应对报告中识别的每一项主要风险，从未固定版本的 Actions 到发布当天即引入的依赖项。

点击放大

数据已经证实，这验证了 StepSecurity 多年来一直在发出的警告。​

Datadog 刚刚发布了《2026 年 DevSecOps 现状》报告，分析了数万款应用程序及其供应链依赖项。调查结果证实了我们通过真实事件响应一直在记录的现实：CI/CD 流水线和软件供应链的保护仍然严重不足，即使攻击者越来越多地将矛头指向这些环节。

我们受邀为该报告贡献我们的观点，我们的联合创始人 Ashish Kurmi 毫不客气地指出：

"GitHub Actions 工作流通常处理生产凭证、生成发布版本，并在高度特权上下文中执行第三方代码，但大多数组织并未像对待生产基础设施那样对其进行同等严格的安全保护。2025 年发生的主要 GitHub Actions 入侵事件清楚地表明，攻击者正在系统性地针对这一安全缺口。组织需要采用第一性原则的方法来保障 CI/CD 安全：了解每个工作流的爆炸半径、监控运行时行为，并将构建基础设施视为高价值资产。这种基础性思维使我们对 tj-actions、Shai-Hulud 和 s1ngularity 等攻击做到了早期检测，这也是整个行业需要在 2026 年广泛采用的理念。"

— Ashish Kurmi，​联合创始人，StepSecurity

该报告列出了 DevSecOps 现状的五个关键事实。每一个都对应 StepSecurity 平台专门设计来缓解的风险。以下是具体对应关系。

事实 1：87% 的组织在已部署的服务中存在已知可利用的漏洞

风险：​ Datadog 发现，87% 的组织至少有一个可利用的漏洞，影响了 40% 的全部服务。Java 服务以 59% 居首，其次是 .NET 的 47% 和 Rust 的 40%。一个关键驱动因素是过时的语言和运行时版本：10% 的服务运行在至少一个已终止支持（EOL）版本上，而这些服务中 50% 存在可利用的漏洞，相比之下使用无 EOL 版本时这一比例为 37%。

StepSecurity 如何缓解此风险：​ 可利用的漏洞不仅存在于生产代码中。它们通过被篡改的依赖项、过时的库和不安全的构建流程进入软件供应链。StepSecurity 的 Harden-Runner 为 GitHub Actions 工作流提供运行时安全保护，监控每次 CI/CD 运行期间的网络流量、文件系统活动和进程行为。如果被篡改的依赖项在构建过程中试图窃取数据或发出未经授权的网络调用，Harden-Runner 能够检测到并（在启用 egress-policy: block 的情况下）阻止它。

这意味着即使易受攻击或被篡改的库进入了依赖树，StepSecurity 也能在最关键的环节——构建和部署流水线期间——捕获恶意行为，防止其进入生产环境。

让我们通过这个交互式演示来了解 Harden-Runner 的工作原理：​

Dev Machine Guard 将供应链保护扩展到开发人员机器，风险往往在代码进入流水线之前就已经在开发人员机器上产生。通过 本地 npm 监控，安全团队可以全面了解组织内每个开发人员工作站上安装的软件包，从而在易受攻击的代码进入代码库或流水线之前，快速识别被篡改的依赖项。

事实 2：依赖项比最新主要版本落后 278 天

风险：​ 中位依赖项现在比其最新主要版本落后 278 天，较去年的 215 天有所增加。Java 是最严重的"落后者"，达 492 天，其次是 Ruby 的 357 天。Datadog 的研究还表明，较旧的库携带的漏洞明显更多：2023 年发布的库平均每个服务有 3.8 个漏洞，而 2025 年发布的库则为 1.3 个。部署频率低于每月一次的服务的依赖项比每天部署的服务过时程度高出 70%。

StepSecurity 如何缓解此风险：​ 过时的依赖项就像一颗定时炸弹，而团队落后的部分原因是他们缺乏对依赖树中实际内容的可见性，以及更新是否安全。StepSecurity 从供应链角度解决这个问题：

• NPM Package Compromised Updates 作为 GitHub Check 在每个 Pull Request 上运行，确保依赖项更新不会引入已知被篡改的软件包。StepSecurity 维护着一个被篡改软件包的内部数据库，并实时更新，通常在官方 CVE 发布之前。这样团队就可以更有信心地更频繁地进行更新，因为恶意版本将被自动捕获。

  点击放大

• NPM Package Search 允许安全团队在整个组织中搜索特定软件包是通过哪些 Pull Request 引入的。当在旧版库中发现漏洞时，这使得能够快速识别每个受影响的代码库，以便团队在最关键的地方优先进行更新。Dev Machine Guard 也在此发挥作用。它的 NPM Package Search 功能不仅限于代码库和 Pull Request，还包括开发人员机器，让安全团队能够识别整个组织中特定软件包的存在位置：在 PR 中、在默认分支上、以及在本地工作站上。当发现过时依赖项包含漏洞时，这种全面可见性确保在修复过程中不会遗漏任何实例。

  点击放大

• Artifact Monitor 为您发布的自有制品提供持续合规监控，验证每个版本都关联到可信的 CI/CD 发布流程。这确保您内部的软件包不会为您自己的团队或下游消费者成为供应链风险的来源。

  点击放大

通过消除更新可能引入被篡改软件包的恐惧，StepSecurity 有助于打破 Datadog 数据所揭示的依赖项管理疏漏循环。

事实 3：50% 的组织在发布当天就使用库

风险：​ 虽然事实 2 表明组织更新过于缓慢，但事实 3 揭示了另一个极端：50% 的组织在第三方库发布后一天内就使用它，12% 使用公共 AMI 镜像，32% 使用发布不到一天的公共 Docker 镜像。这正是 Shai-Hulud 和 s1ngularity 等供应链攻击造成损害的确切窗口。Datadog 指出，在过去一年中，使用 npm 的组织中有 1.6% 使用过至少一个恶意依赖项，代表着可能有数万个组织执行了恶意代码。

StepSecurity 如何缓解此风险：​ 这正是我们的制品安全套件和 GitHub Checks 设计用来防止的问题：

• NPM Package Cooldown 是一个 GitHub Check，自动阻止任何引入在可配置等待期（默认：2 天）内发布的依赖项的 Pull Request。如果 PR 试图添加昨天发布的软件包，检查将自动失败，一旦冷却期到期则自动通过。无需人工干预。Datadog 建议一周的冷却期；StepSecurity 允许您配置这以匹配您组织的风险承受能力。由于大多数供应链攻击在最初 24 小时内被发现，即使默认的 2 天冷却期也能消除绝大部分风险。

• NPM Package Compromised Updates 提供第二层防御，阻止任何已知恶意的依赖项。在 Shai-Hulud 攻击期间，此功能自动标记试图拉取被篡改版本的 Pull Request，并阻止它们合并，完全保护客户免受攻击。

• Threat Center 作为跟踪开源生态系统活跃供应链妥协事件的集中枢纽。当 Shai-Hulud 等事件发生时，安全团队可以在 StepSecurity 仪表板内调查详情并直接应用修复步骤，而无需在多个来源之间奔波。

  点击放大

• Harden-Runner 在运行时提供最后一道防线。即使恶意软件包以某种方式进入工作流，Harden-Runner 也能检测到异常行为（意外的网络调用、未授权的文件访问、凭证窃取尝试）并可实时阻止。在 Shai-Hulud 攻击期间，Harden-Runner 在发布后几分钟内就标记了恶意行为，远早于广泛利用开始之前。

• Dev Machine Guard 将这些保护扩展到开发人员工作站。​本地 npm 软件包监控 跟踪组织内开发人员机器上安装的每个软件包，无论是由人还是由 AI 编码代理安装，使安全团队在检测到被篡改软件包（如 Shai-Hulud 活动中专门针对开发人员机器的那些）时能够全面了解暴露情况。Dev Machine Guard 的 NPM Package Search 还扩展到包括开发人员机器，让安全团队识别整个组织中特定软件包的存在位置（在 PR 中、在默认分支上、以及在本地工作站上），以便在事件期间进行完整的爆炸半径评估。

这些功能共同创建了分层防御：冷却期防止过早采用，被篡改软件包检查阻止已知威胁，运行时监控捕获任何漏网之鱼。

事实 4：GitHub Actions 容易受到供应链攻击

风险：​ 使用 GitHub Actions 的每个组织都至少使用一个市场 Actions，但只有 4% 为所有市场 Actions 固定了哈希值。令人震惊的是，​71% 从不为任何 Actions 固定哈希值。更糟的是，80% 的组织使用至少一个不由 GitHub 管理的第三方市场 Actions 且未固定到提交哈希，2% 正在运行之前已被篡改的 Actions 而未进行哈希固定。tj-actions/changed-files 篡改事件 正好展示了这种做法可能造成的灾难性后果：攻击者注入了一个恶意有效载荷，导致受影响代码库的 secrets 被写入工作流日志。

StepSecurity 如何缓解此风险：​ GitHub Actions 安全自成立以来一直是我们的核心关注点，针对这个确切问题我们提供了业内最全面的解决方案：

• Orchestrate Security 自动将 GitHub Actions 和容器镜像固定到整个组织代码库中的完整长度提交 SHA。这正是 Datadog 和 GitHub 推荐的唯一防止自动更新到可能被篡改的 Action 版本的缓解措施。StepSecurity 将 71% 的组织目前手动失败完成的工作自动化。

• StepSecurity Maintained Actions 更进一步，提供经安全审查的热门第三方 Actions 精选替代品。每个维护的 Action 在加入之前都经过严格的手动安全代码审查，使用严格访问控制且无持久凭证，并默认启用标签保护。这直接解决了导致 tj-actions 和 reviewdog 妥协事件的访问控制失败问题。企业客户可以请求加入特定 Actions，StepSecurity 监控上游变更，并在修补漏洞时有明确的 SLA。

  点击放大

• GitHub Checks 包括用于 PWN Request 检测的专用控制（捕获可以被恶意分叉 PR 利用的不安全 pull_request_target 配置）和 脚本注入 扫描（标记使用未清理外部输入的工作流）。这些检查捕获攻击者利用以获取初始访问权限的工作流级漏洞。

• Workflow Run Policies 为锁定哪些 Actions 可以在您的环境中执行提供关键运行时控制。​Allowed Actions Policy 允许您定义已批准 GitHub Actions 的允许列表，确保只有经过审查的 Actions 可以在整个组织中运行。​Compromised Actions Policy 自动检测工作流何时尝试使用已知被篡改的 Action，并在执行前取消运行。对于 Datadog 发现仍在运行被篡改 Actions（未固定）的 2% 组织，这些策略将立即阻止这些 Actions 执行。

让我们通过这个交互式演示来了解 Compromised Actions Policy 的工作原理：​

自动固定、维护 Actions、工作流检查和运行时监控的组合意味着 StepSecurity 涵盖了 GitHub Actions 安全的完整生命周期：预防、检测和响应。

事实 5：大多数漏洞不应该打扰人工处理

风险：​ Datadog 发现，在使用运行时上下文和 CVE 上下文调整严重性评分后，只有 18% 的关键依赖项漏洞仍保持关键级别。这意味着超过 80% 的"关键"警报实际上是噪音。该报告还强调，98% 的 .NET 依赖项漏洞从关键级别下调，而 49% 的 PHP 漏洞保持关键级别。将每个漏洞都过度优先处理会造成警报疲劳，分散对真实威胁的关注，并浪费开发者时间。

StepSecurity 如何缓解此风险：​ 警报疲劳是一个真实存在的问题，当安全工具产生没有上下文的噪音时会加剧。StepSecurity 的方法围绕可操作的情报而非警报数量构建：

• Harden-Runner 专注于在运行时检测实际恶意行为，而不是标记每个理论上的漏洞。当依赖项发起意外的网络调用或试图访问不应访问的文件时，这是需要关注的高信号警报。这种运行时上下文正是 Datadog 描述的减少误报的关键。
• NPM Package Compromised Updates 仅阻止已确认被篡改的依赖项，而不是每个有 CVE 的依赖项。StepSecurity 的内部威胁情报数据库经过准确性审核，这意味着当检查失败时，是因为存在真实的、已确认的威胁，而非理论上的威胁。
• Threat Center 提供关于活跃供应链妥协事件的精选情报，让安全团队清楚地了解哪些是在野外实际被利用的，哪些仅是被评分的漏洞。这帮助团队将有限的时间集中在构成真正业务风险的威胁上。
• Workflow Run Policies 允许组织在整个 GitHub Actions 工作流中定义和执行安全策略，确保一致的安全标准，而无需手动审查每次工作流运行。
• Dev Machine Guard 通过 IDE Extension Governance 从开发人员机器端减少噪音，该功能跟踪 VSCode 和 Cursor 上所有已安装的扩展，并提供全面的风险评分。安全团队可以实施已批准扩展列表和新版本自动冷却期，主动过滤掉有风险的扩展，而非在事件发生后才做出反应。这与 NX Build System 篡改事件 等攻击直接相关，该攻击中一个 VSCode 扩展在激活时静默运行恶意代码。Dev Machine Guard 不是在每个扩展更新时发出警报，而是允许您执行策略并将注意力集中在真正有风险的更改上。

通过关注已确认的威胁和实际恶意行为而非原始 CVSS 评分，StepSecurity 帮助安全团队排除干扰，响应真正重要的问题。

为什么现在比以往任何时候都更重要

DevSecOps 格局正在快速发展。像 GitHub Copilot、Claude Code 和 Gemini CLI 这样的 AI 编码代理正在加速开发速度，这意味着 CI/CD 流水线比以往任何时候都运行得更频繁、处理更敏感的操作、并集成更多第三方代码。Datadog 在本报告中识别的每一项风险都因这种加速而放大。

正如 Ashish 所指出的，使我们对 2025 年主要妥协事件进行早期检测的基础性思维（了解爆炸半径、监控运行时行为、将 CI/CD 视为关键基础设施）正是组织在 AI 辅助开发时代扩展所需的方法。

这正是我们构建 StepSecurity 的核心理念。Harden-Runner 现已被超过 10,000 个代码库信任，包括来自 Microsoft、Google 和 Kubernetes 的项目，提供运行时安全基础。结合我们的 GitHub Checks、Artifact Security 套件、Orchestrate Security 和 Maintained Actions，我们提供业内最全面的平台来保护 CI/CD 流水线，抵御 Datadog 报告中识别的每一类风险。

开始使用

Datadog 报告中的每项风险在 StepSecurity 平台中都有对应的缓解措施。以下是从哪里开始：

1. 使用 Orchestrate Security 将所有 GitHub Actions 固定到提交 SHA，或采用 StepSecurity Maintained Actions 用于关键工作流。
2. 通过 GitHub Checks 启用 NPM Package Cooldown 以阻止发布当天的依赖项风险。
3. 将 NPM Package Compromised Updates 激活为必需检查，在已知恶意软件包进入代码库之前阻止它们。
4. 添加 Harden-Runner 到您的工作流以实现运行时监控和出口控制。
5. 使用 NPM Package Search 和 Threat Center 监控您的爆炸半径。

我们一直在为这一刻做准备。数据现已证实了我们的判断。