AI 可为 Kubernetes 提供部署感知的风险分析

我爱免费

作者：微信文章
AI 可为 Kubernetes 提供部署感知的风险分析

核心要点：了解 Red Hat 和 IBM 如何使用 AI 智能体为 Kubernetes 安全添加真实部署上下文，超越静态评分以发现真实风险

2025 年 12 月 5 日 上午 9:00 | 作者：Yair Allouche 和 Sabina Aledort

---

对于 Kubernetes 平台工程师或 DevSecOps 负责人来说，这种经历再熟悉不过了：打开安全仪表板，迎面而来的是 10000 个部署的列表，全部标记有关键漏洞、配置问题和可疑活动。警报数量之大造成了一个悖论：当一切都是优先事项时，什么都不是优先事项。

传统的风险评分解决方案孤立地评估扫描器检测到的风险指标，依赖预定义的启发式方法和静态漏洞评分。这些解决方案主要基于这些静态标签来优先处理风险，但不考虑这些风险是否真正适用于特定的部署环境，或者它们是否构成实际的利用路径。

解决这种上下文缺失的问题是 Red Hat 与 IBM Research 合作的重点，他们正在为 Red Hat Advanced Cluster Security 开发未来功能。通过引入 AI 驱动的风险调查智能体，团队正在从静态评分转向"部署感知"的风险分析。

---

问题：上下文差距


在当前的许多 Kubernetes 安全实践中，风险评分通常基于静态元数据分配，而不是部署在实时环境中的实际行为。确定真实风险需要了解易受攻击的库是否在运行时加载、受影响的端口是否暴露，或者工作负载是否处于活动状态。

配置弱点可能会加剧某些漏洞的影响，同一部署中的多个常见漏洞和暴露（CVE）可能会相互作用形成链式利用路径。一个漏洞可能启用或支持另一个漏洞的利用，从而创建利用链。

此外，行为指标如异常进程、异常网络活动或未经授权的访问尝试可能表明正在进行利用尝试。这些信号必须与漏洞数据和部署上下文相关联，以产生准确且有意义的风险评估。

新合作的目标是基于真实部署上下文完善风险评分。为此，系统解决了传统扫描中的两个关键差距：

部署感知的风险评估：使用 AI 关联 Red Hat Advanced Cluster Security 检测到的发现，提供部署感知的风险评估。这包括评估每个风险指标在实际部署上下文中的适用性，例如确定 CVE 是否在特定工作负载中真正可利用。还包括关联多个指标以识别它们组合产生放大或链式风险的情况。

上下文和可解释性：利用大型语言模型（LLM）的能力生成清晰、自然的语言解释，描述影响风险评分的具体因素。这为客户提供了每个评估如何得出的透明度，使他们能够验证 AI 驱动洞察的质量，并帮助他们更好地理解潜在风险。

---

解决方案：风险调查智能体


这项新能力的核心是 IBM Research Labs 开发的用于 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，这是一个针对 WSUS 通过 TCP 端口 8530 和 8531 的远程代码执行漏洞。

误报：在一个集群中，Red Hat Advanced Cluster Security 检测到易受攻击的 WSUS 包存在于镜像中，但在运行时分析中，它确认 TCP 端口 8530 和 8531 已关闭，没有网络暴露。也没有任何 WSUS 相关进程活动的迹象。LLM 确定虽然库存在，但漏洞"在当前配置下不可利用"，并将利用嫌疑标记为 False，有效地降低其优先级。

真阳性：在另一个部署中，Red Hat Advanced Cluster Security 观察到端口 8530 和 8531 是开放且可访问的。运行时网络监控检测到来自另一个 Pod 的针对这些端口的内部端口扫描尝试。LLM 将这些识别为与远程代码执行探测强相关的行为，而不是通用系统事件。它将其标记为与 CVE-2025-59287 相关的"高度相关 - 可疑"端口扫描活动，标记为"True"。

然后系统生成人类可读的摘要："风险与运行在未修补容器上的暴露 WSUS 服务相关，开放了 TCP 端口 8530/8531。检测到的集群中异常端口扫描活动增加了利用可能性，并影响总体风险评分。"

---

可解释性：交互式、环境感知的洞察


虽然传统的 AI 可解释性侧重于澄清风险评分如何计算，但正在开发额外功能，通过使系统交互式并响应部署环境，将 Red Hat Advanced Cluster Security 提升到新水平。目标是平台工程师和管理员能够查询 AI 关于特定工作负载或配置的问题，并接收针对其环境量身定制的清晰、上下文相关的答案。

这种交互式可解释性允许用户直接向模型提供反馈。例如，如果部署被标记为高风险但用户知道它是临时沙盒，他们可以注释该上下文。然后系统整合此反馈，不断适应和完善对企业环境的理解。结果是形成一个"白盒"AI，不仅解释其推理，还从环境和用户输入中学习，实现更准确、可操作和可信的指导。

---

未来展望：从分析到修复


IBM 和 Red Hat 正在探索使 AI 能够主动提出针对特定部署上下文量身定制的修复行动的能力。未来的迭代旨在生成用户可以直接应用以缓解已识别风险的修复选项。这些包括与环境的操作约束相一致的风险感知修补策略、无法立即修补的漏洞的缓解步骤，以及减少暴露和强化部署的配置更改。

将 GenAI 集成到 Red Hat Advanced Cluster Security 中代表了 Kubernetes 安全的一个成熟里程碑。我们正在超越简单模式匹配的时代，进入上下文理解的时代。

通过将 IBM 在相关性分析方面的研究与 Red Hat 的平台能力相结合，Red Hat Advanced Cluster Security 正试图解决困扰现代 SecOps 的信噪比问题。对于 IT 经理来说，这意味着减少追逐误报的时间。对于 Kubernetes 用户来说，这意味着更清楚地了解其集群中实际运行的内容。

---

趋势故事

AI 可为 Kubernetes 提供部署感知的风险分析良好的软件供应链安全是什么样的为什么 Kubernetes 安全对 GenAI 完整性至关重要AWS WAF vs. Google Cloud Armor：多云安全对决在 Kali Linux 上使用 Burp Suite 渗透测试 Web 应用

---

文档来源：AI Can Deliver Deployment-Aware Risk Analysis for Kubernetes
原始作者：Yair Allouche 和 Sabina Aledort
原始发布日期：2025 年 12 月 5 日

本文由 AI 助手整理优化，欢迎关注、分享转载，请注明出处