Packagist 包签名验证需满足作者启用 signed releases 且本地开启 verify-signatures；全局配置 composer config --global security.signature-verification 返回 true 才生效，签名仅覆盖 dist 包，source 方式不校验。
如何确认 Packagist 上的包是否经过签名验证？
Composer 从 2.0 开始默认启用 composer/semver 和签名验证机制，但前提是包作者启用了「signed releases」且你本地开启了 verify-signatures。未开启时，composer install 完全不校验 GPG 签名，哪怕包本身已签名。
- 检查全局配置是否启用：
composer config --global security.signature-verification（返回true才生效） - 临时启用安装时校验：
composer install --verify-signatures，若失败会报错Signature mismatch或Missing signature for ... - 签名只覆盖
dist包（zip/tar.gz），source（git clone）方式不参与签名验证 - Packagist 本身不托管私钥，签名由 packagist.org 验证后打上
verified标签——但该标签仅表示“作者上传时附带了有效签名”，不代表 Packagist 审计过代码逻辑
为什么 composer require vendor/package 可能拉到恶意代码？
根本原因在于 Composer 默认信任 Packagist 的元数据源，而 Packagist 不强制要求作者验证邮箱或绑定 GitHub——只要注册邮箱能接收验证邮件，就能发布任意 vendor/name。攻击者常通过以下方式得手：
- 抢注废弃包名：原作者 abandon 后，新注册者可发布同名包，且
composer require优先取最新版本（即使^1.0也会升到恶意1.0.5） - 依赖混淆：发布
laravel/framework-fake这类形近包，靠开发者手误引入 - 供应链投毒：在
composer.json的scripts中嵌入post-install-cmd，执行curl | bash或写入 .env
验证手段有限：你无法单靠 composer show vendor/package 判断安全性，必须交叉核对。
手动验证包来源的三个关键动作
别只信 Packagist 页面上的「Source」链接，要确认它是否真实指向作者可控仓库，并与发布记录一致：
- 打开 Packagist 页面，点击
Source链接，检查 GitHub/GitLab 仓库的releases页 —— 每个 tag 是否有对应 GPG 签名？执行git verify-tag v2.3.1可验证（需提前导入作者公钥） - 比对
composer.json中的homepage、support.source和实际仓库 owner 是否一致；例如monolog/monolog的 source 是https://github.com/Seldaek/monolog，而Seldaek是原始作者 - 用
composer audit（Composer 2.5+）扫描已安装包：它会查 CVE 数据库 + Packagist 的已知漏洞标记，但不会检测未上报的零日投毒
composer audit --format=json | jq '.advisories[] | select(.severity == "critical")'
生产环境必须做的最小防护配置
光靠人工核对不可持续，需固化策略：
- 在
composer.json中锁定minimum-stability为stable，禁用dev-前缀版本，避免拉取未测试分支 - 使用
composer config --global repo.packagist.org.allow-plugins false禁用所有插件自动加载，防止恶意composer-plugin注入 - CI 流程中强制运行：
composer validate --no-check-publish（校验 JSON 结构） +composer outdated --direct --minor-only（只允许小版本升级） - 关键项目建议镜像私有 Packagist（如 Satis 或 Private Packagist），并只同步白名单仓库的指定 tag
最常被忽略的一点：Packagist 的「verified」徽章只说明签名存在，不说明私钥是否泄露、作者是否被钓鱼、或 CI 构建流程是否干净。真正的安全水位，取决于你控制构建链路和依赖更新节奏的能力。
