Composer ≥ 2.5.0 才内置 audit 命令；运行 composer --version 查版本，低于则执行 composer self-update 升级，CI 或 Docker 中需更换基础镜像或手动覆盖安装。
直接用 composer audit，但前提是 Composer ≥ 2.5.0；低于这个版本会报 Command "audit" is not defined，别折腾插件，升级就行。
怎么确认和升级到可用的 Composer 版本
Composer 的 audit 命令从 2.5.0 版本起才正式内置并默认启用。旧版（比如 2.4.x 或更早）根本没这个命令。
- 运行
composer --version查看当前版本；输出是Composer version 2.4.9或更低，就肯定不支持 - 执行
composer self-update升级（确保已配置国内镜像，否则可能卡在下载阶段） - 升级后再次运行
composer --version，确认输出为2.5.x或更高 - 某些 CI 环境或 Docker 镜像里 Composer 被锁死在旧版，得改基础镜像或手动覆盖安装
audit 扫什么、不扫什么，为什么有时“明明有漏洞却不报”
composer audit 只比对 composer.lock 中记录的**实际安装版本**和 FriendsOfPHP/security-advisories 数据库里的条目。它不分析代码、不查 CVE 原始库、也不检测运行时环境是否满足触发条件。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 它不读
composer.json—— 如果你改了composer.json但没运行composer install，audit就看不到“潜在风险” - 它不检查 dev-only 包，除非显式加
--with-dev；很多测试工具链漏洞（如 PHPUnit 插件）因此被漏掉 - 新爆出的漏洞通常要几小时到一天才会同步进数据库，这期间
audit会漏报 - 如果你的
vendor/是手动复制或 git clone 进来的，composer.lock缺失或哈希不匹配，audit就无法准确定位版本
常用参数和 CI 场景下的关键控制点
默认行为太宽泛，尤其在 CI 流水线里容易误失败。必须按需收紧范围和判断逻辑。
-
composer audit --no-dev：跳过require-dev，避免测试依赖干扰主流程 -
composer audit --severity=critical --severity=high：只关注真正需要响应的级别；--severity=medium不生效，别加 -
composer audit --format=json | jq '.advisories[] | select(.severity == "critical")'：配合jq做精准过滤，适合脚本集成 -
composer audit --fail-on-security-violations：让命令在发现 critical/high 时返回非零退出码，可用于流水线卡点 - CI 环境若无外网或 DNS 不稳，加
--no-interaction --timeout=30防止卡住
audit 只报不修，后续动作必须人工闭环
它不会自动升级、替换或打补丁，所有修复都得你手动干预。最容易忽略的是“是否真被利用”这个判断环节。
- 先跑
composer show vendor/package-name确认当前安装版本 - 再跑
composer suggest vendor/package-name看推荐的安全更新路径 - 尝试
composer update vendor/package-name --with-all-dependencies，注意观察是否引入 BC break - 如果升级不可行，别急着加
config.advisories-bypass屏蔽 —— 先写最小复现脚本，验证漏洞是否真能在你的调用方式下触发 - 特别警惕带
"cve": "CVE-XXXX-XXXX"且"link"指向 NVD 页面的条目，这类已有公开 PoC，优先处理
