文章总结： 文章系统剖析了npm与Python生态中的供应链投毒攻击，涵盖命名混淆、依赖混淆、上游接管与间接依赖四种入侵路径，并详述了安装阶段与运行阶段的代码触发机制，特别指出CI/CD环境因凭证集中而风险倍增。防御层面提出锁版本、固定仓库来源、限制安装脚本、30秒包体检、收紧CI权限及分钟级实时拦截六层策略，最后给出已中招后的应急响应四步法。内容兼具攻击原理深度与可落地的防护体系，适合开发与运维人员参考。 综合评分： 85 文章分类： 供应链安全,漏洞分析,安全建设,安全运营,应急响应

你是怎么中招投毒包的，怎么能避免？

原创

KeepHack1ng KeepHack1ng

KeepHack1ng

2026年2月10日 21:02 北京

我上期分享了投毒的Python包，有兄弟评论区问：这种投毒包，我该怎么才能避免中招呢？

今天就以最典型的 npm、Python 投毒包为例，讲讲三件事： 攻击者是怎么投毒的、投毒代码是怎么触发的，以及我们怎么尽量避免中招 。

01

你通常是怎么“装上投毒包”的？

先说结论：大多数投毒包不是“黑进来”的，而是你自己直接或间接把它装进项目的。常见就这几条路：

1. 命名混淆：你打错了包名 攻击者会发布一个 和热门包长得很像 的名字：多一个字母、少一个下划线、大小写变化，甚至就是一个复数形式（比如 request vs requests ）。 你手滑、复制错、看错，一次 install 就把它带进来了。这种方式 成本最低 ，但命中率非常高。
2. 依赖混淆：你以为装的是公司内网包，实际装了公网恶意同名包 很多公司/团队都有私有依赖（内网仓库）。攻击者会通过信息收集（公司官网、邮箱域名、业务名称、Git 公开信息等）去 猜测你们内部可能使用的包名 ，然后提前在公共仓库发布一个 同名恶意包 。如果你的构建环境 没有正确配置“优先/只允许从内部源拉取” ，那么一旦解析依赖时去公网拉到同名包，基本就属于“自己把门打开了”。
3. 上游被接管：原本好包“被植入恶意代码” 更隐蔽的一种：包本来很正常，但维护者账号被盗、发布权限泄露、供应链被渗透，导致某个版本开始夹带恶意代码。 你装的还是“熟悉的包名”，但 版本已经不是你认识的版本 了。
4. 间接依赖：你没直接安装投毒包，但它被正常包所依赖

你只装了 A，A 依赖 B，B 依赖 C……投毒包常常藏在很深的 C。 所以很多人排查时会说：“我根本没装过这个包啊？”——但它确实是被“顺带装进来”的。

02

投毒代码一般怎么“触发”？

很多人以为：只要我不 import 它，它就不会动。 但投毒包最恶心的点在于： 它可以在“安装时”就动起来 ，根本不需要你写任何调用。

1）安装阶段触发：你一 install，它就开始干活（非常常见）

在 npm 和 Python 生态里，都存在“安装/构建阶段会执行脚本或构建逻辑”的场景。攻击者就喜欢把恶意逻辑塞在这里： 你一装包就触发 ，甚至不需要你写任何业务代码。

典型能干的事包括：窃取环境变量、秘钥、主机信息、建立后门等。

2）运行阶段触发：你 import/require 的那一刻

另一类投毒更像“正常代码”，但会在模块初始化时偷偷执行： 你一 import xxx / require(‘xxx’) 就会触发恶意代码。

3）CI/CD 环境触发：一偷就是“整条链路”的权限

投毒包最喜欢在 CI/CD 里发作，不是因为 CI 更“高级”，而是因为 CI 天然就放着一堆高价值凭证 ，而且运行环境通常具备自动化发布能力。

在 CI 里常见能被它盯上的东西包括：

• 发布凭证 ：npm token / PyPI token，一旦被偷，攻击者就能用你的身份发“新版本”，把投毒扩散给更多人

• 代码仓库权限 ：GitHub/GitLab token，被偷后可能直接推代码、开 PR、改 workflow，甚至埋长期后门

• 云环境密钥 ：AWS/Azure/GCP 等访问密钥，被偷后可以拉取生产配置、访问存储、动基础设施

• 镜像/制品仓库权限 ：Docker registry、制品库 token，被偷后可以把构建产物“换货”

• 签名/证书材料 ：一些团队还会在流水线里做制品签名或证书打包，这类一旦泄露，影响更难收拾

所以同样一段投毒代码，在你本地最多偷点个人配置；但在 CI 里，攻击者通常不仅能偷密钥，还能借你的身份发布版本、篡改构建产物、把后门推到生产 ，影响直接从“某台机器”升级成“整条交付链路”。

03

怎么避免中招？

