composer audit 是 Composer 2.5.0+ 内置的安全检测命令，严格依赖 composer.lock 的精确版本和哈希，不分析代码或运行时环境；低于 2.5.0 版本会报“Command not defined”，需先升级 composer self-update。
composer audit 是当前最直接、最轻量的 Composer 安全检测方式，但它不是万能扫描器——它只比对 composer.lock 中已安装的包版本与 Symfony 安全数据库（FriendsOfPHP/security-advisories）的匹配项，不分析代码、不查 CVE 原始库、也不做运行时环境判断。用错版本、锁文件不准、网络配置不对，都会让它“装作没看见”真实漏洞。
为什么 composer audit 报 “Command ‘audit’ is not defined”
这不是插件没装，是 Composer 版本太低。该命令从 2.2.0 开始内置，但真正稳定可用、默认启用安全数据库同步的是 2.5.0+。低于这个版本，命令根本不存在。
- 检查当前版本：
composer --version—— 若输出为2.4.x或更低，必须升级 - 升级命令：
composer self-update（确保已配国内镜像，否则易卡在 TLS 握手） - 验证是否生效：
composer list | grep audit应能看见audit行 - 企业环境若因 PHP 7.2 等旧版本无法升到
2.5+，roave/security-advisories也救不了——它只拦安装，不扫已存在的包
composer audit 扫的是 vendor/ 还是 composer.lock？
它严格依赖 composer.lock 中记录的**精确安装版本和哈希值**，不是看 vendor/ 目录里“看起来像”的文件，也不读 composer.json 里的模糊约束（如 "^3.0"）。
- 你改了
composer.json但没运行composer install，audit就不会反映潜在风险 - 本地
vendor/是手动拷贝或git clone进来的，composer.lock缺失或哈希不匹配 →audit结果为空或漏报 - 私有包必须在
composer.json的repositories中显式声明，且元数据需支持security-advisories字段，否则不参与扫描 - 临时验证方法：删掉
vendor/和composer.lock，重新composer install再跑composer audit
CI 流水线里 composer audit 总失败，怎么办？
不是漏洞多，是默认策略太激进：只要发现任意一条 advisory（哪怕 low 级别、5 年前的条目），就返回非零退出码，导致流水线中断。这不是 bug，是设计如此——但你不该让它这么用。
- 生产环境卡点建议：
composer audit --severity=critical --severity=high --no-dev，只关注真正可利用的高危项 - 网络不稳定时加超时：
composer audit --no-interaction --timeout=30，避免因拉不到安全库而卡住 - 想让结果可解析：
composer audit --format=json | jq '.advisories[] | select(.severity == "critical")'（需提前装jq） - 注意：
--ignore-severity=low在部分旧版2.5.x中不生效，优先用--severity=显式指定
composer audit 报了 CVE，但项目根本没调相关代码，还要处理吗？
要，但得先人工评估。它不分析调用链，只告诉你“这个版本被公开标记为存在某漏洞”，是否真影响你的场景，得看原始 advisory 描述里的 Affected versions 和 Exploitation conditions。
- 有些漏洞只在特定配置下触发（如开启
debug模式、启用gd扩展） - 有些需用户可控输入配合（如反序列化入口 + 恶意 payload）
- 有些仅影响 CLI SAPI，你的项目跑在 FPM 下就无感
- 盲目升级可能引入 BC break；建议先写最小复现脚本，验证漏洞是否真能在你的用法下触发
最常被忽略的一点：audit 不自动修复，也不提示怎么修。它只告诉你 doctrine/dbal (cve-2023-30518)，但不会说“请运行 composer update doctrine/dbal --with-all-dependencies”。修复动作必须手动触发，且要确认新版本是否兼容现有代码——这一步，工具永远替代不了人。
