Composer 的 --audit 命令依赖 composer/advisory-security 项目维护的公开漏洞清单,该清单由官方团队人工审核并同步自 PHP Security Advisories Database,不使用 OSV、NVD 或 Snyk API。

Composer 的 --audit 命令依赖哪个漏洞数据库?
它直接对接 composer/advisory-security 项目维护的公开漏洞清单,该清单由 Composer 官方团队人工审核并同步自 PHP Security Advisories Database(即 roave/security-advisories 的上游源)。不使用 OSV、NVD 或 Snyk API。
composer audit 是如何匹配已安装包与漏洞记录的?
它不会运行代码或扫描源码,而是做纯声明式比对:
- 读取当前
composer.lock中每个包的name和version - 查表匹配 advisory 数据库中对应
package字段和versions范围(如"^1.2.0"或") - 若当前版本落在任一已知受影响范围内,就标记为
CRITICAL/HIGH等级并报告 - 不检测本地修改、fork 分支、私有包(除非你手动将它们加入 advisory 列表)
为什么有些已知 CVE 没被 composer audit 报出?
常见原因包括:
- 对应 CVE 尚未被收录进
composer/advisory-security仓库(提交 PR 需要人工审核,存在延迟) - 包名不一致:比如你用了
monolog/monolog,但 advisory 记录的是php-monolog/monolog(旧别名)或镜像源别名 - 版本约束写法导致误判:如
"dev-main as 1.0.0"这类别名版本无法被 advisory 的语义化版本规则识别 - 你启用了
--ignore-platform-reqs安装,但audit仍按lock文件原始版本比对,可能漏掉因平台跳过而实际未安装的包
能否让 composer audit 检查私有包或自定义规则?
原生命令不支持。但可通过以下方式扩展:
- 在项目根目录添加
composer.json的extra.security-advisories字段,手动注入私有包的漏洞条目(格式同官方 JSON 结构) - 用
composer audit --format=json输出后,用脚本合并自定义 JSON 漏洞数据再解析 - 更可靠的做法是接入
security-checker(已归档)或改用phpstan-security+ 自定义规则,但这就脱离了--audit本身的能力边界
{
"extra": {
"security-advisories": [
{
"package": "acme/internal-sdk",
"version": "1.2.0",
"advisory": "ACME-2024-001",
"title": "Hardcoded API key in config",
"link": "https://internal.acme.dev/sec/ACME-2024-001",
"severity": "CRITICAL"
}
]
}
}
真正容易被忽略的是:即使 audit 报告“无漏洞”,也不代表代码安全——它只管声明式依赖,不管逻辑漏洞、配置错误、运行时注入或你手写的 eval()。










