composer audit --locked 更可靠，因它直接读取 composer.lock 文件，与实际运行环境完全一致，避免了依赖解析偏差；漏洞数据源自 Composer 官方维护的 advisory database，同步自 GHSA 等可信源，仅报告 high/critical 级漏洞。
composer audit --locked 是 Composer 2.5+ 引入的安全审计命令，它只检查 composer.lock 中已安装的依赖版本是否存在已知漏洞，不重新解析依赖树、不联网更新包。这是上线前快速验证“当前实际运行依赖是否安全”的最轻量方式。
为什么 audit --locked 比 audit 更可靠？
不带 --locked 的 composer audit 会基于 composer.json 重新计算依赖图（类似 install --dry-run），但这个过程可能受 platform 配置、require-dev 开关、本地 repo 等影响，结果未必反映真实部署环境。而 --locked 直接读取锁文件，和你 composer install 后实际加载的包完全一致。
- 锁文件记录了每个包的确切版本、完整哈希、安装路径，审计结果可复现
- 跳过依赖解析，执行快，CI 中可作为必检步骤
- 不会因
minimum-stability或prefer-stable导致误报/漏报
audit --locked 报告的漏洞来源是哪里？
它默认使用 Symfony Security Checker（已归档）的替代服务 —— 实际由 Composer 官方维护的 advisory database 提供数据，该库同步自 GitHub Security Advisory Database（GHSA）、Drupal、PHPStan 等可信源，覆盖 CVE、CWE 及社区报告的高危问题。
- 数据库每周自动更新，本地无缓存；每次运行都拉取最新清单（需网络）
- 仅报告
high和critical级别漏洞，默认不显示medium（可用--level=medium调整） - 不检测你自己写的代码，只查第三方包的已知公开漏洞
常见报错与绕过陷阱
运行时提示 Could not fetch security advisories 或 No lock file found 是最常卡住的地方：
-
No lock file found：确保在项目根目录执行，且composer.lock存在且未被.gitignore掩盖（CI 中尤其注意） -
Could not fetch...：公司内网可能屏蔽了https://api.github.com/advisories，可配置代理：export HTTP_PROXY=http://your-proxy:8080 - 返回
OK但仍有风险：某些漏洞未被收录（如未公开的 0day、私有包、或新披露未同步的 CVE），不能当作绝对安全凭证 - 忽略警告用
--no-dev？不行 ——--locked本身已锁定全部内容，--no-dev对它无效；若想排除 dev-only 包，得先用composer install --no-dev生成对应锁文件再审
CI 中推荐的最小实践
把它塞进 CI 流程比本地手动跑更有意义，但要注意时机：
- 放在
composer install之后、测试之前，确保审计的是即将运行的依赖 - 加
--format=json方便解析结果（例如失败时提取 CVE ID 发通知） - 避免在
pull_request流程中强制失败 —— 有些漏洞修复需要上游发版，临时允许--level=high并人工跟进更务实 - 示例命令：
composer audit --locked --level=critical --format=json || echo "Critical vuln found"
真正关键的不是“有没有漏洞”，而是“这个漏洞是否在你的调用链里被触发”。composer audit --locked 只回答前半句；后半句得靠代码审计、动态扫描或最小化依赖来逼近。
