Composer 不提供安全评分，仅作二元判断；第三方“打分”工具实为对 severity 标签的加权求和，但 critical/high/medium/low 是人工评估的操作优先级提示，不可数学叠加，且未收录不等于安全。
Composer 本身不提供“安全评分”——它只做二元判断：已知漏洞（有 advisory）或未知（未收录）。 所有声称“打分”“量化风险”的第三方工具，底层都只是把 composer audit 的输出（severity 字段）映射成数字，再加权求和。这种做法容易误导，因为 Symfony DB 的 critical 和 medium 是人工评估上下文后的定性结论，不是 CVSS 原始分，也不能跨包线性叠加。
composer audit 输出的 severity 不是分数，而是风险等级标签
当你运行 composer audit，看到的 critical、high、medium、low 是 Symfony 安全团队基于实际利用链给出的**操作优先级提示**，不是数学可加的“安全分”：
-
critical表示无需用户交互即可远程执行代码（如guzzlehttp/guzzle的CVE-2023-38913），必须立即处理 -
high往往需特定配置或数据流才能触发（如 SSRF 需要可控 URL 输入），不能跳过但可排期 -
medium多为 XSS 或日志注入，影响面窄，但若出现在管理后台等高权限区域，实际风险可能升为high - 没出现在 Symfony DB 的包，
audit会显示Warning: No security advisories found for package xxx—— 这不等于“安全”，只是“未被收录”，需人工查 CVE/NVD
为什么不能对多个 medium 漏洞求平均分？
依赖树里同时存在两个 medium 漏洞，不意味着“整体风险 = 2 × medium”。真实风险取决于它们是否在同一条调用链上、是否共享输入源、是否可被串联利用：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 两个独立组件的 XSS 漏洞（一个在前端 JS 包，一个在后端模板引擎），攻击面隔离，风险不可叠加
- 若一个是反序列化 gadget，另一个是未校验的文件路径拼接，且都在同一请求生命周期中被调用，就可能构成 RCE 链，此时单看
medium标签严重失真 -
composer audit --full会检查require-dev中的包，但其中的phpunit/phpunit漏洞只在测试环境生效，线上风险为零
真正有用的替代方案：聚焦可操作项
与其纠结“总分多少”，不如直接执行能落地的动作：
- 用
composer audit --format=json | jq '.advisories[] | select(.severity == "critical" or .severity == "high")'筛出必须处理的条目 - 对每个
critical漏洞，立刻运行composer update vendor/package-name，不要等“凑够几个一起修” - 用
composer depends vendor/package-name查清该包被谁拉入，再决定是升级上游还是临时replace - CI 中固定加
composer audit --no-dev --strict：失败即阻断，避免medium漏洞被忽略成常态
最常被忽略的一点：composer audit 只读 vendor/ 目录，不验证 composer.json 里声明但未安装的版本是否更安全。你删掉一个 medium 漏洞包，却在 composer.json 里留着宽松约束（如 "monolog/monolog": "^1.0 || ^2.0"），下次 update 仍可能装回带漏洞的老版本——约束本身才是长期风险源。
