composer audit 是 Composer 2.5+ 唯一官方安全检查命令，需确认版本≥2.5.0、composer.lock 存在、网络可达 Packagist 安全数据库；它不修复漏洞、不扫描源码、覆盖有限，应结合 Snyk 等工具补全。
composer audit 是唯一官方支持的依赖安全检查命令，但它不自动修复、不扫描源码、也不保证覆盖所有 CVE —— 用之前必须确认版本、锁文件、网络和数据源都就位。
怎么确认 composer audit 能用
执行 composer --version，输出必须是 2.5.0 或更高；低于这个版本会报错 Command "audit" is not defined。如果版本达标但 composer list | grep audit 没输出，可能是实验特性未启用：composer config --global experimental.audit true。某些精简版 phar（比如企业内网分发的定制包）可能压根没编译审计模块，这时只能换二进制或退回到 roave/security-advisories 插件兜底。
为什么 audit 没报漏洞，但项目其实有高危 CVE
常见原因有四个：
-
composer.lock文件不存在或过期 ——audit只读 lock，不看composer.json的约束；必须先跑composer install或composer update - 用了私有仓库但没在
composer.json的repositories里声明，或该仓库不提供security-advisories兼容字段 - 网络不通或镜像源不支持安全通告接口 —— 错误信息如
Could not fetch advisories: cURL error 7，可试curl -I https://packagist.org验证连通性，或临时切回官方源：composer config --global repo.packagist.org composer https://packagist.org - 漏洞不在 PHP-SECADV 数据库里 —— 这个库只收 Symfony/Drupal/Laravel 等主流生态确认过的条目，小众包或新披露未同步的 CVE 就查不到
怎么让 audit 输出真正有用的信息
默认输出太简略，定位和集成都很吃力：
- 聚焦风险等级：
composer audit --severity=critical,high，避免被 low/medium 干扰判断 - 排除开发依赖干扰生产评估：
composer audit --no-dev - 导出结构化数据供 CI 解析：
composer audit --format=json --no-dev，再配合jq '.advisories[] | select(.severity == "critical")'提取关键项（需提前装jq） - 忽略已知可控的漏洞（慎用）：
composer audit --ignore=CVE-2023-12345，但必须在代码注释或文档里写明豁免理由
audit 发现了漏洞，然后呢
它只提示，不升级、不降级、不改 composer.json：
- 修复动作仍是手动
composer update vendor/package，或指定版本composer update monolog/monolog:^2.9 - 如果当前
require约束太宽（如"monolog/monolog": "^2.0"），而修复版是2.9.0，update 才会拉进来；但如果约束锁死了"^1.25"，就算2.9.0已发布也不会命中 - 别指望
composer update自动绕过漏洞 —— Composer 不感知安全状态，只忠于版本约束 - CI 中建议叠加第三方扫描（如
snyk test --file=composer.lock --severity-threshold=high），因为 Snyk 覆盖更广，但注意它会上传composer.lock，私有项目要评估合规风险
最常被忽略的一点：即使 audit 返回 0，也只代表“没查到已知漏洞”，不代表项目安全 —— 它不校验许可证、不分析运行时行为、不检查 platform 包（如 ext-mbstring）、也不验证 PHP 版本兼容性。真要落地安全治理，得把它当起点，不是终点。