投毒这件事，核心思路就两句话： 减少“装错/装到坏版本”的概率 ，以及 让坏包即便出现也进不了你的链路 。下面按实用优先级来。

1）先把“装包来源”和“版本”管住（最关键）

锁版本 ：别让依赖“自动漂到最新”。

• npm ：保留并使用 lockfile；CI 里尽量让安装严格按 lockfile 走，保证可复现。

• Python ：requirements 尽量固定版本，少用 >= 这类大范围条件。

固定仓库来源 ：团队有私有仓库，就要明确配置 只从私有源/指定源拉取 ，避免解析依赖时“到处找”。

这一步的意义很简单：把“每次安装像抽盲盒”，变成“每次安装都可控、可复现”。

2）减少“安装时自动执行”的机会

npm 的安装阶段脚本是高风险点：在构建/CI 场景里，可以考虑限制或禁用不必要的安装脚本（但要结合项目实际，别一刀切导致构建失败）。 Python 侧尽量避免在不可信环境里“边装边构建”，能用经过固定/审计的依赖集合就用。

3）装之前做一次“30 秒体检”

不需要安全专家，也能快速过滤掉一批明显风险包：

• 包名是否像“碰瓷”（差一个字母、复数/大小写变化等）

• 下载量/更新时间是否异常（突然冒出来、突然频繁发版）

• 是否有正常的仓库/主页/文档

• 维护者是否突然更换、账号是否像临时号

4）CI 里把权限收紧：就算中招也别让它“偷到大钥匙”

投毒包最爱偷的就是 CI 里的“钥匙”。所以 CI 要按 最小权限 设计：

• CI token 最小权限：能读就不给写，能发测试就不给生产

• 生产密钥与普通构建分离，关键发布步骤加审批/签名

• 构建环境尽量隔离（容器/沙箱），必要时限制网络出站（很多投毒要把数据“传出去”）

5）从“事后扫描”升级到“实时预防”：分钟级发现 + 入口拦截

前面的做法属于基础防线，但如果想把投毒风险真正压下去，关键是把防护 前移到“包进入项目之前” ：做到 实时监测 ，并把结果落地为 可执行的入口拦截 。

我实现的投毒检测引擎可以实时检出 npm / PyPI / Chrome 插件 / VSCode 插件 /AI Skills 等生态的投毒组件，核心能力包括：

• 分钟级检出 ：组件一发布/一更新，即可在分钟级判断是否存在投毒风险

• 告警推送 ：命中高风险后直接推送通知，第一时间定位到“哪个包、哪个版本出事”

• 规模化发现 ：目前 每周稳定发现几百例投毒组件 （包含新投毒、复活包、变种包等）

更重要的是，这种分钟级检出能力不仅能“发现”，还能进一步落地成“拦截”。我提供给客户的是持续更新的 投毒数据 （投毒包名、版本、IOC等），客户可以按自身链路选择落地点，把风险挡在门外，例如：

• 私有化仓库/制品库侧拦截 ：将投毒包或高风险版本加入黑名单，禁止入库、禁止同步、禁止下载

• 镜像/代理侧过滤 ：在依赖代理或缓存层做版本级拦截/隔离（命中就拒绝或转人工审核）

• CI/CD 阶段拦截 ：构建前做依赖校验，命中投毒直接 fail build，并通知负责人

• 终端/研发环境侧防护 ：对开发机装包行为做风险提示或拦截（适合管控更强的团队）

• 集成到客户自有产品 ：把投毒数据接入安全平台/研发治理平台，形成统一告警与处置闭环

• 网关侧拦截 ：将检测引擎产出的黑名单/风险评分/规则接入网关，在“安装入口”直接拦截或隔离高风险包

这样做的效果很直接：让投毒包尽量进不了仓库、进不了构建、进不了交付链路 。

换句话说： 锁版本 + 固定来源 解决的是“降低中招概率”，而 分钟级检测 + 入口拦截 解决的是“把已知风险直接挡在门外”。

04

如果你怀疑已经中招了，先做这四步

1. 先停发版/停部署 ，避免继续扩大影响
2. 回滚到已知安全的锁定依赖版本 （含 lockfile / requirements）
3. 立刻轮换密钥 （GitHub Token、云 Key、SSH key、数据库密码等）
4. 排查最近依赖变动：新增/升级的包、间接依赖变化；CI 日志里是否出现异常脚本执行/异常网络请求

05

结尾

投毒包的核心套路一句话： 利用你对依赖的信任，把恶意代码伪装成“正常组件”，在安装或加载时偷偷执行。

真正有效的防护也很朴素： 锁版本、管来源、收紧 CI 权限、定期审计依赖 。 如果再往前一步，把依赖引入统一走网关，并配合分钟级投毒检测与告警推送，很多风险就能被拦截在“进入项目之前”。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：KeepHack1ng KeepHack1ng KeepHack1ng《你是怎么中招投毒包的，怎么能避免？》