确保 Composer 依赖可信需控制源头、验证完整性、持续监控风险：仅用官方 Packagist，禁用不可信仓库与插件，启用 composer audit，提交并依赖 composer.lock，人工评估维护者与包健康度。
确保 Composer 安装的依赖包来源可信，核心在于控制源头、验证完整性、持续监控风险。这不是一次性的操作，而是贯穿开发与部署的持续实践。
只从官方 Packagist 和已知可信源加载包
Packagist.org 是 Composer 默认且最主流的包仓库，它本身不托管代码，而是索引 GitHub、GitLab 等平台上的公开仓库。虽然开放，但具备基础审核机制（如自动扫描明显恶意文件）。关键是你得避免手动添加不可信的自定义仓库（repositories）。
- 检查
composer.json中是否含有非官方type: "composer"的repositories配置，尤其警惕域名生僻、无 HTTPS、无明确维护者信息的源 - 生产项目尽量禁用
allow-plugins: false或显式白名单插件，防止恶意插件在安装时执行任意代码 - 如需私有包，优先使用企业级私有仓库（如 Satis、Private Packagist、GitHub Packages），并配合身份认证和访问审计
启用并定期运行安全检查（Security Audit）
Composer 自带 composer audit（v2.5+）命令，底层调用 Symfony Security Checker API 或本地 CVE 数据库，能快速识别已知漏洞。
- 在 CI 流程中加入
composer audit --no-dev --format=json | jq '.advisories | length > 0' && exit 1 || exit 0实现自动化阻断 - 对历史项目，先运行
composer update --dry-run再audit，避免直接升级引发兼容问题 - 注意：audit 不检测供应链投毒（如恶意 maintainer 推送新版本），仅覆盖已公开披露的 CVE
锁定依赖哈希值，防止下载篡改
composer.lock 文件不仅记录版本，还包含每个包 ZIP 归档的 SHA-256 哈希值。只要 lock 文件未被恶意修改，Composer 就会校验下载内容一致性。
- 务必把
composer.lock提交到版本库（禁止 .gitignore 掉） - 部署时使用
composer install（而非update），强制按 lock 文件还原，跳过远程版本解析 - 可手动验证：运行
composer show vendor/package --all查看实际安装的 commit hash 和 dist reference，比对是否与 lock 中一致
关注维护者行为与包健康度
技术手段无法替代人工判断。一个包即使没爆 CVE，也可能因维护者失联、代码质量滑坡或突然引入可疑功能而变得高危。
- 安装前查看 Packagist 页面的 “Source” 链接，确认 GitHub/GitLab 仓库 star 数、最近 commit 时间、issue 响应速度
- 用
composer show -t查看依赖树，警惕深度嵌套、多层间接依赖中出现的冷门包（它们更可能被忽视） - 订阅关键包的 GitHub Releases 或 Packagist 更新通知，对突然发布的 v1.0.0 或跨大版本更新保持谨慎
基本上就这些。不复杂但容易忽略——关键是把验证动作变成习惯，而不是等出事才补救。
