composer audit 是 composer 2.5+ 官方安全命令，依赖 packagist 安全数据库，非本地分析；需手动运行，不自动触发；检查 composer.lock 中已安装包的已知 cve，支持 --dev 和 --format=json；数据源为社区提交的 advisory-db，存在延迟与覆盖局限；升级需谨慎评估 bc break。
Composer 本身不内置漏洞扫描能力，composer audit 是 Composer 2.5+ 引入的官方安全审计命令，但它依赖 Symfony Security Checker（已停用）的后继服务 —— 实际由 packagist.org 的安全告警数据库支撑，**不是本地静态分析工具，也不调用第三方 CLI 扫描器（如 sensiolabs/security-checker）**。
composer audit 命令怎么用？是否默认启用？
composer audit 是一个独立命令，不会在 install 或 update 时自动运行。它只检查当前 composer.lock 中已安装包的已知 CVE 记录，并输出高/中危漏洞。
- 运行前确保
composer.lock存在且是最新的（composer update --lock可强制刷新锁文件时间戳，但不更新包） - 执行
composer audit即可；加--format=json适合 CI 集成 - 它不检查
require-dev中的包（除非显式加--dev参数） - 无网络连接时会报错：
Failed to fetch security advisories: cURL error 7—— 它必须能访问https://packagist.org/advisories
composer audit --dev --format=json
audit 报出的漏洞信息从哪来？为什么有时“漏报”？
数据源是 Packagist 维护的 advisory-security-db，由社区和厂商提交，非自动化挖掘。这意味着：
- 新披露的 CVE 可能有数小时至数天延迟才入库
- 仅覆盖明确标记了
package + version constraint + CVE ID + description的条目，不推断逻辑漏洞或配置风险 - 不检测你自己写的私有包（
repositories类型为package或vcs的包不会被审计） - 若某包版本范围写成
^1.2，而漏洞仅影响1.2.3，audit 不会触发——它比对的是 lock 文件中解析出的**确切安装版本**
audit 发现漏洞后，该怎么安全升级？
不能只靠 composer update vendor/package 盲升：很多漏洞修复版本可能跨主版本（如从 2.x 升到 3.0），存在 BC Break。
- 先查
composer show vendor/package确认当前版本和可用更新 - 看该包的 CHANGELOG 或 GitHub Releases，确认修复版本是否兼容你的代码
- 优先尝试最小升级：比如漏洞在
1.4.2，修复于1.4.3，就锁定"vendor/package": "^1.4.3"再composer update - 若需大版本升级，建议配合
composer prohibits vendor/package查依赖阻塞点 - 临时缓解？改
composer.json加"conflict": {"vendor/package": "，下次 install 会直接失败，避免误装
audit 不是万能的：哪些情况它完全不管？
它只做「已知已登记」的版本匹配，以下全都不覆盖：
- 你项目里硬编码的 API 密钥、数据库密码（
.env文件内容） - PHP 配置问题（如
display_errors = On在生产环境） - Web 服务器配置缺陷（如 Nginx 暴露
composer.json） - 前端依赖（
package-lock.json或yarn.lock）中的漏洞 - PHP 自身版本漏洞（例如 PHP 8.1.10 的某个 ZTS crash）——需用
php -v和 PHP 官方支持列表交叉核对
真正关键的加固动作，往往藏在 lock 文件之外：定期更新 PHP 小版本、禁用危险函数（exec, system）、用 open_basedir 限制路径、以及把 composer install 放进 CI 并强制跑 audit —— 而不是等上线后才发现 monolog/monolog 的 1.25.3 有反序列化风险。
