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。










