生产环境每次发布前必须运行 composer audit，开发阶段建议每周自动触发；因其仅检查当前 lock 文件中的已知漏洞，无法预测新披露风险，且不替代更新或覆盖未知漏洞。

生产环境必须每次发布前跑一次 composer audit，开发阶段建议每周固定时间自动触发一次。

为什么不能只在“出问题时才审计”

依赖漏洞不是突然出现的，而是持续累积的：某个你半年没更新的 monolog/monolog 今天被披露 CVE-2026-12345，但你的 composer.lock 里还锁着带漏洞的 2.8.1；而 composer audit 不会主动提醒你——它只告诉你“当前锁定的版本有没有已知问题”。

常见错误现象：

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

• CI 流水线里漏掉 composer audit 步骤，上线后被安全扫描平台直接标红
• 本地开发时手动执行过一次，之后三个月再没跑，以为“没问题了”
• 误以为 composer update 能代替审计——其实它只升级，不检查历史版本是否已被通报风险

CI 流程中怎么嵌入才不拖慢构建

composer audit 默认走 Packagist 的公开 API，网络抖动或限流会导致超时失败。别让它卡住整个部署流程。

• 加 --no-dev：跳过 require-dev 里的包，减少约 40% 检查量（开发工具类漏洞通常不影响运行时）
• 加 --format=json + jq 过滤：只关注 severity: "critical" 或 "high" 级别，避免低优先级告警干扰
• 设置超时：timeout 30s composer audit --no-dev 2>/dev/null || echo "audit timeout, skipped"，失败不中断构建，但记录日志供回溯

团队协作时谁该负责、什么时候干预

审计结果不是“有漏洞就立刻修”，得看上下文。关键判断点在 composer.lock 是否已提交、漏洞是否影响当前代码路径。

• 发现 high/critical 漏洞但 composer.lock 未提交？立刻阻断 PR，要求修复后再合入
• 漏洞存在于 require-dev 且只用于本地生成文档（如 phpdocumentor/phpdocumentor），可加 --ignore=phpdocumentor/phpdocumentor 临时豁免
• 修复需升主版本（如从 guzzlehttp/guzzle:^7.5 升到 ^8.0），必须同步改代码+写测试，不能仅靠 composer update 一键解决

最容易被忽略的是：审计通过 ≠ 安全。它只覆盖已录入 CVE 数据库的已知问题，对逻辑漏洞、配置错误、未公开的 0day 完全无感。真正管用的节奏是“发布前强制卡点 + 每周静默扫描 + 关键包单独盯梢”。