composer audit 直接查出 Packagist 官方安全数据库中已收录的高危/严重漏洞（CVSS≥7.0），覆盖主流PHP包，但不查私有包、0day、源码或dev-dependencies（除非加--dev）。
composer audit 命令能直接查出哪些漏洞？
它只检查 composer.lock 中已安装的依赖，不扫描源码或自定义代码。结果来自 Packagist 官方维护的 [Security Advisory Database](https://github.com/composer/advisories)，覆盖主流 PHP 包（如 monolog/monolog、laravel/framework），但不会报出未收录的私有包或未公开披露的 0day。
- 默认只显示「高危」和「严重」等级的漏洞（CVSS ≥ 7.0）
- 加
--low才会包含中低风险（比如信息泄露类 CVE） - 不检查 dev-dependencies，除非显式加上
--dev - 如果项目没运行过
composer install或lock文件损坏，命令会直接失败并提示No composer.lock file found
audit 报错 “Could not fetch advisories” 怎么办？
这是网络或认证问题，不是你本地配置错了。Composer 默认走 HTTPS 请求 Packagist 的 advisory API，国内环境容易卡在 DNS 或 TLS 握手阶段。
- 先试
composer config -g repo.packagist.org.allow_ssl_downgrade false（避免某些代理强制降级） - 临时换镜像源：
composer config -g repo.packagist.org.url https://packagist.phpcomposer.com（注意：该镜像已停更，推荐用https://packagist.org+ 科学网络） - 如果公司内网禁了外部 HTTPS，需联系运维开通
https://github.com/composer/advisories的出站访问 - 别改
advisory-url配置项——这个字段不存在，官方不支持自定义 advisory 源
audit 输出里 “not fixed” 是什么意思？
说明当前锁文件中使用的版本存在已知漏洞，且对应包的最新稳定版（或你允许的版本约束范围内）尚未发布修复补丁。不是 Composer 没尽力，是上游还没修。
- 例如
guzzlehttp/guzzlev7.2.0 有 CVE-2021-3018，但 v7.2.1 才修复；如果你"guzzlehttp/guzzle": "^7.2"，而 lock 里锁的是 v7.2.0，就会标not fixed - 此时运行
composer update guzzlehttp/guzzle通常能升到 v7.2.1（前提是版本约束允许） - 若上游长期不修，又不能升大版本，只能手动 patch 或加
security-advisories白名单（不推荐） -
not fixed不等于“无法解决”，只是当前依赖树里没路可走
CI 流程里怎么安全地用 audit？
别让它变成阻断项。很多团队误把 composer audit --no-dev 放进 pre-commit 或 CI，结果因一条低危告警导致整条流水线失败，反而掩盖真正要处理的问题。
- CI 中建议加
--format=json并用脚本过滤：只对severity: "critical"或"high"且fixed: false的条目 exit 1 - 避免在 PR 构建中运行，改在 nightly scheduled job 里跑全量审计，生成报告归档
- 如果用了
composer require --no-update后忘记install，audit 会静默跳过——加个前置检查：test -f composer.lock || (echo "Missing composer.lock"; exit 1) - GitHub Actions 示例片段：
composer audit --no-dev --format=json | jq -e 'map(select(.severity == "critical" or (.severity == "high" and .fixed == false))) | length > 0'
（需装jq）
vendor/ 目录是否和 lock 一致。如果有人手动删过 vendor 或混入了非 Composer 安装的包，audit 结果就不可信——先 composer install --dry-run 确认一致性，再 audit。 
