防止 Composer 项目遭受供应链攻击，核心是控制依赖来源可信度、验证完整性、限制执行权限，并持续监控变更。需严格锁定依赖版本并验证哈希值，始终提交 composer.lock，禁用非官方仓库，启用包签名验证，结合静态扫描与行为监控形成闭环防护。
防止 Composer 项目遭受供应链攻击，核心是控制依赖来源可信度、验证完整性、限制执行权限，并持续监控变更。不是只靠“更新到最新版”，而是建立一套可信的依赖治理流程。
严格锁定依赖版本并验证哈希值
Composer 默认使用 composer.lock 锁定精确版本和依赖树，这是防篡改的第一道防线。但仅锁版本不够——攻击者可能入侵包仓库（如 Packagist）或发布恶意小版本（如 1.2.3 → 1.2.4），而 lock 文件若未及时提交或被绕过（如用 --no-lock），就会拉取恶意代码。
- 始终提交 composer.lock 到版本库，禁止忽略它
- 启用 composer install --no-dev 在生产环境，避免开发依赖引入风险
- 定期运行 composer validate 检查 lock 文件结构合法性
- 搭配 composer show --tree 审查深层依赖，识别隐藏的陌生包（如名字相似的 typosquatting 包）
只从可信源安装，禁用非官方仓库
Packagist 是默认且审核较严的源，但 Composer 允许通过 repositories 配置自定义源——这常被用于投毒。攻击者可能诱导你在 composer.json 中添加伪装成“加速镜像”或“内部包”的恶意仓库。
- 检查 composer.json 中的 repositories 字段，删除所有非官方、非公司内网认证的源
- 生产部署前用 composer config --global repos.packagist.org false 临时禁用 Packagist，再手动启用确保无覆盖
- 企业可部署私有 Packagist 镜像（如 Satis 或 Private Packagist），只同步白名单内的包和版本
启用签名验证（Signed Packages）
Composer 自 2.2 起支持包签名（signing），作者可用 GPG 私钥对发布包签名，你用公钥验证。这不是默认开启的，需主动配置。
- 要求团队关键包作者启用签名：运行 composer pubkey 导出公钥，加入项目 .composer/auth.json 的 "signing-keys"
- 在 composer.json 中设置 "require-signature": true，强制所有包必须签名才允许安装
- 注意：目前 Packagist 上签名包仍属少数，优先对核心安全组件（如加密、身份验证类库）启用
自动化扫描与行为监控
静态扫描不能替代人工审查，但能快速暴露高危模式。Composer 本身不提供运行时防护，需结合外部工具形成闭环。
- CI 流程中集成 phpstan-security 或 sensiolabs/security-checker（已归档，推荐换用 roave/security-advisories）检测已知漏洞包
- 用 composer outdated --direct 定期检查直接依赖是否陈旧，但别盲目升级——先看 changelog 是否含可疑修改
- 监控 vendor/ 目录文件哈希变化（如用 sha256sum vendor/**/* 2>/dev/null | sha256sum），异常变更可触发告警
基本上就这些。不复杂但容易忽略：锁文件要管、源要干净、签名要开、扫描要跑。真正的防护不在某一行命令，而在每次 composer require 前多问一句——这个包谁维护？怎么进来的？改过什么？
