开发者电脑，正在成为软件供应链的新战场

过去我们谈软件安全，最常想到的是服务器漏洞、数据库泄露、接口鉴权、云服务权限配置。

但最近越来越明显的一个趋势是：攻击者正在把目标前移，不再只盯着线上系统，而是开始盯上开发者的电脑、依赖包、IDE 插件、CI/CD 流水线和开源仓库。

换句话说，软件还没上线，风险可能已经进入了项目。

开源依赖不再只是“工具”，也是攻击入口

现代软件开发离不开开源生态。

前端项目要装 npm 包，Python 项目要用 PyPI，PHP 项目依赖 Packagist，Java 项目离不开 Maven，甚至编辑器里还会装各种插件。开发效率确实提高了，但代价是：一个项目可能间接依赖几十、几百甚至上千个第三方组件。

只要其中某个包被劫持，或者某个维护者账号被盗，风险就可能顺着依赖链传递到大量项目里。

最近几个月，软件供应链攻击的频率明显升高。SecurityWeek 报道称，2026 年 6 月初，新一轮 Shai-Hulud 相关攻击影响了 100 多个 npm 和 PyPI 包。 Palo Alto Networks Unit 42 也提到，2026 年 6 月 1 日，攻击者曾通过受影响的 GitHub 账号波及 Red Hat Cloud Services 命名空间下至少 32 个 npm 包，这些包平均每周下载量约 8 万次。

这说明一个问题：开源依赖已经不是简单的“引入代码”，而是把别人的发布流程、账号安全、构建环境也一起带进了自己的系统。

最危险的不是代码运行时，而是安装时

很多人以为，一个依赖包只有在项目真正 import、调用、运行时才有风险。

但供应链攻击更麻烦的地方在于，有些恶意代码可能在安装阶段就执行。Sonatype 在分析 PolinRider 相关 npm 包时就提醒，install-time malware 特别危险，因为包还没有被业务代码引用，开发者电脑、构建机器、CI/CD 环境就可能已经暴露。

这对开发者来说很容易被忽视。

比如你只是执行了一次 npm install，只是想本地跑一下项目，甚至只是试用一个开源 demo，就有可能把风险带进本地环境。更麻烦的是，开发者电脑往往保存着很多敏感信息：GitHub token、SSH key、云服务密钥、数据库连接配置、npm 或 Docker 登录凭证。

所以现在的供应链攻击，真正盯上的不一定是最终用户，而是开发者本身。

因为拿到开发者环境，往往就等于拿到了进入更多系统的钥匙。

IDE 插件和浏览器扩展也变成风险点

过去大家比较关注依赖包，但现在 IDE 插件、浏览器扩展也越来越值得警惕。

TechRadar 最近报道提到，开发者设备正在成为软件供应链攻击中的盲区，攻击者可能通过浏览器扩展、IDE 插件、恶意依赖包或自动更新机制进入开发环境。 这类风险很现实，因为开发者通常会给工具比较高的信任权限。

一个 VS Code 插件可能读取项目目录。

一个浏览器插件可能接触登录状态和网页内容。

一个本地调试工具可能接触环境变量。

一个构建插件可能进入 CI/CD 流水线。

这些工具本来是为了提高效率，但一旦被劫持，就会变成很隐蔽的攻击入口。

这也解释了为什么现在越来越多安全事件不是“服务器被直接打穿”，而是“开发链路先被污染”。

软件供应链攻击为什么越来越多？

我觉得主要有三个原因。

第一，开源生态太庞大了。npm、PyPI、Packagist 这类生态每天都有大量包发布和更新，人工审核几乎不可能覆盖所有内容。OpenSSF 的一篇材料提到，PyPI 在 2026 年每天新增接近 900 个包。 当生态越来越大，攻击者混入其中的机会也会变多。

第二，开发流程越来越自动化。以前发布软件可能需要人工打包、审核、部署。现在很多项目是依赖自动构建、自动测试、自动发布。一旦攻击者拿到某个 token 或发布权限，就可能快速污染多个包或仓库。

第三，开发者越来越依赖工具链。代码补全、自动生成、插件市场、模板项目、脚手架、CI/CD、容器镜像，这些工具都能提升效率，但也会扩大攻击面。

这不是说开源不好，也不是说自动化不好，而是说明：开发效率越高，安全边界就越需要重新设计。

对个人开发者有什么启发？

很多人会觉得供应链攻击是大公司才需要考虑的事，个人博客、小项目、学习项目没必要这么紧张。

但我觉得个人开发者更应该有基本安全意识。

因为个人项目通常没有专业安全团队，也没有严格审计流程。你可能会随手复制一段安装命令，随手试一个 GitHub 项目，随手装一个 VS Code 插件，随手把 .env 放在项目目录里。大公司至少还有流程兜底，个人开发者很多时候只能靠习惯自保。

比较实用的做法有几条。

第一，少装不必要的依赖。一个小功能能自己写，就别为了几行代码引入一个庞大依赖。

第二，安装依赖前看一下包的维护状态。关注下载量、更新时间、仓库活跃度、issue 情况，不要随便用陌生小包。

第三，锁定依赖版本。前端项目至少要保留 lock 文件，避免每次安装都拉到不可控的新版本。

第四，把敏感信息和项目代码隔离。.env 不要提交，token 权限尽量最小化，用不到的密钥及时删除。

第五，CI/CD 里的密钥要谨慎。部署 token、云服务器 SSH key、镜像仓库密码都应该按最小权限配置，不要一个 key 管所有事情。

第六，插件不要乱装。特别是来历不明、更新很频繁、权限很大的 IDE 插件和浏览器扩展，要尽量克制。

这些动作看起来普通，但真正能降低很多风险。

未来的软件安全，会更重视“开发前线”

以前安全更多发生在上线后：漏洞扫描、WAF、防火墙、日志审计、告警监控。

但现在，安全正在往开发阶段前移。

Packagist 官方在 2026 年 5 月的文章中也提到，公开审计日志、强制 MFA、不可变发布、构建来源证明和签名证明等机制，已经成为多个包管理生态正在推进的方向。 这说明主流开源生态已经意识到，不能只靠开发者自己小心，平台层面也必须提供更强的保护。

未来比较理想的状态，应该是：

包发布要有更强身份验证。

依赖更新要有更清晰的风险提示。

构建产物要能追溯来源。

CI/CD 权限要默认最小化。

开发工具要能识别异常行为。

安全不应该只在最后上线前检查，而应该从安装依赖的第一步就开始。

我的判断

软件供应链安全会成为未来几年开发者绕不开的话题。

原因很简单：现代软件不是一个人从零写出来的，而是由无数依赖、插件、脚本、镜像、流水线和云服务拼起来的。我们享受了开源和自动化带来的效率，也必须接受它带来的复杂性。

对普通开发者来说，不需要因为这些新闻就对开源产生恐惧，但要改变一个习惯：不要再把依赖包、插件和安装脚本当成完全无害的东西。

每一次 npm install、每一次装插件、每一次复制运行命令，本质上都是一次信任决策。

以前我们写代码，重点是功能能不能跑。

以后我们写代码，还要多问一句：

这段代码和它背后的依赖，真的值得信任吗？