软件开发和部署过程十分复杂。现代企业应用具有复杂的软件依赖关系，形成了一个互联的网络，提供了前所未有的功能，但成本却呈指数级增长。
根据 NVIDIA 的数据，2022 年常见漏洞和暴露 (CVE) 数据库中报告的安全漏洞数量创历史新高。随着该数据库中报告的安全漏洞数量不断增加，软件安全问题正变得越来越具有挑战性。详情请参阅 CVE 数据库。
截至 2023 年底，报告的漏洞累计超过 20 万个，显然传统的扫描和修补方法已变得难以管理。使用生成式 AI，可以在减轻安全团队负担的同时改进漏洞防御。
组织已经开始研究生成式 AI 来帮助实现这一过程的自动化。但是，在企业级范围内这样做需要收集、理解和合成许多信息。
AI 代理和检索增强型生成为 CVE 分析添加智能功能
检测和修复 CVE 的第一步是扫描软件中与数据库中已知 CVE 存在关联的签名。但这一过程不应就此止步。
逻辑上的下一步可能是通过生成拉取请求并将软件包版本调整为补丁或固定版本来修复 CVE.但是，要求为每个检测到的 CVE 升级软件包是不现实的，并且不适用于企业级软件发布，尤其是在软件包升级可用之前通常会发现较新的 CVE。
由于软件依赖关系的复杂性，即使软件包存在，升级到非漏洞版本也不一定是可能的。调查 CVE 以确定最佳前进方向非常耗时。
生成式 AI 代理可实现更复杂的响应。它们加快了人类安全分析师对 CVE 和扫描软件容器进行更广泛的研究和调查的手动工作，以确定是否需要升级，但执行速度显著加快 (图 1)。
在此 CVE 分析 AI 工作流程示例中，我们做到了这一点。就本文而言，我们的生成式 AI 应用程序名为“Agent Morpheus”，该应用程序会采取其他步骤来确定是否确实存在漏洞，生成任务清单以正确、彻底地调查 CVE，最重要的是，确定其是否可利用，这是分析的关键部分。
对于企业级软件发布而言，自动补救是不切实际的
企业软件可能并不总是需要更新每个检测到的 CVE 以保持安全，而且这样做并不总是可行的。其中一个原因可能是，维护人员无法获得漏洞包的更新版或固定版本。另一个挑战是，现代软件项目的依赖链非常复杂，更新一个软件包可能会导致与其他依赖项的兼容性问题，并破坏软件。
软件是否应在最后的 CVE 修复之前保持未发布状态？显然不是，但发行商应确信其软件不包含可在使用软件期间加以利用的关键或较高的 CVE 分数。
区分容易受到攻击的容器 (存在 CVE) 和可利用的容器 (实际上可以执行和滥用漏洞) 非常重要。
CVE 在容器中不可利用的原因有很多。一些理由可以像漏洞扫描为误报、CVE 签名不正确以及容器中实际上不存在漏洞库一样简单。
CVE 不需要补丁的其他原因可能更复杂，例如漏洞库需要运行时中不存在的特定依赖项。例如，容器内未安装 Java 运行时环境 (JRE) 的库中的。jar 文件中的 CVE.如果没有 JRE，则无法执行。jar 文件，因此由于缺少依赖项，CVE 无法利用。
另一个不可利用的 CVE 理由是，库中的漏洞代码或函数根本无法使用或访问软件，或者存在缓解条件。
确定每个 CVE 可利用性的确切方法是基于特定漏洞的独特过程。它需要分析师合成来自各种情报来源的 CVE 信息，并将其应用到相关容器或软件项目中。这是一个非常繁琐和耗时的手动过程。
在无需人工提示的情况下获取更多上下文、推理和标准安全理由
Agent Morpheus 采用另一种方法，将检索增强生成 (RAG) 和 AI 代理结合到事件驱动的工作流中，以进行数据检索、合成、规划和高阶推理。
该工作流程连接到多个漏洞数据库和威胁情报来源，以及与特定软件项目相关的资产和数据，例如源代码、软件材料清单 (SBOM)、文档和通用互联网搜索工具。
该工作流程使用四个不同的 Lama3 大型语言模型 (LLM)，其中三个模型针对其特定任务进行了 LoRA 调优：
- 规划或独特的清单任务生成阶段
- AI Agent 阶段，用于在特定软件项目的上下文中执行检查清单项目
- 包含所有项目的总结阶段
- 将不可利用的 CVE 的合理性标准化为常见的机器可读和可分发的格式，即 VEX 格式。
由于工作流会生成一份检查清单，且 AI 智能体会独立运行该检查清单，从而有效地与自身对话，因此它可以独立于人类分析师进行操作，而无需提示。这提高了流程的效率，因为只有当人类可以获得足够的信息以就后续步骤做出决定时，人类分析师才会参与其中。
漏洞扫描事件通过传递在容器中检测到的 CVE 列表来触发工作流程。这些结果与最新的漏洞和威胁情报相结合，为工作流程提供有关特定 CVE 及其当前利用情况的实时信息。
这些信息会添加到经过微调的 LLM LoRA 的提示中，该 LLM LoRA 的特定任务是制定独特的计划或检查清单，以确定 CVE 是否可利用。例如，之前 .jar 文件示例的检查清单可能会包括“检查软件项目是否需要 JRE 来执行漏洞百出的。jar 文件”等项目。检查清单项目会传递给 AI 代理，该代理会检索必要的信息并自动执行任务。
AI 代理可以访问与软件项目和容器相关的许多资产，以有效执行检查清单项目并做出决策。例如，它可以在项目的软件材料清单和源代码中搜索 JRE，并得出环境无法运行 .jar 文件、CVE 不可利用以及容器不需要立即修补的结论 (图 2)。
除了数据源之外，AI 智能体还可以访问工具，帮助其克服当前 LLM 的一些限制。
例如，LLM 的一个常见缺点是难以执行数学计算。这可以通过允许 LLM 访问计算工具来克服。对于我们的工作流程，我们发现模型难以比较软件包版本号，例如 1.10 之前的版本 1.9.1，我们构建了一个版本比较工具，代理用于确定软件包版本之间的关系。
图 3 显示了单个 CVE 示例的打印输出。
借助事件驱动的 RAG 加速软件交付
借助 Agent Morpheus，组织可以将软件分拣漏洞所需的时间从几小时或几天缩短到几秒钟。它可以独立感知、推理和行动，无需人类分析师的提示或协助。完成分析后，Agent Morpheus 会向人类分析师展示结果摘要，然后由其确定最佳行动方案。
分析师对 Agent Morpheus 摘要的任何人类批准的补丁豁免或更改都会反馈到 LLM 微调数据集，以便根据人类输出持续改进模型。
Agent Morpheus 与我们的容器注册表和内部安全工具完全集成，可完全自动化从容器上传到创建最终 VEX 文档的整个过程。
- 每当用户将新容器推送到注册表时，就会发生容器上传事件，从而触发此过程。
- 上传容器后，系统会立即使用 Anchore 等传统 CVE 扫描仪对其进行扫描。扫描结果将传递给 Agent Morpheus 服务。
- Agent Morpheus 为列出的 CVE 检索必要的情报，并准备任何代理工具。
- 运行 Agent Morpheus 模型和代理，为每个 CVE 生成最终摘要和分类。
- 然后，每个 CVE 的最终摘要和分类将发送到安全分析师控制面板进行审核。分析师会查看原始容器扫描报告、改进的摘要以及 Agent Morpheus 提供的理由，并针对每个 CVE 提出最终建议。
- 系统会发送推荐系统以供同行评审。必须作出的任何更改均会返回给分析师。
- VEX 文档完成同行评审后，最终文档将随容器一起发布和分发。
- 摘要中的任何更改或分析师的豁免都会编译成新的训练数据集，用于不断重新训练模型，并使用分析师的输出自动改进系统。
Agent Morpheus 使用 NVIDIA NIM 推理微服务来加快部署速度和推理速度。NIM 微服务用于执行所有 LLM 查询，并且出于多种原因而成为工作流不可或缺的一部分。 NVIDIA NIM 可让您轻松启动与 OpenAI API 规范兼容的 LLM 服务。
Agent Morpheus 使用三个 LoRA 定制版本的 Llama3 模型和一个 Llama3 基础模型，它们都使用单个 NIM 容器托管，该容器可根据需要动态加载 LoRA 适配器。
NIM 还可以处理该工具生成的 LLM 请求的爆发性。平均而言，每个 CVE 的 Agent Morpheus 大约需要 41 个 LLM 查询！由于容器扫描可以为每个容器生成数十个 CVE，因此单个容器的待处理 LLM 请求数量可以轻松达到数千个。NIM 可以处理此类可变工作负载，并消除开发自定义 LLM 服务的需求。
与传统聊天机器人流程不同，Agent Morpheus 事件驱动工作流不受人类响应所需时间的限制。相反，加速工作流可以使用相同的并行化和优化技术 (传统机器学习流程的基石) 运行所有 CVE 或事件。
借助 Morpheus 网络安全框架，我们构建了一个工作流，用于编排大量 LLM 请求，并能够异步并行执行 LLM 请求。每个 CVE 和 CVE 的检查清单项目完全相互独立，可以并行运行。
串行运行时，处理包含 20 个 CVE 的容器可能需要 2842.35 秒。使用 Morpheus 并行运行时，处理同一容器需要 304.72 秒，速度提高了 9.3 倍！
Morpheus 通过使用 HttpServerSourceStage 将管道转变为微服务，简化了工具与容器注册表和安全控制面板服务的集成。借助此源阶段，Agent Morpheus 真正是事件驱动的，并在每个容器上传到注册表时自动触发，使其能够满足企业软件漏洞管理的极高需求。
了解详情
注册以接收通知，以便您可以下载 安全漏洞分析 AI 工作流程，并体验 NVIDIA AI Enterprise 的 90 天免费试用。
欲了解更多信息，请观看 Bartley Richardson 的 GTC 会议录像：如何应用生成式 AI 提高网络安全。
