How AI Is Changing Patching and What Devs Need to Know About Exposure Management

AI如何改变补丁管理以及开发人员需要了解的暴露管理

2026年9月4日

/

#人工智能

Reetain Raina

当漏洞扫描器报告您的应用程序存在23个漏洞，其中4个为严重漏洞、7个为高风险漏洞、其余12个为中等风险漏洞时，乍看之下答案似乎很明确：开始修复漏洞。但您应该优先修复哪一个？

这一直是漏洞管理中的难题。虽然安全团队可能会发现存在漏洞的依赖项，但修复它并不总是可以立即完成。开发人员需要确保存在漏洞的代码确实在使用中，并在将修复版本发布到生产环境之前完成所有必要的检查。

不过，最近在利用人工智能发现软件漏洞和攻击方法方面取得了一些实质性进展。例如，这项研究详细说明了部分发现成果以及未来的发展方向。

但这些进展对开发人员社区究竟有何帮助？我们确实需要更快地解决问题，但更重要的是，我们需要判断哪些漏洞真正重要，哪些漏洞需要优先处理。

在本文中，我们将探讨传统补丁管理流程的典型模式，人工智能如何缩短安全团队的响应时间，以及为什么仅根据漏洞严重性评分来处理漏洞并不总是合理的。

我们还将讨论暴露管理与传统漏洞管理之间的差异，并介绍开发人员如何分析依赖项、代码可达性以及软件物料清单（SBOM）来识别应用程序中的实际漏洞。

本文内容：

• 补丁管理与暴露管理：有何不同？什么是补丁管理？什么是暴露管理？

• 旧版补丁管理流程围绕时间构建

• 人工智能正在缩短“发现”与“被利用”之间的时间差距

• 为什么“修复所有漏洞”在大规模场景下行不通

• 暴露管理：从漏洞数量转向上下文风险

• 依赖树作为攻击面

• 开发人员的实用建议：审计传递依赖项、检查代码可达性、在CI/CD中生成SBOM、在补丁未就绪时使用补偿控制、在运行时应用最小权限原则

• 总结

补丁管理与暴露管理：有何不同？

在探讨人工智能如何改变漏洞响应机制之前，先理解两个重要概念——补丁管理和暴露管理——将有助于我们更好地理解后续内容。

什么是补丁管理？

补丁管理是通过更新软件来解决现有问题（包括安全漏洞、错误或稳定性问题）的过程。这可能涉及升级已知存在漏洞的库、为操作系统应用安全更新，或使用修复了漏洞的新版本应用程序。

例如，如果您的应用程序使用了某个已知存在安全漏洞的库，一旦修复版本可用，就可以升级该库。升级后，需要测试更新内容，确保应用程序仍能按预期运行，并将升级后的版本发布到生产环境。

因此，修补不仅仅是安装相关软件包的最新版本。依赖项的更新可能会破坏API、某些功能，甚至影响其他依赖包。正因如此，团队在识别漏洞、更新决策、测试、部署以及验证补丁有效性时，通常会采用修补管理策略。

什么是暴露管理？

虽然漏洞管理主要关注识别漏洞，但暴露管理更广泛地关注这些漏洞是否可能成为实际攻击的可行路径。

例如，一个仅限于开发系统的易受攻击库，其即时威胁程度要低于一个用于互联网面向系统的类似易受攻击库，后者能够访问数据库。

需要考虑的方面包括网络可访问性、资产暴露情况、易受攻击的代码路径、身份和访问控制、云环境以及系统和数据的敏感性。

简而言之，漏洞管理关注的是漏洞的发现和追踪，而暴露管理则专注于确定哪些漏洞真正或更可能构成风险。

旧的修补管理流程围绕时间构建

传统的漏洞缓解流程依赖于逐步操作。

• 发现CVE
• 安全团队评估严重性
• 维护者发布上游补丁
• 开发人员更新依赖项
• CI/CD流水线运行回归测试
• 生产环境部署
• 验证修复效果

该流程本身并无缺陷，但其基于一个未明说的假设：防守方在每一步都有足够空间进行操作。

