composer audit 命令直接查出 composer.lock 中已安装包对应 packagist 安全告警数据库（security-advisories）收录的已知漏洞，不扫描源码、运行时行为或未 lock 的 dev 依赖（除非加 –dev）。
composer audit 命令能直接查出哪些漏洞？
它只检查 composer.lock 中已安装的包，不扫描源码或运行时行为，也不覆盖未 lock 的 dev 依赖（除非加 --dev）。底层调用的是 Packagist 的安全告警数据库（security-advisories），所以结果和 FriendsOfPHP/security-advisories 同源。
常见错误现象：执行 composer audit 返回 “No security vulnerability detected”，但实际项目里有已知高危漏洞——大概率是没生成或没更新 composer.lock，或者用了私有仓库且未配置安全源。
- 必须确保
composer install或composer update已成功运行并生成/更新了composer.lock - 私有包需在
composer.json的repositories中显式声明，并确认其元数据包含security-advisories兼容字段 - 若项目长期未
update，audit 可能漏掉新披露但尚未被旧 lock 文件记录的漏洞（因为 lock 锁死的是旧版本）
如何让 audit 输出更实用的信息？
默认输出只列 CVE 编号和包名，很难定位到具体哪一行代码受影响。加 --format=json 或 --severity=high,critical 能快速聚焦风险等级；加 --no-dev 可排除开发期依赖干扰生产环境评估。
使用场景：CI 流水线中自动拦截高危漏洞，或交接项目时快速摸底第三方风险。
-
composer audit --severity=critical：只看最高危项，适合紧急响应 -
composer audit --format=json | jq '.advisories[] | select(.severity == "critical")'：配合jq提取关键字段（需提前装 jq） -
composer audit --dev：检查require-dev中的漏洞，比如测试工具链里的反序列化问题
audit 报错 “Could not fetch advisories” 怎么办？
这是网络或配置问题，不是项目本身的问题。Composer 默认从 https://packagist.org 拉取安全通告，如果公司内网屏蔽了该域名，或用了镜像源但镜像未同步安全数据，就会失败。
错误信息示例：Could not fetch advisories: curl Error 7: Failed to connect to packagist.org port 443
- 先试
curl -I https://packagist.org确认基础连通性 - 检查是否设置了
COMPOSER_REPO_PACKAGIST环境变量或repositories.packagist.org配置，有些镜像站（如阿里云）不提供安全通告接口 - 临时切回官方源：
composer config --global repo.packagist.org composer https://packagist.org
audit 和 require –update-with-dependencies 有什么关系？
audit 不会升级任何包，它只是“照镜子”。真正修复漏洞靠的是 composer update，但要注意：直接 update 可能破坏兼容性，尤其当漏洞在次级依赖（transitive dependency）里时。
参数差异明显：composer update foo/bar 只升指定包；composer update foo/bar --with-all-dependencies 会连带升级其所有子依赖，更可能命中修复版本。
- 先用
composer audit --direct看直系依赖漏洞，优先处理 - 对间接依赖，用
composer depends vendor/package定位谁引入了它，再决定是升级上游还是加replace规则 - 某些 CVE 修复需要 PHP 版本 ≥8.1，别只盯着 Composer 版本，漏看
php自身限制
audit 的结果永远滞后于真实世界的新漏洞披露节奏，而且它不检测逻辑漏洞、硬编码密钥、或你手写的 sql 拼接——那些得靠人工审计或 SAST 工具补位。