一组值得关注的数据是：在公开开源安全通告库中，仅 npm 与 PyPI 两个生态就能看到超过 23 万条相关告警。其中 npm 约 21.9 万条，PyPI 约 2 万条。更关键的是，这些记录里相当一部分并不是传统意义上的 CVE 漏洞，而是恶意包、窃密包、后门包、仿冒包、依赖混淆包。
这意味着，今天的软件供应链风险已经不能只用「有没有漏洞」来衡量。很多时候，包本身没有被发现什么代码缺陷，因为它从发布那一刻起就是恶意的。
一、攻击者不一定高级，但手法非常稳定
软件供应链攻击最可怕的地方，不一定在于技术多复杂，而在于它利用了开发者生态里的默认信任。
开发者安装依赖时，通常不会逐行审查每个包的安装脚本；CI/CD 流水线拉取依赖时，也不会默认把每个包当作潜在恶意代码对待。包管理器、构建工具、IDE 插件、AI 编程助手配置，原本都是为了提高效率而存在的。但攻击者看中的，恰恰是这种效率背后的自动执行能力。
比如 npm 包可以在 postinstall 阶段自动运行脚本；PyPI 包可以在安装或导入时执行代码；Rust 包可以通过 build.rs 在构建阶段运行逻辑；VS Code 扩展可以在开发者打开项目或触发特定功能时激活。对正常软件来说，这些都是便利功能；对恶意软件来说，这些就是入口。
于是，供应链攻击逐渐形成了几个稳定模式：安装时执行、读取本地敏感文件、收集凭据或钱包数据、通过公共 Webhook 外传、必要时植入持久化机制。攻击者不需要每次都发明新技术，只要把这些组件重新组合，就能制造一批新的恶意包。
二、五类最常见的攻击模式
第一类是安装钩子窃密。典型场景是开发者执行 npm install 或 pip install 后，恶意代码在安装过程中自动运行，读取本机的 .npmrc、.pypirc、SSH key、AWS 凭据、GitHub token、环境变量等敏感信息。很多开发者机器本身就保存着大量高权限凭据，一旦被读取，攻击者拿到的不只是单台电脑，而是背后一整条开发链路。
第二类是加密钱包与浏览器数据窃取。攻击者会扫描 Chrome、Brave、Edge 等浏览器的用户目录，寻找 MetaMask、Phantom、Coinbase Wallet、Rabby、Keplr 等钱包扩展的数据，也会检索助记词、seed phrase、keystore 等关键词。相比企业凭据，钱包资产更容易快速变现，因此这类攻击在恶意包生态中越来越常见。
第三类是 Webhook 外传。很多恶意包并不会搭建复杂的 C2 基础设施，而是直接把窃取到的数据发送到 Discord、Telegram、Slack、Zapier、webhook.site、requestbin 等公共服务。这样做成本低、部署快、隐蔽性也不差。因为这些平台本身可能是正常业务工具，企业网络很难仅凭访问域名就判断恶意。
第四类是反弹 shell 与远程控制。部分恶意包会在安装阶段尝试建立反向连接，通过 bash -i、nc、Python socket、pty 等方式让攻击者获得交互式访问。虽然这类行为比单纯窃密更容易被检测，但如果发生在开发者机器或构建环境中，后果同样严重。
第五类是「包名拼写仿冒」与「依赖混淆」。前者利用包名相似欺骗开发者，比如把热门包名字改一两个字符；后者则利用企业内部包名与公开仓库包名冲突，让构建系统误装攻击者上传的公开包。它们是真实风险，但并不是全部。现在更大的问题是，攻击者已经不只依赖「名字相似」，而是在利用整个开发工具链的默认执行机制。
三、为什么传统安全产品不容易拦住
这类攻击对传统安全体系很不友好。
原因很简单：恶意行为经常发生在合法进程里。node 执行脚本是正常行为，python 访问用户目录是正常行为，构建工具联网下载依赖也是正常行为。开发者机器访问 GitHub、npm、PyPI、Discord、Telegram、Slack，也未必异常。
换句话说，攻击者不是一定要绕过安全产品，而是躲进了安全产品最难下判断的灰色地带。
EDR 能看到进程行为，但很难区分某个安装脚本是在正常编译，还是在偷 .aws/credentials。网络检测能看到出站连接，但如果目标是 Telegram API 或 Discord Webhook，单看域名很难直接定性。SCA 工具能识别已知 CVE，但面对刚发布、尚未进入通告库的恶意包，往往存在时间差。
这就是供应链攻击的核心优势：它把恶意代码放进了开发者主动执行、工具链默认信任、企业安全策略经常放行的位置。
四、攻击目标已经从「偷密钥」扩展到「污染开发流程」
更值得警惕的是，恶意包的目标正在扩大。
过去我们主要担心它偷 token、偷云凭据、偷 SSH key。现在还要担心它污染 IDE 配置、AI 编程助手规则、项目级提示文件、Git hooks、CI/CD workflow。比如某些恶意包可能修改 .cursorrules、CLAUDE.md 之类的配置，让 AI 编程助手在后续开发中执行有风险的建议，或者在代码生成时悄悄引入后门逻辑。
这意味着供应链攻击不再只是一次性的窃密行为，而可能变成对开发环境的持续污染。攻击者拿到的不只是现有凭据，还可能影响开发者下一次写代码、下一次提交、下一次发布、下一次构建。
这类风险尤其适合在 AI 编程普及后放大。因为开发者越来越依赖自动补全、自动生成、自动执行脚本。如果项目目录本身已经被植入恶意规则，AI 助手就可能在不知不觉中成为攻击链的一部分。
五、防守重点：从「发现坏包」转向「识别坏行为」
面对这种趋势，单纯等待恶意包通告已经不够。等恶意包被公开标记时，可能已经有人安装过，凭据也已经被外传。
更有效的思路，是把检测前移到包进入开发环境之前。
- 第一，要建立依赖清单。企业需要知道开发者机器、CI/CD 流水线、构建容器中安装过哪些包、哪些版本、来自哪个生态。否则每次出现恶意包通告，都无法快速判断自身是否受影响。
- 第二，要扫描包结构，而不只是看 CVE。重点检查安装脚本、远程下载逻辑、硬编码 Webhook、敏感路径读取、反弹 shell 片段、混淆代码、可疑二阶段载荷等。很多恶意包并不高明，静态规则就能发现相当一部分。
- 第三，要限制安装阶段权限。理想状态下，安装依赖不应该默认读取用户家目录，不应该默认访问云凭据，不应该默认联网执行远程脚本。至少在 CI/CD 环境中，可以考虑禁用生命周期脚本、隔离构建环境、使用短期凭据、限制出站网络。
- 第四，要锁定依赖版本。不要让生产构建自动拉取最新版本，也不要让传递依赖在无人审查的情况下随意升级。lockfile、可复现构建、延迟升级、依赖审批，这些看似基础的工程纪律，在供应链安全中非常重要。
- 第五，要把 IDE 扩展和 AI 助手配置纳入治理。VS Code 扩展、Open VSX 扩展、Cursor 配置、Claude Code 项目文件、GitHub Actions workflow，都应该被视为开发供应链的一部分。它们不是边缘工具，而是攻击者正在盯上的新入口。
六、最后
软件供应链攻击正在进入「模板化」阶段。攻击者未必需要非常高端的漏洞利用能力，只要反复使用安装钩子、凭据扫描、Webhook 外传、反弹 shell、依赖混淆这些成熟组件，就能持续命中开发者和企业构建环境。
真正的问题不在于某一个包有多危险，而在于整个开发生态长期默认信任「安装即执行」「工具即可信」「依赖即安全」。这种默认信任，正是攻击者最喜欢的入口。
所以，供应链安全的重点不能只停留在「查 CVE」和「等通告」上，而要回到更基础的问题：谁能进入依赖链，谁能在安装阶段执行代码，谁能读取开发者凭据，谁能修改构建流程，谁能影响 AI 编程助手。
攻击者利用的是默认信任，防守方要建立的，就是默认验证。
