领导只关注三件事：高危漏洞、弃用/无人维护包、许可证冲突；结论须明确具体修复动作、责任人和时间节点，避免模糊表述。
依赖审计报告里哪些信息领导真正在意
领导不关心 composer audit 跑了多少行输出，只看三件事：有没有高危漏洞、有没有被弃用或无人维护的包、有没有许可证风险。其他像“中危数量 12 个”这种数字，没上下文等于没说。
实操建议：
- 把
composer audit --format=json的原始结果先过一遍，过滤出severity: "critical"或"high"的条目，再人工确认是否真实可利用（比如漏洞是否在 dev-only 包里、是否用了受影响函数） - 重点标出被审计出问题的包名（如
guzzlehttp/guzzle）、对应版本（如7.4.5）、CVE 编号（如CVE-2023-29197），再加一句影响说明：“该版本存在 DNS 重绑定漏洞，服务端发起外部 HTTP 请求时可能被绕过白名单” - 许可证部分只提冲突项：比如项目用 MIT，但引入了
ircmaxell/password-compat（PHP 5.3 兼容层），它带的是 BSD-3-Clause + GPL-2.0 双许可，而 GPL-2.0 传染性可能影响交付合规
怎么写结论才不被追问“然后呢”
结论不是复述扫描结果，而是给出明确动作指向。领导看到结论，应该能立刻判断要不要批资源、要不要压测试排期、要不要法务介入。
实操建议：
- 避免写“存在若干高危漏洞”，改写为：“需升级
monolog/monolog至^2.10.0（当前2.9.1），预计 0.5 人日，影响日志上报模块，上线前需验证 SLS 日志格式兼容性” - 对已 EOL 的包（如
symfony/http-foundation v3.4），写清替代方案：“symfony/http-foundation已停止维护，建议迁移到^6.4，需同步升级symfony/event-dispatcher和symfony/polyfill-php81，最小改动路径见 PR #4222” - 如果某漏洞实际不可达（比如
doctrine/inflector的反序列化漏洞只在 CLI 环境触发，而本项目纯 Web API），结论里必须写明“暂不修复，已记录为已知风险，后续架构演进时一并清理”
附录里放什么、不放什么
附录是给技术同事查细节用的，不是给领导读的。领导翻到附录，只应看到一张表：三列 —— 包名、风险类型、状态（已修复 / 排期中 / 规避中 / 拒绝修复）。
实操建议：
- 不要贴完整 JSON 输出，也不要放
composer show的树状依赖图 - 可以放一行命令供 QA 验证：“上线后执行
curl -s https://your-api.com/health | jq '.dependencies[] | select(.name==\"guzzlehttp/guzzle\")'确认版本已更新” - 如果用了
composer prohibit或replace锁死某个有风险的包，附录里写清楚约束逻辑：“通过replace声明laravel/framework: ^8.0替代illuminate/support，规避其v8.75.0中的反序列化路径”
关键点在于：所有结论都得锚定到具体代码变更、责任人和时间节点。没人会为“建议加强安全意识”这种话签字。
