LiteLLM遭投毒，艾体宝Mend.io助力企业快速感知供应链风险

10 月 21 日22:13，艾体宝安全团队收到 Mend.io 发出的零日漏洞提醒，团队登录平台核对组件清单。3分钟后，确认组织内没有版本交集，随即完成影响确认。

这背后是艾体宝 Mend.io 的组件清单管理与持续安全监测能力。平台能够追踪新出现的供应链威胁，将事件与平台中已有的组件清单进行比对研判。用户收到告警后，登录平台即可查看事件详情与组织内的影响情况，快速确认自身是否受到影响。

22:13，安全事件告警抵达客户邮箱

北京时间 10 月 21 日 22:13，Mend.io 平台针对 LiteLLM 1.107.0 供应链攻击事件发出 Zero-Day Event 邮件通知，并将该事件纳入 Mend Zero-Day 事件目录。（原文阅读：https://www.mend.io/blog/litellm-1-107-0-compromised/）

此次事件中，攻击者将恶意代码植入发布至 Python 包索引 PyPI 的 LiteLLM 1.107.0 版本。根据 Mend.io 安全研究团队发布的分析，该版本携带了凭证窃取程序及远程代码加载器，可在 Python 启动时执行恶意操作，窃取开发环境中的各

类敏感凭证，并具备加载、执行远程代码的能力。受影响范围不仅涉及直接使用该组件的应用，还可能延伸至相关开发环境、容器镜像及部署流程。

面对这类突发供应链安全事件，企业首先需要回答的往往不是漏洞的技术原理，而是一个更紧迫的问题：自己的哪些项目使用了受影响的组件？

传统人工排查需要开发、安全及运维团队分别检查项目依赖、版本记录和部署环境。在项目数量较多、依赖关系复杂的情况下，这一过程可能耗费大量时间。

而在本次事件中，Mend.io 通过平台主动发送告警，提醒客户及时查看事件详情，并核查组织内部的实际暴露情况。

从持续监控到主动告警：不必等到风险发生后才开始排查

Mend Zero-Day Event 的价值，不仅在于发现一项新的安全事件，更在于将外部安全情报、企业软件资产和实际风险排查连接起来。

第一步：持续掌握软件组件情况。

企业的软件项目通常依赖大量开源组件，这些组件会随着开发、升级和部署不断变化。通过软件组成分析（SCA）及软件物料清单（SBOM）等能力，Mend.io 帮助企业识别和管理项目中的开源依赖，为后续安全事件影响分析提供资产依据。

第二步：跟踪重大安全事件并及时告警。

当出现新的重大漏洞或供应链攻击事件时，Mend.io 会将相关风险纳入平台的 Zero-Day 事件管理流程，并通过平台界面及相应通知机制提醒客户。企业不必完全依赖安全人员主动搜索外部漏洞公告，才能意识到风险的出现。

第三步：关联企业项目，快速确认影响范围。

收到告警后，客户可以登录 Mend.io 平台，查看事件详情并检查相关应用和项目是否存在受影响的组件。对于确认不受影响的组织，可以及时完成核查并明确当前状态；如果发现受影响项目，则可以进一步定位组件、评估风险并安排修复。

这一机制将原本分散在外部漏洞信息、项目依赖清单和内部排查流程中的工作连接起来，帮助企业缩短从风险出现到确认自身影响的时间。

不只是一次告警，而是持续运行的风险管理机制

10 月 21 日的 LiteLLM 供应链攻击事件，展示了 Mend.io 将新兴安全风险及时传递给客户的能力。同日，Mend.io 还发布了关于 PHP2Shell 的技术分析，指出 PHP 运行时中的两项严重远程代码执行漏洞，并介绍了如何利用容器扫描、Mend SCA 和依赖更新工作流识别受影响资产、推进修复。

这两类事件也体现出软件供应链安全管理的一个共同难点：风险信息不断变化，但企业必须始终掌握自己的软件资产，并能够迅速判断外部风险是否与自身相关。

对于企业而言，真正有效的安全管理不应止步于定期扫描或收到漏洞公告后临时组织排查，而应建立一套持续运转的机制：

• 资产持续可见： 掌握项目使用的开源组件及其依赖关系。
• 风险及时触达： 在重大安全事件出现时，及时接收平台告警。
• 影响快速确认： 将外部风险与内部项目关联，缩小人工排查范围。
• 后续处置有据可依： 对受影响资产开展风险评估、修复和复核。

安全事件无法完全避免，但企业可以通过持续的资产管理与主动告警机制，减少发现风险、确认影响和启动响应之间的时间差。

从收到一封告警邮件，到快速确认组织是否受到影响，Mend.io 希望帮助企业把安全响应从“事件发生后再排查”，推进到“风险出现时及时感知、快速定位并采取行动”。