什么是Composer的供应链攻击？如何有效防范？

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"）

运行时和权限必须收紧

就算装了坏包，也要让它动不了：

标签： php js git json composer github 工具