Composer audit命令能发现已收录于PHP安全数据库的已知漏洞，如monolog反序列化、laravel SSRF等，但不检测私有包、零日漏洞、配置错误或逻辑漏洞。
Composer audit命令能发现哪些安全问题
composer audit 是 Composer 2.5+ 内置的安全扫描命令，它不运行代码、不下载包，只读取 composer.lock 中已安装的依赖版本，比对 PHP Security Advisory Database（由 FriendsOfPHP 维护）中已知的漏洞条目。它能识别的主要是：已公开披露、有 CVE 编号、且已被收录进该数据库的 PHP 包漏洞，比如 monolog/monolog 的反序列化风险、laravel/framework 的 SSRF 或信息泄露等。
注意：它不会检测你自定义的私有包、未被收录的零日漏洞、配置错误（如 .env 泄露）、或应用层逻辑漏洞。扫描结果里出现的 CRITICAL 或 HIGH 级别条目，基本对应真实可利用风险，值得立即跟进。
audit命令必须配合lock文件才能工作
运行 composer audit 前，项目必须已有有效的 composer.lock 文件——它不是分析 composer.json 的声明，而是校验实际安装的版本。如果 lock 文件缺失或损坏，命令会直接报错：Could not find composer.lock。
常见误操作包括：
- 在 CI 流程中跳过
composer install，只跑composer audit→ 没有 lock 就扫不了 - 本地开发用
composer require但没提交更新后的composer.lock→ 扫描结果和线上环境不一致 - 使用
--no-install或--dry-run参数后执行 audit → lock 文件未生成或未更新，扫描失效
稳妥做法是：CI 中先确保 composer install --no-interaction --no-progress 成功执行，再跑 composer audit。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
如何让audit输出更实用的结果
默认输出只列漏洞摘要，对修复帮助有限。加几个参数能快速定位问题：
-
composer audit --format=json→ 输出结构化 JSON，适合脚本解析或集成到安全门禁（如 GitLab CI 的 artifact 分析） -
composer audit --ignore=monolog/monolog→ 临时忽略某个已知但暂无法升级的包（仅限测试/过渡期，勿长期使用） -
composer audit --fixed→ 显示哪些已安装版本其实已被后续小版本修复（即“当前版本有漏洞，但升级到 X.Y.Z 就好了”），这是最常用来指导升级的选项
示例输出片段：{"package":"symfony/http-foundation","version":"5.4.21","advisory":"https://github.com/advisories/GHSA-xxxx","fixed":"5.4.22"} —— 直接告诉你该升到哪个版本。
audit不能替代手动验证和升级策略
扫描出漏洞后，composer update 不一定就能解决。比如某包的修复版本可能要求 PHP 8.2，而你还在用 8.0；或者新版本引入了 BC break，导致 App\Http\Controllers 类调用失败。
真正落地时要分三步走：
- 查
composer audit --fixed给出的fixed版本号 - 运行
composer show vendor/package --all确认该版本是否在 packagist 可用、是否兼容当前 PHP 和其他依赖 - 在测试环境执行
composer update vendor/package:^x.y.z，再跑单元测试 + 关键路径冒烟
最常被忽略的一点：有些高危漏洞（如 guzzlehttp/guzzle 的 DNS rebinding）影响的是 CLI 命令或队列任务，Web 请求压根不触发——但 audit 仍会标出。得结合你的实际使用方式判断是否真要紧急处理。
