audit命令在ci中跑不起来需确认三件事：composer≥2.5.0、experimental.audit全局启用、存在有效composer.lock；默认返回非零码会中断构建，应加--severity=critical,high --no-dev --format=json实现精准可控的自动化安全检查。
audit 命令在 CI 中根本跑不起来？先确认三件事
它不是“装了就能用”的命令，缺一不可：Composer ≥2.5.0、experimental.audit 全局启用、项目存在且有效的 composer.lock。任意一项缺失，结果都是静默失效或直接报错。
- 运行
composer --version，输出必须是Composer version 2.5.0或更高；2.4.9 及以下必须执行composer self-update - 运行
composer config --global experimental.audit true（该配置写入~/.composer/auth.json） - 验证是否注册成功：
composer list | grep audit—— 没输出就等于没生效，别折腾插件或镜像源 -
composer.lock必须由composer install --no-interaction生成，手动拷贝、git restore 或跳过 install 直接跑 audit，都会触发Could not find composer.lock
CI 流程里 audit 总失败？默认策略太激进
默认行为是：只要发现任意一条 advisory（哪怕 low 级别、5 年前的废弃包提示），就返回非零退出码，导致构建中断。这不是 bug，是设计如此，但你不该让它这么用。
- 生产环境卡点只应关注真实可利用风险：
composer audit --severity=critical --severity=high --no-dev -
--no-dev很关键——开发依赖（如 PHPUnit、phpstan）不参与运行时，扫它们只会增加误报 - 网络不稳定时加超时控制：
composer audit --no-interaction --timeout=30，避免因 DNS 或安全数据库响应慢而卡住 - 不要用
--severity=medium，它不生效；--severity=low更不会中断，别白加
想让结果能被脚本解析？别信默认表格输出
默认 table 格式看着直观，但无法被 CI 工具自动判断是否要阻断发布。真正落地的集成必须结构化输出。
- 用
composer audit --format=json，输出含package、version、advisory、severity、fixed字段，机器可读 - 配合
jq提取高危项：composer audit --format=json 2>/dev/null | jq -r 'select(.advisories[]?.severity == "critical" or .advisories[]?.severity == "high")' - 加
--fixed参数才能看到修复建议版本号，例如"fixed": "7.5.0"，否则只告诉你有漏洞，不告诉你升到哪 - CI 中建议组合使用：
composer audit --format=json --severity=critical,high --no-dev --fixed
audit 扫不到的，你得心里有数
它只比对 composer.lock 里的精确版本与 FriendsOfPHP/security-advisories 数据库已收录条目，其他一律不管。
- 私有包、未提交到 Packagist 的包、
dev-master分支、未同步进数据库的 CVE —— 全部漏掉 - 不分析代码行为，不查
eval()、exec()、反序列化链，也不识别混淆攻击（那得靠magento/composer-dependency-version-audit-plugin） - 报告里的
CVE-2023-12345不代表你项目一定被利用，得人工查原始 advisory，看 “Exploitation conditions” 是否匹配你的实际用法 - CI 中若用
--ignore=CVE-XXXX，必须确保该漏洞确实在你场景下不可利用，而不是为过流水线随便忽略
