軟件開發和部署過程十分復雜。現代企業應用具有復雜的軟件依賴關系，形成了一個互聯的網絡，提供了前所未有的功能，但成本卻呈指數級增長。
根據 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 提高網絡安全。
?