让我们以依赖项漏洞为例进行说明。如果自动化扫描器在像lodash这样的流行实用工具包中发现漏洞，工程师不会立即在生产环境中升级依赖项版本。他们需要确认应用程序代码是否使用了易受攻击的函数，检查升级后是否存在破坏性API变更，并通过集成测试运行构建验证。

每个安全补丁本质上都是对代码的修改，需要安全地推进到开发和部署周期中。

AI正在缩短"发现"与"被利用"之间的时间差

过去漏洞发现与利用之间的缓冲期正在消失。这是因为自动化程序可以扫描代码库、生成概念验证并发现边缘情况。

现代AI系统帮助研究人员和潜在攻击者执行静态二进制分析、检测漏洞、创建利用载荷以及发现复杂软件设计中的逻辑问题。

像DARPA的人工智能网络挑战赛（AIxCC）这样的项目展示了AI系统如何用于自动发现和修复复杂开源软件中的漏洞。在2024年半决赛中，自主网络推理系统针对基于现实软件的项目进行了测试，包括Jenkins、Linux内核、Nginx、SQLite3和Apache Tika。这些系统发现了22个独特的合成漏洞，并成功修复了其中15个。它们还识别出了SQLite3中的一个真实漏洞，并进行了负责任的披露。

在实际开发流程中，补丁过程中的某些任务可以由AI执行。AI可以执行代码分析和依赖分析以检测潜在漏洞。它还可以帮助追踪易受攻击函数的使用情况，推荐代码和依赖项的更改，并生成测试以确保建议的补丁不会破坏现有功能。安全团队还可以使用AI进行模式检测。

随着AI工具在评估软件和检测漏洞方面变得越来越好，漏洞检测与缓解之间的窗口期变得越来越短且越来越重要。这种范式的转变也影响了安全专业人员对AI和暴露管理的处理方式，尤其是当利用窗口期缩短且漏洞需要适当优先级排序时。

AI还可以通过将漏洞信息与易受攻击软件运行的环境连接起来来支持暴露管理。例如，AI辅助的安全系统可以将易受攻击的依赖项与面向互联网的应用程序、其网络连接、云权限以及它可以访问的数据或服务相关联。这有助于安全团队从仅仅询问漏洞是否存在转变为询问攻击者通过该漏洞可以实际到达什么位置。

为什么“修复所有漏洞”在大规模下无法奏效

当组织范围的扫描器生成一个包含多个微服务中500个漏洞的列表时，对每个漏洞都紧急响应似乎变得不可能。开发人员很容易因警报疲劳而感到不堪重负。

通用漏洞评分系统（CVSS）是一个用于描述漏洞严重程度的标准框架。CVSS v3.1使用以下严重程度范围：

| CVSS 评分 | 严重程度 | |----------|---------| | 0.0 | 无 | | 0.1–3.9 | 低 | | 4.0–6.9 | 中 | | 7.0–8.9 | 高 | | 9.0–10.0 | 严重 |

CVSS之所以有用，是因为它为开发人员和安全团队提供了一个共同的语言来描述漏洞的严重程度。然而，评分仅描述了漏洞本身，而没有描述该漏洞出现的环境。换句话说，CVSS不会告诉你漏洞使用的功能是否真的被您的应用程序使用，或者受影响的系统是否暴露在互联网上。

为了说明为什么仅凭CVSS并不总是足够，假设我们有一个组织环境中的两个假设漏洞：

• 漏洞A：这是一个关键的远程代码执行漏洞，属于一个隔离的测试框架或仅用于开发的依赖项，从未包含在生产环境中，并且没有任何外部网络访问权限。

• 漏洞B：一个高严重性输入验证漏洞被发现于一个面向互联网的API网关中，该网关处理恶意用户输入，并可以访问包含客户信息的后端数据库。

仅查看CVSS评分会要求团队优先处理漏洞A而不是漏洞B。但很明显，漏洞B对运营构成了更大的威胁。安全研究表明，一旦漏洞被公开，很少有漏洞会被利用。CISA KEV目录的遥测数据清楚地表明，攻击者专注于具有实际利用路径的漏洞子集。

在实际操作中，团队在决定修复哪些问题时，除了考虑CVSS评分，还必须综合许多上下文因素。如果满足以下条件，某个漏洞可能需要更高的优先级：

