Composer本身不防供应链攻击，防住靠主动设检查关卡：运行composer config repositories查注册源、composer config packagist确认是否禁用官方源、composer show --tree扫可疑包；composer.lock不锁来源，需提交Git并禁用--no-lock；签名验证需Composer 2.5+且作者已签名，通过composer config -g security.signature-verification true开启并用composer show --security验证生效。
Composer 本身不防供应链攻击，它只负责按配置拉包——防住攻击靠的是你主动设的几道检查关卡。
怎么确认当前项目正在用可信仓库
Composer 默认只认 packagist.org，但一旦你在 composer.json 里加了 repositories，信任链就变长了。运行以下命令快速摸清底细：
-
composer config repositories—— 查所有注册源，重点看有没有非官方的type: "composer"条目 -
composer config packagist—— 输出false是高危信号，说明你手动关掉了官方源 -
composer show --tree | head -20—— 扫一眼依赖树顶层，有没有名字可疑的包（比如guzzie、laravell）
私有源不是更安全，而是扩大了攻击面：Satis 镜像若没启用 provider-includes 或返回带签名的 provider 列表，它就只是个“缓存”，不提供任何校验能力。
为什么 composer.lock 不是万能的
composer.lock 锁的是版本和 dist.shasum，但它不锁来源。如果攻击者污染了你的 lock 文件（比如篡改 dist.url 指向恶意 ZIP），或你在 CI 中用了 --no-lock，那这层防护就直接失效。
- 必须把
composer.lock提交进 Git，且禁止.gitignore忽略它 - CI 流水线中始终用
composer install --no-dev --prefer-dist --optimize-autoloader，不走 source 安装 - 上线前跑
composer validate --strict+sha256sum composer.lock对比预发布版本哈希 - 绝对不在生产服务器上执行
composer update—— 所有变更必须在 CI 中生成新 lock 文件再同步
签名验证（signed packages）怎么真正起作用
Composer 2.5+ 默认启用签名验证，但前提是包作者真签了、你本地也开了开关。低于 2.5 的版本不支持 security.signature-verification，强行配会报错 Unknown configuration setting "security.signature-verification"。
- 全局开启：
composer config -g security.signature-verification true - 验证是否生效：
composer show --security输出含Signature verification: enabled才算成功 - 注意：只有 Packagist.org 上托管、且作者手动启用「signed packages」的包才受保护；私有仓库需额外配
signing-key或启用仓库级签名策略 - 企业关键组件（如
web-token/jwt-framework、paragonie/random_compat）建议强制签名："require-signature": true加进composer.json
CI 和生产环境最容易漏掉的三件事
本地开发很难触发混淆或投毒，问题总在自动化流程里爆发。最常被跳过的其实是权限控制和元数据校验。
- CI 中确保
COMPOSER_AUTH环境变量不打日志、不泄露私钥 —— Artifactory 用户尤其注意别开 “Bypass checksum storage”，否则等于关掉 shasum 校验 - Git 源默认走
source（clone），跳过shasum校验；强制走dist要在repositories里加"no-api": true，并确认服务端提供 dist 元数据 - 禁用 root 权限运行 Composer：用
sudo -u appuser composer install，而不是直接sudo composer install—— 恶意 post-install-cmd 脚本拿到 root 就等于拿下整台机器
签名、锁文件、仓库白名单，这三样缺一不可。但最麻烦的其实是持续维护：没人会天天去翻 composer show --tree，所以得靠 CI 自动跑 composer-audit 或集成 SCA 工具，把异常包当构建失败拦下来。
