composer show 不能识别恶意包，它仅列出已安装包及版本，无安全扫描能力；真正识别需依赖 composer audit（比对 friendsofphp 安全数据库）并辅以人工核验包来源、脚本和文件行为。
composer show 命令能直接识别恶意包吗
不能。composer show 只列出已安装包及其版本，不包含安全扫描能力。它不会标记 laravel-zero/faker 这类曾被投毒的包（2023年真实事件），也不会提示 phpunit/phpunit 旧版中混入的后门变体。依赖列表本身是中性的，风险判断必须靠额外校验。
用 composer audit 检查已知漏洞和恶意包
composer audit 是 Composer 2.5+ 内置的安全检查命令，底层对接 packagist.org 的安全告警数据库（包括恶意包、供应链攻击记录）。它能识别已被报告的恶意包，比如 symfony/console 的伪造分支、monolog/monolog 的镜像劫持版本。
实操建议：
- 确保 Composer 版本 ≥ 2.5：
composer --version，低于则先运行composer self-update - 执行完整扫描：
composer audit --locked（检查composer.lock中实际安装的版本，比仅查composer.json更准确） - 若项目禁用 packagist.org 镜像或使用私有仓库，需确认
audit能访问官方安全数据源；可加-v查看请求详情 - 遇到
Warning: No security advisories found不代表安全，只说明 Packagist 当前未收录该包的风险报告——需人工交叉核对
配合第三方工具补全盲区
composer audit 依赖社区上报，对新出现的恶意包存在滞后性（平均 12–72 小时）。此时需补充静态分析手段：
推荐组合：
- 用
composer show --tree快速定位可疑包：关注名字仿冒主流库（如laravel-support、phpmailer-pro）、作者非官方组织（github.com/user123而非github.com/laravel） - 手动检查
vendor/下包的composer.json：重点看source或dist的 URL 是否指向非 GitHub/GitLab 官方域名，或含可疑路径（如/malware/、/build/） - 用开源工具
security-checker（Symfony 提供）或roave/security-advisories（强制阻止已知危险版本安装）作辅助验证
为什么 audit 有时不报已知恶意包
常见原因不是命令失效，而是匹配逻辑限制：
- 包名未被 Packagist 收录进安全数据库（例如小众 fork 包、内部私有包）
- 恶意行为藏在
autoload的脚本中（如post-install-cmd执行远程下载），audit不解析执行逻辑 -
composer.lock锁定的是 dist ZIP 包，但某些攻击会篡改 vendor 解压后的文件——此时需用composer install --dry-run对比哈希，或用sha256sum vendor/*/*/*.php | grep -E "(eval|base64_decode|file_get_contents)"快速筛可疑函数调用
真正危险的不是“audit 报错”，而是 audit 安静通过却仍存在定制化投毒——得盯住包来源、构建流程、运行时行为三个层面。
