Composer供应链攻击是攻击者通过篡改第三方包（如发布恶意包、劫持账户、注入恶意URL）使composer install/update执行恶意代码；常见路径包括拼写错误包、盗用旧版本、Packagist漏洞、全局恶意插件及root权限滥用；防御需锁定来源与版本、收紧运行权限、加强监控审计，核心是将默认信任转为可验证、可限制、可回溯的动作。
Composer 的供应链攻击，是指攻击者通过篡改、伪造或污染 PHP 项目所依赖的第三方包（比如在 Packagist 上发布恶意包、劫持维护者账户、注入恶意 dist/source 地址），让 composer install 或 composer update 在不知情中拉取并执行恶意代码的过程。这类攻击不直接入侵你的服务器，而是“借道”你信任的依赖流程，在构建或部署阶段悄悄植入后门、窃取凭证、删除数据，甚至横向渗透。
搞清楚攻击怎么发生的
常见路径包括：
- 伪装成主流库的“拼写错误包”（如
guzzie冒充guzzlehttp/guzzle），靠手误安装 - 合法包的旧版本被作者账号盗用后植入恶意
post-install-cmd脚本 - Packagist 服务端漏洞（如参数注入）被利用，篡改元数据，将
dist.url指向攻击者控制的恶意 ZIP - 全局安装（
composer global require）恶意插件，导致所有项目运行时自动加载其代码 - 使用 root 权限运行 Composer，使恶意脚本获得系统级权限
锁定来源与版本是基础防线
别让依赖“自由生长”：
- 始终提交
composer.lock到 Git，禁止生产环境用composer update自动升版 - 在
composer.json中显式配置"repositories"，只允许官方 Packagist 或经审核的私有镜像（如 Private Packagist、Satis） - 企业可搭建带人工审核环节的私有 Packagist 镜像，新包入库前查签名、看 star 数、审 GitHub 提交历史
- 避免使用
"dev-master"或模糊版本约束（如"^1.0"），优先指定精确小版本（如"1.2.3"）
运行时和权限必须收紧
就算装了坏包，也要让它动不了：
- 永远不用 root 或 sudo 运行 Composer；普通用户权限足够，也符合最小权限原则
- 生产环境部署时加
--no-dev --prefer-dist：跳过开发依赖，只装压缩包而非源码，减少脚本执行面 - 禁用全局安装不可信包；检查
~/.composer/vendor/bin/下的命令是否都知情，目录权限设为700 - 定期运行
composer-unused或手动审计vendor/，删掉没被实际调用的包
把监控变成日常动作
安全不是设完就完，而是持续看见、及时响应：
- 启用 Dependabot 或 Renovate，自动监听 CVE 并 PR 更新建议
- 在 CI 流程中集成
composer-audit或 SCA 工具（如 Snyk、Dependabot CLI），扫描composer.lock中已知漏洞 - 订阅关键依赖的 Packagist 安全通告、GitHub Security Alerts 和 PHP 安全邮件列表
- 对高敏系统，考虑对 vendor 中的核心包做轻量沙箱测试（例如运行其测试套件+简单行为日志捕获）
本质上，Composer 供应链攻击 exploit 的是“信任默认化”——我们默认 Packagist 是可信的、包名是唯一的、版本号是安全的。防范的关键不是拒绝使用依赖，而是把每一层信任都变成可验证、可限制、可回溯的动作。精简、锁定、监控、降权，四件事做到位，风险就大幅收敛。
