composer audit 是 Composer 2.5+ 官方内置的安全审计命令，通过比对 composer.lock 与 Roave 维护的 PHP Security Advisory Database 离线快照，检测已知漏洞；需升级后启用，支持 --no-dev、--json、--fail-on-warnings 等参数，但不自动修复、不覆盖私有包或零日漏洞。
Composer 本身不提供实时漏洞预警能力，也不存在官方维护的“集成式漏洞库”；所谓“Composer 集成式漏洞库”是常见误解——真正起作用的是第三方工具（如 sensiolabs/security-checker 已弃用，现由 roave/security-advisories 或 composer audit 替代）与 Composer 生态的配合机制。
为什么 composer audit 是当前最直接有效的方案
PHP 8.2+ 自带的 composer audit 命令才是 Composer 官方推荐的漏洞检查方式。它不依赖外部服务端，而是本地解析 composer.lock，比对 PHP Security Advisory Database（由 Roave 维护）的离线快照。
- 执行前需确保 Composer 已升级到 2.5.0+：
composer self-update - 默认只报告中高危（CVSS ≥ 4.0），加
--all可显示全部 - 若项目含私有包或 fork 分支，
audit可能漏报——它只认 Packagist 上已收录且有安全通告的版本 - 不扫描运行时动态加载的扩展（如
ext-redis），仅覆盖require和require-dev声明的包
CI/CD 中阻断构建的实操写法
在 GitHub Actions 或 GitLab CI 中，不能只靠 composer install 后手动跑 audit，必须让失败触发退出码非 0。
- GitHub Actions 示例片段：
- name: Check for security vulnerabilities<br> run: composer audit --no-dev --fail-on-warnings
-
--fail-on-warnings是关键：它让中危及以上漏洞直接导致 job 失败，而非仅输出警告 - 若使用旧版 Composer（composer require --dev roave/security-advisories:dev-master 强制安装冲突包来“编译期报错”，但该方式会污染
composer.json，不推荐用于生产流水线 - 注意：GitLab CI 默认不缓存
composer.lock的安全数据库快照，建议显式添加cache步骤避免每次重拉
为什么别信“自动 webhook 推送漏洞”的第三方 Composer 插件
部分插件声称支持“扫描完自动发 Slack”，实际运行逻辑是：定时调用 composer show --outdated + 硬编码 CVE 匹配规则，既无权威数据源背书，也无法识别条件性漏洞（例如仅当启用 openssl 扩展时才触发的 crypto bug）。
- 真实漏洞上下文依赖 PHP 版本、扩展启用状态、甚至 ini 配置（如
allow_url_fopen），纯静态分析必然误报/漏报 - 所有声称“实时同步 NVD”的 PHP 工具，本质都是定期抓取 Roave/security-advisories 的更新，延迟通常 6–48 小时
- 若真需告警，应统一走 SIEM 或 Prometheus Alertmanager，把
composer audit的 JSON 输出（加--format=json）喂给日志收集器，而非在 Composer 层做通知
真正容易被忽略的点是：Composer 的漏洞检查永远滞后于实际攻击面。比如一个包修复了 CVE-2025-12345，但你的代码里仍调用了已被标记为 @deprecated 的危险函数——audit 不管这个。它只管“有没有已知漏洞版本”，不管“你有没有踩进坑”。
