Composer依赖混淆攻击是通过配置错误或网络劫持使composer install/update从非官方仓库拉取同名恶意包，防护需启用secure-http、preferred-install dist，严格校验composer.lock哈希并禁用生产环境动态更新。
Composer 依赖混淆攻击是什么
它不是 Composer 自身漏洞，而是你执行 composer install 或 composer update 时，从错误源拉取了同名但恶意的包。比如你本想装 monolog/monolog，却因配置或网络劫持，实际装了私有仓库里一个伪造的 monolog/monolog（版本号相同、签名不同）。这种攻击依赖于 Composer 的包解析逻辑和仓库优先级规则。
如何确认当前项目用的是可信仓库
Composer 默认只信任 packagist.org，但一旦你加了私有仓库（尤其是 type: "composer" 的镜像或内部源），就可能被混淆——尤其当私有源未启用 provider-includes 或未校验 providers 签名时。
- 运行
composer config repositories查看所有注册仓库，重点检查是否有非官方的type: "composer"源 - 确认
packagist.org是否被显式禁用：composer config packagist false是高危操作，应避免 - 若使用私有源，确保它启用了
providers-api并返回带signature的 provider 列表（Packagist 官方镜像支持，很多自建 Satis 不支持）
必须开启的两项安全配置
这两项不依赖外部服务，但默认关闭，开了才能让 Composer 校验包来源真实性：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 启用
secure-http：强制所有仓库使用 HTTPS，防止中间人篡改元数据。composer config secure-http true - 启用
preferred-install+sort-packages配合composer.lock锁定哈希：composer config preferred-install dist（避免从源码安装不可信 git 分支）
注意：composer.lock 中每个包的 dist.shasum 字段是关键防线——只要没被手动删改，就能在下次 install 时比对下载文件是否一致。
CI/CD 和生产环境必须做的三件事
本地开发不易察觉混淆，但 CI 流水线和线上部署是重灾区：
- CI 中执行
composer install --no-dev --prefer-dist --optimize-autoloader，并确保COMPOSER_AUTH环境变量未泄露私钥到日志 - 上线前校验
composer.lock的完整性：用composer validate --strict检查格式+哈希，再用sha256sum composer.lock对比预发布版本 - 禁止在生产服务器上运行
composer update；所有依赖变更必须在 CI 中生成新composer.lock，再同步到线上
最常被忽略的一点：很多人以为加了私有仓库就“更安全”，其实反而扩大了攻击面——只要一个私有源被入侵或配置错误，所有依赖都可能被掉包。真正的防护不在“多加源”，而在“锁死路径+验证哈希+切断动态更新”。
