如何防止 Composer 项目遭受供应链攻击（supply chain attack）？

防止 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 供应链攻击 php js json 工具 ai