我們如何構建了一個LangGraph代理以確定GitOps漏洞的優先級？ 原創
一款基于LangGraph的開源工具可幫助你確定在特定的Kubernetes環境中最需要優先解決的漏洞。
在當今復雜的Kubernetes環境中，管理漏洞并確定優先級很快會變得令人不堪重負。由于數十甚至數百個容器跨多個服務運行，你如何決定先處理哪些漏洞？
這時候AI可以助一臂之力。我在本文中將介紹我們使用LangGraph和LangChain構建基于AI的漏洞優先級排序器HAIstings方面的經驗，并使用Stacklok開發的開源AI網關CodeGate增強安全性。
漏洞太多，時間太少?
如果你曾經針對Kubernetes集群運行過Trivy之類的漏洞掃描程序，對此就會深有體會：出現在數十個映像中的成百上千個常見漏洞和暴露（CVE），而解決漏洞的時間和資源有限。應該先處理哪些漏洞？
傳統方法依賴嚴重性分數（即嚴重、高、中、低），但這種分數并未考慮到你的特定基礎設施環境。比如說，內部非關鍵服務中的高漏洞可能不如一個面向互聯網的組件中的中等漏洞來得緊迫。
我們想看看是否可以使用AI來幫助解決這個優先級確定問題。受阿加莎小說中的Hercule Poirot偵探的助手Arthur Hastings的啟發，我們構建了HAIstings來幫助基礎設施團隊根據以下因素確定漏洞的優先級：
- 嚴重性（嚴重/高/中/低）。
- 基礎設施上下文（來自 GitOps存儲庫）。
- 用戶提供的有關組件關鍵性的見解。
- 通過對話不斷加深理解。
使用LangGraph和LangChain構建HAIstings?
基于LangChain而建的LangGraph提供了一個出色的框架，用于創建具有記憶的對話式AI代理。下面是我們構建HAIstings的方式：
1. 核心組件
HAIstings的主要組件包括如下：
- k8sreport：連接到Kubernetes，從trivy-operator收集漏洞報告。
- repo_ingest：提取基礎設施存儲庫文件以提供上下文。
- vector_db：使用向量嵌入來存儲和檢索相關文件。
- memory：維護跨會話的對話歷史記錄。
2. 對話流
HAIstings使用LangGraph狀態機，流程如下：
graph_builder = StateGraph(State)
# Nodes
graph_builder.add_node("retrieve", retrieve) # Get vulnerability data
graph_builder.add_node("generate_initial", generate_initial) # Create initial report
graph_builder.add_node("extra_userinput", extra_userinput) # Get more context
# Edges
graph_builder.add_edge(START, "retrieve")
graph_builder.add_edge("retrieve", "generate_initial")
graph_builder.add_edge("generate_initial", "extra_userinput")
graph_builder.add_conditional_edges("extra_userinput", needs_more_info, ["extra_userinput", END])這會創建一個循環，其中HAIstings負責：
- 檢索漏洞數據。
- 生成初始報告。
- 要求提供更多上下文。
- 根據新信息完善評估。
3. 相關上下文的RAG
挑戰之一在于從可能龐大的GitOps存儲庫中高效地檢索相關文件。為此，我們采用了一種檢索增強生成（RAG）方法：
def retrieve_relevant_files(repo_url: str, query: str, k: int = 5) -> List[Dict]:
"""Retrieve relevant files from the vector database based on a query."""
vector_db = VectorDatabase()
documents = vector_db.similarity_search(query, k=k)
results = []
for doc in documents:
results.append({
"path": doc.metadata["path"],
"content": doc.page_content,
"is_kubernetes": doc.metadata.get("is_kubernetes", False),
})
return results這確保上下文中僅包含每個易受攻擊組件最相關的文件，從而使提示大小易于控制。
安全考量?
使用LLM和基礎設施數據時，安全至關重要。我們在分析的漏洞報告和基礎設施文件可能含有敏感信息，比如：
- 配置詳細信息。
- 身份驗證機制。
- 基礎設施文件中可能泄露的憑據。
這時候，開源項目CodeGate顯得必不可少。CodeGate充當HAIstings和LLM提供程序之間的保護層，提供了關鍵保護。
1. 機密信息編輯
CodeGate會自動識別并編輯提示中的機密信息，比如API密鑰、token和憑據，然后它們才會到達大語言模型（LLM）提供程序。這可以防止敏感數據意外泄露給第三方云服務。
比如說，如果你的Kubernetes清單或GitOps存儲庫含有：
apiVersion: v1
kind: Secret
metadata:
name: database-credentials
type: Opaque
data:
username: YWRtaW4= # "admin" in base64
password: c3VwZXJzZWNyZXQ= # "supersecret" in base64CodeGate在這些值到達LLM之前從提示中刪除這些值，然后它在響應中無縫地取消編輯。
你可能會說：“等一下。我們依靠ExternalSecretsOperator之類的機制來保護Kubernetes機密，所以我們很安全……是不是？”
你可能正在試用集群，并將token存儲在本地存儲庫或當前工作目錄中的文件中。代理可能有點過于雄心勃勃，意外將其添加到你的上下文中，就像我們在代碼編輯器中經常看到的那樣。這時候CodeGate就會介入，在敏感信息被無意共享之前對其進行編輯。
2. PII編輯
除了機密外，CodeGate還可以檢測和編輯可能存在于你基礎設施文件或部署清單中的個人身份信息（PII）。
3. 受控模型訪問
CodeGate含有模型多路復用功能，可幫助確?；A設施漏洞信息僅發送給擁有適當安全措施的經過批準的受信任模型。
模型多路復用允許你創建規則，將特定文件類型、項目或代碼模式傳送到不同AI模型。比如說，你可能希望基礎設施代碼由私有的本地托管模型處理，而一般的應用程序代碼則由基于云的模型處理。
模型多路復用支持：
- 數據敏感度控制：將敏感代碼（比如基礎設施、安全或身份驗證模塊）傳送到具有更嚴格隱私保證的模型。
- 合規要求：確保某些類型的代碼永遠不會離開環境，以滿足監管部門的要求。
- 成本優化：僅對關鍵代碼部分使用成本昂貴的高性能模型。
- 性能調整：將代碼復雜性與最合適的模型功能相匹配。
- 以下是使用基礎設施存儲庫的示例模型多路復用策略：
- 規則：*.tf、*.yaml或*-infra.*可以多路復用到本地托管的Ollama模型。
好處：Terraform文件和基礎設施YAML永遠不會離開你的環境，從而防止機密、IP地址或基礎設施設計可能被泄露。
4. 可追溯的歷史記錄
CodeGate維護與AI模型的所有交互的中央記錄，創建所有漏洞評估和建議的審計跟蹤記錄。
使用CodeGate配置HAIstings
配置HAIstings以便與CodeGate配合使用非常簡單。更新HAIstings中的LangChain配置：
# HAIstings configuration for using CodeGate
self.llm = init_chat_model(
# Using CodeGate's Muxing feature
model="gpt-4o", # This will be routed appropriately by CodeGate
model_provider="openai",
# API key not needed as it's handled by CodeGate
api_key="fake-api-key",
# CodeGate Muxing API URL
base_url="http://127.0.0.1:8989/v1/mux",
)結果
鑒于HAIstings和CodeGate協同工作，生成的系統可提供智能、上下文感知的漏洞優先級確定機制，同時保持嚴格的安全控制。
來自HAIstings的示例報告可能就像這樣：
# HAIsting's Security Report
## Introduction
Good day! Arthur Hastings at your service. I've meticulously examined the vulnerability reports from your Kubernetes infrastructure and prepared a prioritized assessment of the security concerns that require your immediate attention.
## Summary
After careful analysis, I've identified several critical vulnerabilities that demand prompt remediation:
1. **example-service (internet-facing service)**
- Critical vulnerabilities: 3
- High vulnerabilities: 7
- Most concerning: CVE-2023-1234 (Remote code execution)
This service is particularly concerning due to its internet-facing nature, as mentioned in your notes. I recommend addressing these vulnerabilities with the utmost urgency.
2. **Flux (GitOps controller)**
- Critical vulnerabilities: 2
- High vulnerabilities: 5
- Most concerning: CVE-2023-5678 (Git request processing vulnerability)
As you've noted, Flux is critical to your infrastructure, and this Git request processing vulnerability aligns with your specific concerns.
## Conclusion
I say, these vulnerabilities require prompt attention, particularly the ones affecting your internet-facing services and deployment controllers. I recommend addressing the critical vulnerabilities in example-service and Flux as your top priorities.性能考量
LLM交互本身很慢，你不應該依賴它們來獲取實時的關鍵警報。代理LLM流量會增加一些延遲。這是可以預料到的，因為這番操作需要耗費大量的計算資源。話雖如此，我們認為這么做帶來的安全好處卻是值得的。你只需多花幾秒鐘的處理時間，就能獲得針對你特定基礎設施需求的大為改進的漏洞優先級確定機制。
為基礎設施確保安全的AI
使用LangGraph和LangChain構建HAIstings表明了AI如何幫助解決現代基礎設施中的漏洞優先級確定問題。結合使用CodeGate確保了這種AI幫助不會以犧牲安全為代價。你可以獲得智能的上下文感知指導，而不降低安全標準，讓你的團隊可以專注于修復最重要的漏洞。
隨著基礎設施變得越來越復雜，漏洞越來越多，HAIstings等工具代表了基礎設施安全管理的未來，在保持最嚴格安全標準的同時提供智能的上下文感知指導。
你可以使用我們GitHub存儲庫中的代碼：??https://github.com/StacklokLabs/HAIstings??，試用 HAIstings。?
原文標題：??How We Built a LangGraph Agent To Prioritize GitOps Vulns?，作者：Juan Antonio "Ozz" Osorio和Radoslav Dimitrov
