译者 | 布加迪
审校 | 重楼
一款基于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 base64
CodeGate在这些值到达LLM之前从提示中删除这些值，然后它在响应中无缝地取消编辑。
你可能会说：“等一下。我们依靠ExternalSecretsOperator之类的机制来保护Kubernetes机密，所以我们很安全……是不是？”
你可能正在试用集群，并将token存储在本地存储库或当前工作目录中的文件中。代理可能有点过于雄心勃勃，意外将其添加到你的上下文中，就像我们在代码编辑器中经常看到的那样。这时候CodeGate就会介入，在敏感信息被无意共享之前对其进行编辑。
2. PII编辑
除了机密外，CodeGate还可以检测和编辑可能存在于你基础设施文件或部署清单中的个人身份信息（PII）。
3. 受控模型访问
CodeGate含有模型多路复用功能，可帮助确保基础设施漏洞信息仅发送给拥有适当安全措施的经过批准的受信任模型。
模型多路复用允许你创建规则，将特定文件类型、项目或代码模式传送到不同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