• 它影响了面向互联网的生产系统，
• 已知该漏洞存在利用方式，
• 暴露了敏感信息，
• 影响了重要的业务功能，
• 或者为攻击者提供了访问其他特权系统的途径。

但如果漏洞仅出现在开发环境，或由于某些原因无法访问，通常不需要立即修复。

确定漏洞重要性的最有效方法是提出一些简单的问题：漏洞系统是否可访问？漏洞代码是否可访问？该漏洞是否存在已知的利用方式？受影响的服务具有哪些权限？攻击者在利用该漏洞后能够访问哪些资源？

对所有告警赋予相同的优先级会浪费工程资源，因为有些漏洞可能根本不存在风险或风险极低。

暴露管理：从漏洞数量转向上下文风险

暴露管理将重点从单纯记录静态漏洞转移到评估组织的实际运营风险状况。

与其询问“我们的代码库中存在多少个CVE？”暴露管理更关注“哪些漏洞组件、配置错误和可访问的网络路径，会在我们的运行资产中形成可被利用的风险？”

当比较两种方法的关注点时，差异会更加明显：

| 维度 | 传统漏洞管理 | 暴露管理 | |------|--------------|----------| | 核心问题 | 存在哪些软件缺陷和CVE？ | 攻击者可以利用哪些路径访问关键资产？ | | 数据范围 | 孤立的依赖项扫描和静态漏洞数据库 | 代码仓库、云运行时、网络路由和IAM权限 | | 优先级指标 | CVSS基础评分和静态严重性评级 | 可达性、可利用性、资产敏感性和环境上下文 | | 主要行动 | 上游包升级和直接软件补丁 | 基于风险的分类处理：网络隔离、配置更改或定向补丁 |

当工程环境管理着10,000个云资产，依赖扫描器发现1,000个漏洞库时，这些数字的简单相加并不能反映真实的网络安全状况。为了聚焦于真正重要的风险，你需要了解每个漏洞所处的具体上下文环境：

• 容器是否暴露在互联网上，还是隐藏在内部负载均衡器之后？
• 代码是否真的调用了存在风险的符号或库函数？
• 漏洞服务能访问哪些身份权限、云角色和数据库？

理解这个分母（需要特定补丁的资产总数）有助于团队识别真正构成威胁的暴露点，从而让工程资源集中在影响生产数据的问题上。

依赖树作为攻击面

现代软件交付依赖于多层软件包，如npm、PyPI、Maven、NuGet、基础操作系统层包、GitHub Actions和第三方API。虽然应用逻辑由开发者编写，但最终的运行时软件包含多个层级的软件包：

你的应用程序逻辑 → 直接依赖（在清单中声明） → 传递依赖（自动引入） → 底层操作系统包 → 基础容器镜像/云运行时。

如果某个漏洞位于传递依赖的第三层，且该传递依赖已无人维护，但可以通过外部输入访问，那么这就是你应用程序攻击面的重要组成部分。

这就是为什么软件开发团队开始使用软件物料清单（SBOM）。SBOM 是构成软件或应用程序的软件组件清单。根据创建 SBOM 所使用的技术，可以获得不同信息，包括组件名称、版本、依赖项和包 ID。

当发现新漏洞时，SBOM 会非常有用。例如，如果在某个特定版本的 lodash 中发现了漏洞，安全团队可以使用其 SBOM 来识别哪些应用程序或容器镜像包含受影响的版本。他们随后可以调查是否存在可被利用的暴露点。

SBOM 本身不会为应用程序提供安全性。其意义在于提高开发人员和安全人员对应用程序中存在内容的可见性。

开发人员的实用建议

一旦将这些原则整合到团队的日常开发流程中，这些原则就会变得相关。你和团队可以采用一些实际方法来应用这些最佳实践和策略：

审计传递依赖

首先要确认应用程序中包含哪些依赖项。这在处理传递依赖时尤其有用，因为这些依赖项可能在安装其他包时被自动添加。

