Composer项目依赖包安全更新与审计记录指南-composer-PHP中文网

不会。composer update 默认只按 composer.json 版本约束安装兼容最新版，不优先选择含安全修复的补丁版本；必须先运行 composer audit 检测漏洞，再手动指定修复版本（如 composer require vendor/package:2.1.3）并执行 composer update --with-dependencies 确保关联依赖同步升级。

composer项目依赖包安全更新与审计记录指南

composer update 会自动修复安全漏洞吗

不会。composer update 默认只按 composer.json 中的版本约束拉取最新兼容版本，不关心是否含安全修复。它可能跳过带补丁的次要版本（比如从 v2.1.0 升到 v2.1.3），只要 v2.1.0 还在 ^2.1 范围内，就不会动。

真正触发安全更新的是：composer update --with-dependencies 配合已知漏洞数据库比对，但前提是你要先运行审计命令——否则 Composer 根本不知道哪些包有风险。

必须先执行 composer audit（Composer 2.5+）或 composer security:audit（旧插件）获取漏洞列表
composer update vendor/package-name 才能精准升级到含修复的版本（如 v2.1.3 而非盲目升到 v2.2.0）
若用 composer update 全量升级，可能引入 BC break，尤其跨主版本时

如何让 composer audit 输出可存档的 JSON 审计记录

composer audit 默认输出人类可读文本，不利于 CI/CD 自动化或长期归档。加 --format=json 参数即可生成结构化结果：

composer audit --format=json > security-audit-$(date +%Y%m%d-%H%M).json

注意几个关键点：

该参数仅在 Composer 2.5.0+ 生效；低于此版本需安装官方插件 composer require --dev composer/composer-security-audit
JSON 输出包含 cve、severity、package、version 和 fixedIn 字段，可直接用于脚本解析
若项目含私有包或未公开 CVE 的内部漏洞，composer audit 不会报告——它只对接 packagist.org 的安全公告源

vendor 目录被忽略时，composer audit 为什么仍能工作

composer audit 不依赖 vendor/ 目录存在，它只读取 composer.lock 中锁定的包名与版本号，再比对 Packagist 公开的安全数据库。所以即使你删了 vendor 或 .gitignore 里写了 /vendor，审计依然有效。

但要注意这个边界：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

如果 composer.lock 不存在或未提交，审计将报错 No lock file found
若使用 platform-checks 或自定义 repositories（如私有 Satis 源），composer audit 默认不检查——它只认 Packagist 官方索引
某些通过 path 类型本地加载的包（"type": "path"）会被跳过，因无对应 CVE 关联逻辑

CI 流水线中安全审计失败时，如何只阻断高危（critical/high）漏洞

默认 composer audit 遇到任意等级漏洞就返回非零退出码，导致流水线中断。实际协作中，常需区分处理：critical/high 必修，medium/low 可延后。

用 --level 参数控制阈值：

composer audit --level=critical,high || echo "Security audit passed for medium/low only"

更稳妥的做法是捕获 JSON 并过滤：

composer audit --format=json | jq -e 'map(select(.severity == "critical" or .severity == "high")) | length > 0' > /dev/null

常见陷阱：

--level=high 不包含 critical，必须显式并列写 critical,high
jq 命令在 Alpine 基础镜像中默认未安装，CI 中需先 apk add jq 或改用 PHP 原生解析
某些企业级扫描工具（如 Snyk）会报告 Composer 未覆盖的间接依赖漏洞，不能只信 composer audit 一家

真正麻烦的不是命令怎么写，而是搞清哪个包的哪个版本被打了补丁、补丁有没有被下游依赖间接拉进来、lock 文件里锁的到底是不是“已修复”那个 commit —— 这些都得靠人工交叉验证，自动化只能帮你标出怀疑对象。