Composer audit 从 v2.5.0 起可用，低版本需升级；其仅基于 FriendsOfPHP 安全数据库检测已安装包版本，不分析代码调用，且不覆盖非 Packagist 包或系统依赖。
composer audit 命令不生效？先确认 Composer 版本
Composer 自带的 audit 功能从 v2.5.0 才正式引入，低于这个版本运行会直接报错 Command "audit" is not defined。别急着查文档或重装，先看版本：
composer --version —— 如果输出是 Composer version 2.4.x 或更低，audit 就不可用。
- 升级到最新稳定版：
composer self-update - 若项目受限于旧 PHP 版本（如 PHP 7.2），可能无法升到 v2.5+，这时得换方案：用
composer outdated --security（需启用security-advisories插件） - v2.5+ 默认启用安全检查，但依赖本地缓存；首次运行可能稍慢，后续会快很多
audit 报出一堆 CVE，但项目没用到对应函数？别急着升级
composer audit 检查的是已安装包的版本是否在已知漏洞数据库中被标记，它不分析代码调用链，也不判断你是否真用到了有漏洞的路径。所以常见现象是：报告了 CVE-2023-1234，但你的代码里根本没调 SomeVulnerableClass::doBadThing()。
- 先看报告里的
advisory ID（如symfony/cve-2023-1234），去 FriendsOfPHP/security-advisories 查原始描述，重点关注「Affected versions」和「Exploitation conditions」 - 有些漏洞只影响特定配置（如开启 debug 模式、使用某扩展）、特定运行环境（如 CLI vs web SAPI），或需要用户可控输入配合 —— 这些都得人工评估，不能光看红字就 panic
- 盲目升级可能引入 BC break；建议先写最小复现脚本，验证漏洞是否真能在你的用法下触发
CI/CD 中自动执行 audit，为什么经常失败？
在 GitHub Actions 或 GitLab CI 里加 composer audit 后，流水线频繁失败，不是因为真有高危漏洞，而是默认策略太激进：只要发现任意一条 advisory（包括 low 级别、过时多年、无实际利用路径的），就返回非零退出码。
- 控制严格程度用
--format=json+ 自定义解析，或直接加--no-dev（避免开发依赖干扰） - 更实用的做法是限定严重等级：
composer audit --severity=high --severity=critical—— 注意--severity可多次出现，但不支持medium或low（它们不会中断命令） - 网络问题也会导致失败：audit 默认查远程
security-advisories数据库，CI 环境若无外网或 DNS 不稳，会卡住或超时；可加--no-interaction --timeout=30控制
audit 显示 “No security vulnerabilities found”，但 SCA 工具（如 Snyk）却报出问题？
这是数据源差异导致的。Composer audit 完全依赖 FriendsOfPHP/security-advisories 这个社区维护的 JSON 列表，而 Snyk、GitHub Dependabot 等还整合了 NVD、OSV、厂商通告等更多渠道。
- FOHP 数据库更新有延迟，尤其对新披露的漏洞，平均滞后 1–3 天；CVE 编号刚发布时，audit 很可能查不到
- FOHP 只收录“已被确认且有修复版本”的 PHP 包漏洞，像 C/C++ 依赖（如 ext-mysqlnd 底层）、系统库、或未打包进 Packagist 的私有包，audit 一律不覆盖
- 如果你用的是私有仓库或 fork 包，audit 无法识别其版本映射关系 —— 它只认
vendor/name和官方 Packagist 上的 release tag
真正关键的不是工具报没报，而是你是否清楚自己用的每个包，在什么条件下、以什么方式参与了数据处理。审计工具只是提醒器，不是保险丝。
