用 conflict 字段硬性阻止已知不安全版本：在 composer.json 的 conflict 段写死如 "monolog/monolog": "=5.0.0"，composer 解析时前置过滤，跳过该组合，不列入安装候选。

用 conflict 字段硬性阻止已知不安全版本

直接在 composer.json 的 conflict 段里写死要封杀的包和版本，Composer 解析依赖时会主动跳过这些组合，连安装候选都不列入。这不是事后检查，而是前置过滤。

• "monolog/monolog": " —— 封杀所有低于 1.24.0 的版本，包括 1.23.9、1.22.0 等
• "symfony/http-foundation": ">=5.0.0 —— 精确围堵某段区间，常用于已知 CVE 影响的版本范围
• 多个包可并列声明，但注意：一旦冲突命中，composer update 会直接报错中止，不会降级或绕行

启用 audit 配置让 Composer 主动拦截漏洞包

Composer 2.0+ 内置安全审计能力，靠 config.audit.block-insecure 开关控制是否在 install 或 update 阶段拒绝含已知漏洞的包版本。它不是只查本地缓存，而是实时请求 packagist.org 的安全公告数据。

First Principles Decomposer

把任何问题拆解为根本真理，再从原子层面重建解决方案。

下载

• 必须设 "block-insecure": true，否则 ignore 列表无效
• "ignore" 里填的是 CVE 编号或 GHSA ID，例如 "CVE-2021-1234"，不能写包名或版本号
• 被 ignore 的条目仅跳过阻断，仍会出现在 composer audit 输出中，方便人工复核

filter.unfiltered-packages 白名单机制慎用

这个配置项容易误解为“只允许这些包”，实际作用是「对列表内包禁用所有 filter 规则」，包括安全过滤。它适用于核心框架类包（如 symfony/*），你信任其发布流程，不想因某次误报的安全通告导致构建失败。

• 写法必须是数组，每个元素带 package、constraint 和 apply 字段
• "apply": "all" 表示对 install/update/audit 全流程豁免，不是只跳过 block
• 如果漏写 constraint，该包将完全脱离版本约束体系，可能引入意外大版本升级

为什么不能只靠 require + 版本号来防不安全版

"some/package": "^3.2" 这类写法看似限制了主版本，但只要上游没发新 patch，Composer 仍可能装上已知含漏洞的 3.2.5——因为漏洞未触发语义化版本变更。真正起效的是 conflict 或 audit 这类基于外部安全元数据的机制。

• require 的版本约束只管“是否满足格式”，不管“是否带漏洞”
• lock 文件里记录的版本，哪怕已被后续安全通告标记为高危，composer install 也不会拒绝安装
• 所以生产环境 CI 必须跑 composer audit --no-interaction 作为独立检查步骤，不能只信 lock