composer audit 无法检测新安全补丁，因其仅查询 Symfony 静态漏洞库（advisories.json），不实时同步Packagist/GitHub、不对比版本差异、不解析语义化补丁关系，且覆盖范围有限、存在延迟。
Composer 自带的 composer audit 命令并不能检测“新的安全补丁”——它只检查已安装依赖是否在 Symfony Security Advisory Database 中被标记为存在已知漏洞，且仅限于 Symfony 官方维护的漏洞数据源。
为什么 composer audit 查不到新补丁？
该命令本质是查询 Symfony 的静态漏洞库（JSON 文件），不是实时连接 Packagist 或 GitHub 检查最新 tag/patch 版本。它不对比当前安装版本与最新可用版本之间的差异，也不识别“v1.2.3 修复了 v1.2.2 的 CVE-2024-xxx”这类语义化补丁关系。
-
composer audit不会告诉你 “monolog/monolog有 v3.5.1 补丁发布了”，只会告诉你 “你装的 v3.4.0 在漏洞库中被标记为受影响” - 漏洞库更新有延迟，新披露的 CVE 可能数小时到数天后才同步进
https://www.php.cn/link/418140029d08ec9365aebdc9542616a0/advisories.json - 大量非 Symfony 生态包（如
guzzlehttp/guzzle、laravel/framework）的漏洞可能未被收录或标记不全
composer audit 的实际使用方式
运行前确保已启用安全插件（Composer 2.5+ 默认内置，旧版需手动安装 composer require --dev symfony/security-checker）：
composer audit
常见输出示例：
Security vulnerability found in monolog/monolog (v2.8.0) * CVE-2023-46805: Log injection via crafted log message * Upgrade to version ^2.9.0, ^3.0.0 or higher
- 输出中明确列出包名、当前版本、CVE 编号、简要描述和建议升级范围
- 加
--format=json可用于 CI 流水线解析：composer audit --format=json - 加
--no-dev跳过开发依赖检查（避免误报） - 若无输出，不代表绝对安全，只代表“未在 Symfony 漏洞库中命中”
真正想发现“新补丁”，得靠组合动作
检测是否有更新的安全补丁，核心是比对本地版本与上游最新稳定 patch 版本，并确认 changelog/CVE 是否覆盖修复：
- 用
composer outdated --minor-only --patch-only筛出可平滑升级的补丁版本（如从1.2.2 → 1.2.3），再人工查对应 release notes - 结合
composer show vendor/package查看source字段，跳转 GitHub 仓库 → 翻releases或security.md - CI 中可搭配 Dependabot 或 Trivy（支持 PHP Composer 锁文件扫描）做主动补丁监控
- 注意：有些包（如
phpunit/phpunit）的 patch 版本可能只修测试逻辑，不涉及运行时安全 —— 得看 commit diff 或 CVE 描述范围
容易被忽略的关键点
很多人以为 composer audit 是“自动打补丁开关”，其实它连 composer update 都不触发。更隐蔽的问题是：
- 锁文件
composer.lock中的dist.shasum不校验安全性，只保完整性；被投毒的包即使哈希一致，audit 也发现不了 - 私有包、fork 包、
vcs类型仓库完全不在 Symfony 漏洞库覆盖范围内 -
composer audit不检查扩展层（如ext-redis、gd）或 PHP 本身版本漏洞 —— 这些得靠php -v和 PHP 官方支持周期 手动核对
