composer audit 是 Composer 2.5.0+ 内置的轻量离线安全扫描命令，依赖 composer.lock 中精确版本与哈希，低于 2.5.0 版本会报“Command not defined”，因功能根本不存在；需用 composer self-update 升级，并通过 composer list | grep audit 验证。
composer audit 是唯一能直接、轻量、离线运行的 Composer 安全检测方式，但它只对 ≥2.5.0 版本有效；低于该版本会报 Command "audit" is not defined，不是配置问题，是功能根本不存在。
为什么 composer audit 报 “Command not defined”
这不是插件没装、镜像没配或权限不对，纯粹是 Composer 版本太低。该命令从 2.2.0 开始实验性引入，但直到 2.5.0 才默认启用并稳定同步安全数据库。
- 执行
composer --version，若输出为2.4.x或更低，audit命令不可用 - 升级必须用
composer self-update（确保有写权限）；若失败，改用官方安装脚本重装 - 企业环境若卡在 PHP 7.2 等旧版本，无法升到 2.5+，
roave/security-advisories也救不了——它只拦新装，不扫已存在包 - 验证是否生效：
composer list | grep audit应能看见audit行
composer audit 扫的是 vendor/ 还是 composer.lock？
它严格依赖 composer.lock 中记录的**精确安装版本和哈希值**，既不读 composer.json 的模糊约束（如 "^3.0"），也不看 vendor/ 目录里“看起来像”的文件。
- 你改了
composer.json但没运行composer install→audit不会反映潜在风险 - 本地
vendor/是手动拷贝或 git clone 进来的，composer.lock缺失或哈希不匹配 → 结果为空或漏报 - 私有包必须在
composer.json的repositories中显式声明，且元数据需支持security-advisories字段，否则不参与扫描 - 临时验证方法：删掉
vendor/和composer.lock，重新composer install再跑composer audit
CI 流水线里 composer audit 总失败，怎么办？
不是漏洞多，是默认策略太激进：只要发现任意一条 advisory（哪怕 low 级别、5 年前的条目），就返回非零退出码，导致流水线中断。这不是 bug，是设计如此——但你不该让它这么用。
- 加
--no-dev排除 PHPUnit、PHPStan 等开发依赖干扰 - 用
--severity=high --severity=critical限定卡点等级（注意：不支持medium或low卡点） - 加
--format=json配合jq或自定义脚本解析，避免靠人眼扫终端 - 网络不稳定时加
--no-interaction --timeout=30，防卡住；内网环境若屏蔽packagist.org，需确认镜像源是否同步安全数据库
发现漏洞后，为什么 composer update 不自动修复？
因为 Composer 不感知“安全状态”，它只忠实地满足 composer.json 中的版本约束。即使某个包 1.2.0 有 CVE，而 1.3.0 已修复，但你的 require 写的是 "foo/bar": "~1.0"，那 composer update foo/bar 可能只会升到 1.2.9——只要还在 ~1.0 范围内，就不会跳出。
- 真正有效的修复路径是：先看
audit输出里的advisory ID（如symfony/cve-2023-1234），去FriendsOfPHP/security-advisories查原始描述，确认Fixed in版本 - 再手动调整
composer.json中对应包的约束，比如从"^1.0"改为"^1.3"，然后composer update foo/bar - 别依赖
audit判断是否“真可利用”——它不分析调用链、不检查运行时配置（如是否启用了某扩展），这些都得人工评估
真正容易被忽略的是：审计结果的可信度完全绑定于 composer.lock 的时效性与完整性。一次没运行 composer install，一次手动替换 vendor/，一次私有仓库未声明 security-advisories 兼容字段，都会让 audit 失效——它不会报错，只会安静地漏报。
