Composer audit 报“高危漏洞”却无实际影响，因其仅按版本号匹配 CVE，不分析调用链或运行环境；误报常见于 dev 包、冷门功能或未启用的扩展。
Composer audit 为什么总报“高危漏洞”却没实际影响
因为 composer audit 默认扫描所有已安装包（含 require-dev 和间接依赖），而很多所谓“CVE”只影响特定使用场景：比如某个反序列化漏洞只在启用某扩展、调用某冷门函数时才触发，你的项目压根没碰那条路径。它不分析代码调用链，只做版本号匹配。
常见误报场景包括：
- 报告
monolog/monolog的 CVE-2021-31287，但你只用它写文件日志，没启用SyslogHandler - 标出
guzzlehttp/guzzle的 SSRF 漏洞，可你项目里所有 HTTP 请求都走封装好的 SDK，底层从不暴露curl配置 - 把
phpunit/phpunit的测试执行漏洞当成运行时风险——它只在dev环境下存在，且不会进生产镜像
如何用白名单精准过滤 audit 误报
不是关掉 composer audit，而是让它的输出聚焦真正该管的包。Composer 2.5+ 支持 --whitelist 参数，只检查你指定的包名（支持通配符）：
只审计主依赖（排除所有 dev 包和间接依赖）：
composer audit --whitelist="mycompany/*" --whitelist="laravel/framework" --whitelist="symfony/http-kernel"
关键点：
-
--whitelist是精确匹配前缀，"laravel/*"会匹配laravel/framework但不匹配laravel/dusk（除非你也加进去） - 不能写
--whitelist="*"，这会被忽略；必须列出可信的 vendor 名或完整包名 - 白名单不支持正则，只认
/分隔的字符串前缀匹配 - CI 脚本里建议固定白名单，避免因本地
composer.json变动导致流水线行为漂移
audit 白名单和 require-dev 的关系要理清
composer audit 默认包含 require-dev，但生产环境根本不用这些包。直接删掉它们不是办法——有些工具（如 phpstan）是构建期必需的。正确做法是分环境执行：
开发时全面扫描（含 dev）：
composer audit
CI 流水线中只扫运行时依赖：
composer install --no-dev --no-scripts && composer audit --whitelist="myapp/*" --whitelist="vendor/core-lib"
容易踩的坑：
- 以为
--no-dev后audit就自动跳过 dev 包——错，audit仍会读composer.lock里的全部记录，必须配--whitelist - 在
composer.json里给require-dev加注释说“此包仅用于测试”，audit完全不看注释 - 用
composer prohibits查依赖来源时，发现某个高危包是phpunit带进来的，就去删phpunit——结果测试跑不了，得不偿失
比白名单更稳的长期方案：用 Composer-Audit 的 ignore 规则
如果某些 CVE 确实无法规避（比如你用的私有组件依赖了带漏洞的旧版 twig，但升级会破坏模板语法），可以用 composer-audit 插件的 ignore 功能（需单独装）：
composer require --dev roave/security-advisories:dev-master
然后在 composer.json 里加：
"extra": {
"roave-security-advisories": {
"ignore": [
"twig/twig:CVE-2022-39265",
"monolog/monolog:CVE-2021-31287"
]
}
}
注意：
- 这个
ignore是按vendor/package:CVE-xxxx精确匹配，大小写敏感 - 被 ignore 的条目仍会出现在
audit输出里，但状态标为ignored，不会导致命令退出码非 0 - 每次加 ignore 前，必须在注释里写明原因和临时缓解措施（例如：“等待 Twig 4.0 LTS 版本发布，预计 2027 Q1”）
最常被忽略的一点：composer audit 的白名单和 ignore 都只作用于当前项目，不继承父级配置；多仓库 monorepo 场景下，每个子项目得单独维护。
