K8s传统安全风险评估缺乏上下文。红帽与IBM合作，利用AI代理实现部署感知风险分析及自然语言解释，提高准确性，帮助优先处理真实威胁。
译自：AI Can Deliver Deployment-Aware Risk Analysis for Kubernetes
作者：Yair Allouche, Sabina Aledort
对于 Kubernetes 平台工程师或 DevSecOps 负责人来说，这种经历再熟悉不过了：你打开安全仪表盘，映入眼帘的是列出 10,000 个部署的清单，所有这些部署都标记着关键漏洞、配置问题和可疑活动。海量的警报反而造成了一个悖论：当所有事情都是优先事项时，就没有优先事项了。
传统的风险评分解决方案孤立地评估扫描器检测到的风险指标，依赖预定义的启发式规则和静态漏洞评分。这些解决方案主要基于这些静态标签来确定风险优先级，但并未考虑这些风险是否真正适用于特定的部署环境或它们是否构成实际的利用路径。
弥补这种上下文缺失是红帽与 IBM 研究院合作的重点领域，他们正在为 Red Hat Advanced Cluster Security 开发未来的功能。通过引入 AI 驱动的风险调查代理，团队正在从静态评分转向“部署感知”的风险分析。
问题：上下文缺失
在许多当前的 Kubernetes 安全实践中，风险评分通常基于静态元数据而非部署在实时环境中的实际行为进行分配。确定真正的风险需要了解易受攻击的库是否在运行时加载、受影响的端口是否暴露或工作负载是否处于活动状态。
配置弱点可能会加剧某些漏洞的影响，同一部署中的多个常见漏洞和暴露 (CVE) 可能会相互作用，形成链式利用路径。一个漏洞可能启用或支持另一个漏洞的利用，从而创建一条利用链。
此外，异常进程、异常网络活动或未经授权的访问尝试等行为指标可能预示着正在进行的利用尝试。这些信号必须与漏洞数据和部署上下文关联，才能产生准确而有意义的风险评估。
这项新合作的目标是基于真实的部署上下文细化风险评分。为此，该系统解决了传统扫描中的两个关键缺陷：
- 部署感知风险评估： 使用 AI 关联 Red Hat Advanced Cluster Security 检测到的发现，以提供部署感知风险评估。这包括评估每个风险指标对实际部署上下文的适用性，例如确定一个 CVE 是否在特定工作负载中真正可利用。它还包括关联多个指标，以识别它们组合起来产生放大或链式风险的情况。
- 上下文和可解释性： 利用大型语言模型 (LLM) 的能力，生成清晰、自然语言的解释，描述影响风险评分的具体因素。这为客户提供了了解每个评估是如何得出的透明度，使他们能够验证 AI 驱动洞察的质量，并帮助他们更好地理解潜在风险。
解决方案：风险调查代理
这项新功能的核心是 IBM 研究院为 Red Hat Advanced Cluster Security 开发的风险调查代理。
此功能设计为拥有资源支持基于 LLM 代理的用户提供的附加组件。它通过一个复杂的流程运行，旨在提供更具上下文感知能力的风险评估：
- 数据聚合： 代理持续从 Red Hat Advanced Cluster Security 服务中提取数据，包括漏洞扫描结果、运行时进程监控、网络活动、Kubernetes 配置元数据和访问事件。它还利用 CVE 数据库、Exploit DB 情报、MITRE ATT&CK 战术和修复指南等外部来源来丰富此视图。
- 调查代理（“大脑”）： 此组件充当推理层。其主要作用是确定每个发现是否代表实时部署中的真实、可利用的风险。它评估网络暴露、工作负载行为、配置姿态和运行时证据，以评估利用的先决条件是否实际存在。这包括验证易受攻击的组件是否已加载、服务或端口是否已暴露以及工作负载是否处于活动状态且可访问。除了单个发现之外，代理还会执行信号之间的交叉关联。它识别配置弱点何时放大漏洞，可疑进程执行或异常网络流量何时表明正在主动利用，或多个漏洞何时组合形成潜在的利用链。
- LLM 处理和风险解释： 数据经过丰富和上下文化后，由 LLM 处理以生成细化的生成式 AI (GenAI) 风险评分。更重要的是，LLM 提供自然语言解释，描述风险为何重大，并引用特定的部署行为、潜在的利用路径、链式漏洞和观察到的攻击指标。这使安全团队不仅能理解风险级别，还能理解其背后的原因。
幕后：AI 如何“思考”
为了理解这里的价值，让我们来看一个具体的评估场景。
考虑一个运行在 Kubernetes 部署上的类似 Windows Server Update Services (WSUS) 的服务。标准扫描可能会标记 CVE-2025-59287，这是一个通过 TCP 端口 8530 和 8531 针对 WSUS 的远程代码执行漏洞。
- 误报： 在一个集群中，Red Hat Advanced Cluster Security 检测到镜像中存在易受攻击的 WSUS 包，但在运行时分析期间，它确认 TCP 端口 8530 和 8531 已关闭，没有网络暴露。也没有任何 WSUS 相关进程活动的迹象。LLM 确定，尽管库存在，但该漏洞在“当前配置下不可利用”，并将利用怀疑标记为“假”，从而有效降低了其优先级。
- 真阳性： 在另一个部署中，Red Hat Advanced Cluster Security 观察到端口 8530 和 8531 开放且可访问。运行时网络监控检测到来自另一个 Pod 针对这些端口的内部端口扫描尝试。LLM 将这些识别为与远程代码执行探测高度相关的行为，而非通用系统事件。它将其标记为与 CVE-2025-59287 相关的“高度相关——可疑”端口扫描活动，并标记为“真”。
系统随后生成一个人类可读的摘要：“该风险与运行在未打补丁的容器上，且 TCP 端口 8530/8531 开放的暴露 WSUS 服务有关。检测到的集群中异常的端口扫描活动增加了被利用的可能性，并增加了整体风险评分。”
可解释性：交互式、环境感知洞察
虽然传统的 AI 可解释性侧重于阐明风险评分是如何计算的，但正在开发的其他功能旨在通过使系统具有交互性和对部署环境的响应性，将 Red Hat Advanced Cluster Security 推向更高的水平。目标是平台工程师和管理员将能够向 AI 查询特定的工作负载或配置，并获得针对其环境量身定制的清晰、上下文相关的答案。
这种交互式可解释性允许用户直接向模型提供反馈。例如，如果一个部署被标记为高风险，但用户知道它是一个临时的沙盒，他们可以注释该上下文。系统随后会整合此反馈，不断调整和完善其对企业环境的理解。结果是一个“白盒”AI，它不仅解释其推理过程，还从环境和用户输入中学习，从而提供更准确、可操作和可信赖的指导。
展望未来：从分析到修复
IBM 和红帽正在探索使 AI 能够主动提出针对特定部署上下文量身定制的修复措施的功能。未来的迭代旨在生成用户可以直接应用以缓解已识别风险的修复选项。这些包括与环境操作约束相符的风险感知补丁策略、无法立即打补丁的漏洞的缓解措施，以及减少暴露和强化部署的配置更改。
将 GenAI 集成到 Red Hat Advanced Cluster Security 中代表了 Kubernetes 安全领域的一个成熟里程碑。我们正在超越简单的模式匹配时代，进入一个上下文理解的时代。
通过将 IBM 在关联分析方面的研究与红帽的平台功能相结合，Red Hat Advanced Cluster Security 正在尝试解决困扰现代 SecOps 的信噪比问题。对于 IT 经理来说，这意味着减少追逐误报的时间。对于 Kubernetes 用户来说，这意味着更清楚地了解集群中实际运行的内容。
