LiteLLM 1.107.0事件：源码标签没有恶意文件，为何发布包仍可能被污染？
摘要：源码审查与制品验证回答不同问题。最新供应链事件提醒研发团队，把批准的源码、构建输入、实际制品与发布授权连接起来，才能解释最终交付对象的来源。
标签：LiteLLM、软件供应链、制品验证、发布安全、构建溯源
已核实事实与时间
LiteLLM官方通报称，1.107.0恶意wheel于10月21日11:39 UTC起上传，而官方源码标签没有相关恶意文件；通报最后更新20:30 UTC。官方通报
两者均在本轮窗口内。通报仍说明调查进行中，不能把全部推断当成最终取证结论。本文与本批第2、3篇共用事件，以下为独立工程分析，不作为另一场攻击。
源码审查的结论需要限定对象
评审者确认某次提交符合要求，首先证明的是所审查源码的状态。最终发布包可能还经历构建配置、依赖解析、打包与上传，任何环节都可能改变交付内容。
因此，不能直接用一个干净标签证明外部仓库里的全部二进制可信。反过来，制品发生问题，也不能在没有证据时认定所有源码分支都包含相同内容。
团队需要清楚记录每项检查覆盖什么对象。把源码、构建和制品证据分开保存，再建立关联，比用一个笼统的“发布已通过”更便于复查。
发布输入应有明确授权范围
构建任务如果允许选择来源仓库、提交或依赖位置，就应明确哪些值可以被接受，以及谁能够改变这些条件。
这种验证不能只依赖名称相似或界面显示。仓库身份、提交和构建配置需要与批准对象对应，例外也要有可追踪依据。
输入变更本身可以被视作重要发布变更。维护者应能够解释为什么改了来源、由谁批准，以及原有测试结果是否仍适用，而不是让变更隐藏在一次手动运行参数中。
溯源记录要被消费端真正验证
生成构建记录，只是证据形成的一步。使用方还需要知道哪些字段与组织预期匹配，哪些差异应阻止交付。
例如，记录中的源码位置、构建身份和制品摘要，应能够与批准发布对应。若没有明确的接受规则，记录可能只是附带文档，无法形成实际约束。
签名可以帮助证明某项声明由特定身份产生，但不能单独证明该身份所执行的动作符合业务意图。验证要同时关注声明来源与内容含义。
管理权限属于发布边界的一部分
即使正常发布路径有严格检查，能够修改规则、工作流或批准权限的身份，仍会影响整个边界。
团队可以梳理谁能改变发布条件，哪些变更需要复核，以及紧急权限何时收回。重点不是增加无意义审批，而是确保高影响改动能够被发现和解释。
临时放宽权限时，也应说明期限、用途和后续复核。一次业务便利措施如果长期存在，可能逐渐改变最初设计的信任关系。
制品检查要连接最终交付
发布前验证应尽量面向准备分发的实际对象，而不仅是另一次重建结果。否则，测试与发布可能针对不同内容。
可以保存制品摘要、验证时间、扫描范围和批准记录，再核对上传对象是否一致。若某个步骤重新构建，应明确它为什么仍满足接受条件。
这些记录也有助于事件响应。发现某个对象异常时，能够回到具体构建和发布，而不是只能通过版本名称推测。
开发团队近期行动
选择一个重要包的发布流程，逐步核对批准源码、构建输入、制品摘要与上传授权，找出不能被现有记录解释的连接。
随后用无害测试对象模拟来源变化，确认流程是否按预期拒绝或进入复核。无需下载恶意包，也不应在日常环境运行事件样本。
供应链安全需要证明的是实际交付关系。源码审查依然重要，把它与制品及发布授权连接起来，结论才更接近用户最终取得的对象。
