报告表达规范是什么
报告的表达方式直接影响整改讨论的效率。规范的做法是每条发现按四段式写：现象、证据、影响、建议；不使用绝对化与恐吓式表述；未验证的内容显著标注；用词与术语表、定级口径保持一致。每句结论都要能对应到证据，或者明确写成推断。
基本信息
| 结构 | 现象 → 证据 → 影响 → 建议 |
|---|---|
| 禁用写法 | 绝对化断言与恐吓式措辞 |
| 标注要求 | 未验证内容显著标注为推断 |
| 一致性 | 与术语表、等级口径保持一致 |
| 适配受众 | 对客户管理层与开发团队同样克制 |
典型使用场景
- 高危发现的影响描述：说明验证到的范围与后果
- 复测结论：区分已验证通过与本轮未覆盖部分
- 管理摘要：用业务语言描述影响而不渲染
- 客户多部门审阅：表达克制能减少对抗性解读
- 对外通报材料：措辞更要避免夸大与定性指控
表述对照
表述对照
不建议：“系统完全沦陷，数据随时可能泄露”
建议：“已验证可越权读取订单数据（E-12），批量影响范围未验证”
不建议：“该漏洞绝不可能被利用”
建议：“当前网络分区下需经跳板访问，路径见证据 E-18”
规则：每句结论都能对应到证据，或标注为推断表述要素与反例
| 要素 | 推荐写法 | 反例 |
|---|---|---|
| 现象 | 客观描述可观测行为 | 使用极其严重等评价性词 |
| 证据 | 引用编号与时间戳 | 仅凭印象描述 |
| 影响 | 写明范围与前提条件 | 推论为已发生事实 |
| 建议 | 给出可执行动作 | 只写加强安全防护 |
对外材料尤其克制：表达方式直接影响整改讨论的氛围与效率，夸大的措辞会让技术团队转入防御姿态，问题反而推不动。
未验证的推断不能与已验证事实混写：客户据此做资源决策时，会把推断当结论，一旦被证伪，整份报告的可信度都受影响。