对于 Node.js 应用程序，可以使用命令 npm ls 来显示依赖树。Python 开发者可以使用 pipdeptree，而使用 Maven 创建的 Java 项目可以使用 mvn dependency:tree 命令。这些命令可以帮助你了解包的来源，以及引入漏洞传递依赖的直接依赖项。

检查代码可达性

在依赖项中发现弱点并不意味着你的应用程序中一定使用了它。不要将每个漏洞报告都视为关键的生产阻塞项。相反，你应该调查受影响的功能是否真的可以从你的应用程序访问。

假设你在某个库函数中发现了一个漏洞。在这种情况下，你需要在代码库中查找该函数的使用情况，并判断是否有将用户控制的数据传递给它的可能性。你可以使用 IDE 提供的搜索功能，或命令行工具如 grep。

一个未使用或无法从外部访问的函数会降低发现的紧迫性，但这并不意味着你可以完全忽略它。

在 CI/CD 中生成 SBOM

你也可以通过 CI/CD 管道生成软件物料清单。创建 SBOM 可以帮助你识别软件中使用的组件，并在发现漏洞时更容易识别受影响组件。

例如，使用 Syft，你可以通过执行命令：syft my-app:latest -o cyclonedx-json > sbom.json 从容器镜像生成 SBOM。

这将生成一个包含容器镜像中组件信息的 CycloneDX JSON 文件。该 SBOM（软件物料清单）将与构建产物一同存储。当某个特定软件包版本中发现新漏洞时，安全团队可以轻松识别出哪些应用程序和容器镜像包含该组件。

在补丁尚未就绪时使用补偿性控制措施

有时可能没有可用补丁，或立即实施补丁存在过高风险，因为这可能会引入需要进一步测试的重大变更。在这些情况下，可以使用补偿性控制措施来降低应用暴露风险，直到补丁正式部署。

根据具体环境，这可能包括限制对易受攻击组件的网络访问、将工作负载与敏感资源隔离、禁用已被入侵的功能，或最小化应用的权限。

这些控制措施并不能替代安全补丁，但可以有效降低漏洞被利用的风险，直到补丁正式实施。

运行时实施最小权限原则

最后，限制应用程序在运行时的访问权限。当因漏洞利用导致入侵时，这种限制可以防止攻击扩散到其他应用或系统。

在部署容器化应用时，可以利用只读文件系统，并移除 Linux 环境中不必要的权限。例如，Docker 提供了运行容器时使用 --read-only 和 --cap-drop=ALL 的选项。

云应用也需要采用相同原则，通过确保使用 IAM 权限，仅授予应用实际需要的访问权限。

目标很简单：当某个组件被攻破时，攻击者应尽可能无法访问其周围环境中的其他组件。

软件安全的未来并不取决于组织更新软件包的速度，而在于是否理解更新的底层原因。随着自动化使漏洞检测更加高效，有效的缓解措施依赖于对源代码、其依赖项和运行时基础设施之间关系的深入理解。

此处的目标不仅是发现新漏洞，更要识别那些对应用构成实际风险的漏洞。

总结

虽然人工智能正在帮助团队更快发现漏洞，但现代应用对多层软件的依赖程度越来越高。这并不意味着补丁变得不重要，而是说明并非所有漏洞都需要立即处理。

开发人员仍需关注漏洞的具体位置、是否可被攻击者访问以及可能造成的影响。随着漏洞发现与利用之间的时间差持续变化，理解暴露风险的重要性将与补丁本身同等关键。

你好，我是Reetain Raina，一位专注于可穿戴技术、人工智能、健康科技和新兴消费科技领域的技术作家。我研究并撰写深入的文章，解释现代技术如何塑造日常生活的未来。我的工作内容涵盖智能戒指、智能手表、智能眼镜、人工智能设备、数字健康和可穿戴计算等领域。通过技术分析和以技术为核心的叙事方式，我希望帮助专业人士、科技爱好者和好奇的读者更轻松地理解复杂的创新。感兴趣领域：可穿戴技术 • 人工智能（AI） • 健康科技 • 智能戒指与智能眼镜 • 未来消费科技。

如果你读到这里，请感谢作者以表达你的支持。说声谢谢

免费学习编程。freeCodeCamp的开源课程已帮助超过40,000人成为开发者。立即开始

广告