roave/security-advisories不能用于统一管理安全基线，因其仅在composer install/update时拦截已知含CVE的包版本，不扫描、不审计、不报告，且对已安装漏洞版本完全静默。
roave/security-advisories 不是用来“统一管理安全基线”的工具，它只做一件事：在 composer install 或 composer update 时，阻止安装已知含 CVE 的 PHP 包版本。它不扫描、不审计、不生成报告，也不影响运行时行为。
为什么不能用 roave/security-advisories 做基线管理？
它的设计目标非常窄：仅干预依赖解析阶段。一旦依赖已安装（比如已有 composer.lock），它就完全静默——哪怕你锁着一个被标记为高危的 monolog/monolog:1.23.0，composer install 也不会报错。
- 它不提供 API、不暴露函数、不写日志，也没有命令行接口（
composer security-check是另一个废弃项目，和它无关） - 它不检查你的代码是否用了危险函数（如
eval、unserialize） - 它不识别私有 fork、自定义分支或未打标签的修复版本
- 它不支持按团队/环境设置不同策略（比如“测试环境允许旧版 Symfony，生产不允许”）
composer require --dev roave/security-advisories:dev-latest 必须加 --dev
这条命令不是可选优化，而是生效前提：
- 必须写进项目根目录的
composer.json，global安装完全无效 - 必须放在
require-dev（或require），但绝不能放在库项目的require里（会污染下游） - 它不会出现在
composer.lock中，也不下载任何 PHP 类——只是注入一组conflict规则 - 如果你的
minimum-stability是stable，而dev-latest被视为不稳定，可临时加"prefer-stable": true或改用roave/security-advisories:6.x-dev（但后者更新滞后）
遇到 Your requirements could not be resolved 怎么快速定位？
这不是错误，是它正在起作用。关键不是看整段推导链，而是盯住第一个被拦下的包：
- 执行
composer why-not monolog/monolog:1.23.0，看谁间接拉入这个版本 - 检查
composer.json里是否有宽泛约束，例如"monolog/monolog": "^1.23"—— Roave 会封掉该范围内所有含漏洞的小版本 - 某些包（如
symfony/http-foundation）在5.4.x中多个小版本各自有不同 CVE，必须升到5.4.33+或直接切6.4+ - 私有 fork 若没同步上游 tag（比如你 fork 了
monolog/monolog但没打v1.23.1），Roave 无法识别修复状态，会持续报错
真正需要的安全基线，得靠组合手段
roave/security-advisories 只是第一道门禁，不是整套安防系统。复杂点在于：它不告诉你“当前有什么漏洞”，只告诉你“这个版本不能装”。要建立可度量、可审计、可继承的安全基线，你还得配 composer audit（PHP 8.4+ 内置）、CI 中跑 security-checker（已归档，慎用）、SAST 工具（如 Psalm with security plugin），以及定期人工 review composer.lock 的变更。忽略这点，很容易误以为“装了 Roave 就万事大吉”。
