Composer audit仅检测CVE漏洞，不检查许可证合规、子依赖高危函数、自定义策略等；许可证检查需借助第三方工具或自定义脚本，CI中应串联audit与license校验并落实人工审批机制。
Composer 本身不提供内置的“合规性检测”能力，它只负责依赖安装与版本解析；真正的依赖合规性（如许可证类型、已知漏洞、内部策略）需靠 composer audit（v2.5+）、第三方工具或自定义策略脚本协同完成。
composer audit 能查什么？不能查什么？
composer audit 是 Composer 2.5 引入的官方安全审计命令，底层对接 Symfony Security Checker（已归档）和当前默认的 advisory-security-checker 数据源。它只检查已知的 CVE 类型漏洞（如 monolog/monolog 的 CVE-2022-29248），不检查：
- 许可证合规（如项目禁用 GPL，但引入了
gnu/gpl-3.0许可的包） - 私有包未声明许可证或许可证字段为空
- 依赖树中某包虽无 CVE，但其子依赖含高危函数（如
eval()、unserialize()） - 是否违反团队自定义规则（如禁止使用
dev-master、要求所有包 version 必须带 stability flag）
执行前确保 Composer 版本 ≥ 2.5：
composer --version若低于该版本，先升级：
composer self-update
如何用 composer audit 扫描已安装依赖
运行 composer audit 会读取 vendor/composer/installed.json 和锁文件，向官方 advisory API 发起批量查询。常见用法：
- 基础扫描：
composer audit
（默认仅显示严重/高危漏洞） - 显示全部等级（包括 medium / low）：
composer audit --all
- 导出 JSON 结果供 CI 解析：
composer audit --format=json
- 忽略特定 CVE（慎用，需加注释）：
composer audit --ignore=CVE-2021-12345
注意：composer audit 不会自动修复，仅报告。修复方式仍是 composer update vendor/package 或降级到已修复版本。
许可证合规必须用第三方工具补位
Composer 原生不校验许可证。要强制执行许可证策略（例如：只允许 MIT / Apache-2.0，禁止 LGPL），需引入：
-
license-checker（Node.js 工具，可解析composer.lock） -
php-scoper+ 自定义脚本提取composer show --all --format=json中的license字段 - 更推荐：
pipenv风格的策略引擎 —— 使用composer licenses（非内置命令）需搭配 ComposerRequireChecker 或自行写 PHP 脚本遍历vendor/*/composer.json
一个轻量检查示例（保存为 check-license.php）：
CI 中串联审计与策略的最小可行流程
在 GitHub Actions / GitLab CI 中，不要只跑
composer install就结束。典型流水线应包含：
- 安装后立即执行：
composer audit --no-dev --format=json | jq -e '.advisories | length == 0'
（用jq断言无漏洞） - 许可证检查放在
composer install后、测试前：php check-license.php
- 对
composer.lock做 git diff 检查，拒绝未经 review 的重大依赖变更（如从^2.0升到^3.0） - 敏感项目建议禁用
packagist.org，改用私有仓库 +composer config repositories.packagist false
真正难的不是工具链拼接，而是把“谁来审批例外”“漏洞响应 SLA 是几小时”这些规则写进 .github/workflows/compliance.yml 并让所有人遵守——技术只是把人定的规则变成不可绕过的门禁。
