composer audit 命令不是默认可用的内置命令，截至 Composer 2.5.x 稳定版需显式安装 dev 主干或启用安全插件，否则报错“Command audit is not defined”；实际审计依赖 roave/security-advisories 黑名单拦截、composer validate --strict 和外部工具如 Snyk 或 GitHub Dependabot。
composer audit 命令是否默认可用
不是。截至 Composer 2.5.x（2026 年主流稳定版），composer audit 不是内置命令，必须显式安装 composer/composer 的 dev 主干或启用安全插件。直接运行会报错：Command "audit" is not defined.
真正可用的审计能力来自官方推荐的安全插件：sensiolabs/security-checker 已弃用，当前基线依赖的是 roave/security-advisories + composer validate --strict + 第三方服务集成。
- 本地轻量审计：用
composer validate --strict检查composer.json格式、许可证字段缺失、不安全的版本约束（如*或dev-master） - 漏洞扫描必须靠外部工具：推荐
phpstan配合roave/security-advisories禁止已知危险版本，或接入GitHub Dependabot/Snyk自动 PR - CI 中禁用
composer update后再审计——否则composer.lock失效，审计结果无意义
roave/security-advisories 如何强制阻断危险依赖
它不是一个扫描器，而是一个“黑名单式冲突包”：声明 "roave/security-advisories": "dev-latest" 后，Composer 解析时会主动拒绝任何与已知 CVE 冲突的版本。
例如，若某项目 require "monolog/monolog": "^1.23"，而该范围包含含 RCE 的 1.23.0，Composer 就会在 install 或 update 阶段直接报错：Your requirements could not be resolved to an installable set of packages.
- 必须放在
require（非require-dev）里才生效，因为它是编译期拦截，不是运行时检测 - 不能替代人工审查：它只拦已收录 CVE，对逻辑漏洞、配置错误、未公开 0day 无效
- 更新基线 = 更新
roave/security-advisories本身版本，建议用^dev-main并每周composer update roave/security-advisories
composer.lock 文件里的 hash 值能否用于审计溯源
能，但仅限完整性校验，不提供漏洞上下文。
composer.lock 中每个包条目含 "content-hash" 和各包自身的 "dist": {"shasum": "..."}，前者是整个 composer.json 结构哈希，后者是压缩包二进制 SHA-256。部署时可脚本化比对：
jq -r '.packages[] | select(.name == "guzzlehttp/guzzle") | .dist.shasum' composer.lock
但注意：
- shasum 只防下载篡改，不防源码层后门（比如包作者恶意提交新 commit 到 tagged 版本）
- content-hash 不随子依赖漏洞更新而变——哪怕
monolog今天爆新 CVE，只要没改composer.json，hash 就不变 - 真正需要审计时，应以
composer.lock为输入，喂给 Snyk CLI 或 GitHub API 查询已知漏洞
CI 流水线中审计失败该不该阻断构建
应该，但要分层响应。
低风险（如过期 license 字段、未锁定 PHP 版本）可 warning；中高风险（CVE 匹配、ext-xyz 缺失导致降级加载）必须 fail。
- 用
composer show --outdated --direct检查直接依赖是否滞后两个小版本以上，作为技术债指标，不阻断但发告警 - 用
composer why-not vendor/package:version快速定位哪个依赖在拖慢升级，避免盲目update - 最易忽略的一点：审计脚本必须运行在和生产一致的 PHP 版本下（比如 PHP 8.3），否则扩展兼容性判断会误报
