Composer 2.5+ 自带 composer audit 命令，用于扫描 vendor/ 中已安装包的 CVE 漏洞，需升级后启用，不依赖网络，不检查 dev-only 包（除非加 --with-dev），默认不启用且不读 composer.json。
Composer 自带 composer audit（v2.5+）能直接查已安装包的已知安全漏洞，不需要额外插件——但默认不启用，且老版本得用 composer security-check 插件，现在基本过时了。
composer audit 能查什么、怎么启用
它基于 Symfony Security Checker 的数据源，扫描 vendor/ 中所有已安装包的 CVE 和公开漏洞报告。前提是你的 Composer 是 2.5.0 或更高版本。
- 运行前先升级：
composer self-update，确认版本 ≥ 2.5.0（composer --version） - 直接执行：
composer audit，会列出所有含已知漏洞的包及对应 CVE 编号 - 想看更详细信息（比如哪个版本修复了）：加
--format=full参数，即composer audit --format=full - CI 环境里想失败退出（用于流水线卡点）：加
--fail-on-security-violations
为什么有时 audit 没报错，但实际有漏洞
常见不是工具不准，而是扫描范围或锁文件状态没对齐。
-
composer audit只检查vendor/里真实安装的包，不读composer.json的声明版本 —— 如果你改了composer.json但没composer install，audit 就看不到“潜在风险” - 某些漏洞只影响特定 PHP 版本或扩展组合（比如需启用
gd才触发），audit 不做运行时环境检测，只看 CVE 公开描述是否匹配包名+版本 - 新爆出的漏洞可能还没同步进 Symfony 安全数据库（通常几小时到一天延迟），此时 audit 会漏报
audit 和第三方工具（如 safety、deps.dev）的区别
别混用，目标和粒度不同。
-
composer audit查的是「当前 vendor 目录中实际加载的包」，结果可直接对应到你的运行时依赖树 -
safety（Python 工具）或deps.devAPI 需要解析composer.lock，再查外部数据库，容易因锁文件格式变动或网络策略失败 - audit 不发请求到外部服务（离线可用），而
composer security-check插件（已废弃）是调远程 HTTP 接口，现在默认禁用 - audit 不检查 dev-only 包（除非你加
--with-dev），这点常被忽略 —— 测试工具链里的漏洞也可能被利用（比如通过 CI 构建环节）
遇到 “Command ‘audit’ is not defined” 怎么办
说明 Composer 版本太低，别折腾插件，直接升级。
- 旧版（composer require --dev roave/security-advisories:dev-master 是无效的 —— 它只是阻止安装已知危险包，不提供扫描能力
- 不要装
composer/composer-security-checker这类废弃包，它早在 2021 年就停止维护，且与 Composer 2.x 不兼容 - 最小成本方案：用
curl -sS https://getcomposer.org/installer | php重装最新稳定版，再php composer.phar audit
真正要注意的不是“有没有漏洞”，而是“这个漏洞在你项目里是否可达”。audit 给出的 CVE 编号得去翻原始报告，看触发条件 —— 很多高危评级的漏洞，实际需要特定配置或用户输入才生效。
