composer audit 不是万能扫描器，它只比对 composer.lock 中已安装包版本与 friendsofphp/security-advisories 数据库的已知条目，不检测未锁住、私有、dev 分支或未入库的漏洞；报“command not defined”是因版本低于 2.5.0，需升级后验证；它严格依赖 composer.lock 的精确版本和哈希，不读 vendor/ 或 composer.json 模糊约束；ci 中应限定 --severity=critical,high --no-dev 避免误中断；结果需人工评估真实利用条件，且受数据库同步延迟影响。
composer audit 不是万能扫描器，它只比对 composer.lock 中已安装的包版本与 FriendsOfPHP/security-advisories 数据库里的已知条目——没锁住的、私有的、dev 分支的、或未同步进数据库的漏洞，它都看不到。
为什么执行 composer audit 报 “Command ‘audit’ is not defined”
这不是插件没装，是 Composer 版本低于 2.5.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插件也救不了——它只拦新装，不扫已存在的包
audit 扫的是 vendor/ 还是 composer.lock？
它严格依赖 composer.lock 中记录的**精确版本号 + 安装哈希值**，完全不读 vendor/ 目录内容，也不解析 composer.json 里的模糊约束（如 "^3.0"）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 改了
composer.json但没运行composer install→audit不会反映风险 - 手动拷贝
vendor/或git clone进来，而composer.lock缺失或哈希不匹配 → 结果为空或漏报 - 私有包必须在
composer.json的repositories中显式声明，且元数据需支持security-advisories字段，否则不参与扫描 - 临时验证：删掉
vendor/和composer.lock，重新composer install再跑composer audit
CI 流水线里 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） - 注意：
--severity可多次出现，但不支持medium或low（它们不会中断命令）
audit 报出 CVE，但代码根本没调用相关函数，还要修吗
要人工评估。它不分析调用链，只看版本是否落在漏洞影响范围内。
- 先查报告里的 advisory ID（如
symfony/cve-2023-1234），去FriendsOfPHP/security-advisories查原始描述，重点关注「Affected versions」和「Exploitation conditions」 - 有些漏洞只影响特定配置（如开启 debug 模式）、特定运行环境（CLI vs web SAPI），或需要用户可控输入配合
- 盲目升级可能引入 BC break；建议先写最小复现脚本，验证漏洞是否真能在你的用法下触发
- CI/CD 中若仅靠
audit卡点，容易误伤——真正关键的是你实际用了什么、怎么用的，不是“理论上可能被利用”
最常被忽略的一点：audit 的结果强依赖 Packagist 安全数据库的同步时效，通常延迟数小时到一天；而你本地 composer.lock 锁死的是旧版本，新披露但尚未被数据库收录的漏洞，它也看不见。
