报告应从决策开始，而不是罗列漏洞
管理者、产品负责人和工程师需要不同层次的信息。简明摘要应说明测试范围、风险最高的场景，以及应优先采取的行动。报告既不应夸大影响，也不应隐藏不确定性；读者需要清楚测试边界、重要排除项，以及结论的可信程度。
有效的优先级还要考虑产品上下文，不能只看技术严重度。访问一个测试账号与读取全部客户记录，可能源于相似的开发错误，但处置方式和时间要求完全不同。
每个发现都应可以验证
一条发现需要连接根因、利用路径和实际观察到的影响，并注明受影响组件、必要前提、最少复现步骤和脱敏证据。真实密钥、个人数据和可重复使用的令牌不应写入报告；能够证明结果的安全片段已经足够。
修复建议只有指向根因时才便于执行。与其笼统写“验证输入”，不如说明控制应放在哪里、哪条信任假设被破坏，以及还需检查哪些相邻路径。如果长期修复涉及架构调整，可以单独列出临时降低风险的措施。
- 上下文和受影响资产。
- 前置条件和可复现步骤。
- 影响、证据和评估可信度。
- 根因修复方案和复测计划。
报告应持续跟踪到修复验证完成
状态和负责人能让报告成为实际工作工具。每条发现应记录责任人、选定的处理方式，以及进入复测的条件。如果团队接受风险或调整优先级，也应在发现旁保存决定及其理由。
复测时，测试人员既要验证原始场景，也要检查合理的绕过方式。结果应准确记录测试内容、测试环境和观察结果。这段历史能让下一次评估关注新风险，而不必重新还原旧问题的背景。
PENTEST.RED / RED JOURNAL