我见过有几种方法可以做到这一点，每种方法都有其优点和缺点。

正如@RoryAlsop 所指出的，这两种方法的一个共同点是执行摘要应该尽可能地为商业受众编写（假设这是您为第 3 方进行的测试，或者报告将通过给管理层）。

• 通过发现报告。在这里，您列出了调查结果，通常按严重性排序（例如 CVSS 评分或其他一些量表，如严重性/可能性）。然后，如果您有这些信息，您可以列出发现的技术细节和潜在的缓解措施。这种报告很快就进入了重点，并且与工具输出配合得很好。
• 按方法报告。假设您在此处遵循定义的测试方法，则报告按照该方法的思路构建，并包含针对每个审查领域的部分。这些部分详细说明了进行的测试和结果（例如，发现或在本节中没有发现的事实）。这里的好处是你展示了你的工作，并且阅读报告的人可以很好地了解你实际上已经测试了一些东西并且没关系，而不是你只是错过了它。缺点是它往往是一个更长的报告并且更难自动化。另一个问题是，您需要确保测试人员不只是遵循方法，他们实际上会动用大脑来寻找其他东西。

就调查结果的格式而言，我通常包括以下内容

• 标题（在表格中使用描述性并链接到详细信息）
• 描述 - 问题是什么的技术描述，重要的是在什么情况下它可能会导致安全问题（例如，对于跨站点脚本，潜在问题之一是用于获取会话令牌，这可能允许攻击者未经授权访问应用程序）
• 建议 - 应该如何解决问题，在可能的情况下包括有关供应商指导的具体细节来解决它（例如，从标头中删除 Web 服务器版本的内容有针对 Apache/IIS 等的具体说明）
• 参考 - 指向与调查结果相关的其他信息的任何链接（例如，指向 Web app.issue 的相关 OWASP 页面的链接）
• 严重性。正如我上面提到的，这可能是 CVSS 或更一般的东西，例如基于影响和可能性的高/中/低。
• 客户需要的其他分类。例如，某些客户可能需要根据标准或政策或类似 OWASP Top 10 之类的东西排列的东西。

还有一点要说明的是，如果您进行大量测试，那么值得拥有一个包含先前发现的数据库，以避免重复查找参考并确保严重性一致。

令人兴奋的问题！我常常觉得我们的行业正在努力追求最新、最流行的安全潮流。我们追求最新的漏洞利用，在最新的工具上花费大量资金，并将漏洞归咎于第 8 层。我知道这是一个粗略的概括，但我想强调这个主题的重要性——报告！

对于漏洞报告中应包含的内容，我有自己的看法。从结构的角度来看，一份完整的报告将具有以下内容：

• 标题页：这将表明报告名称、它所针对的机构或部门、报告发布的日期。

• 目录：看起来很明显，但这些文件可能会变得很长，出于礼貌包括这个。

• 执行摘要：这将是结果的高级摘要，发现了什么以及底线是什么。

• 简介：简单说明您的资格、审核目的和范围。

• 调查结果：本部分将包含您的调查结果，并将列出应重新修复的漏洞或问题。此列表应按关键级别排序，希望由内部策略定义（即，如果您的漏洞扫描程序发现一个高危漏洞，根据该漏洞在您的环境中的实施方式，它可能不是真正的高危漏洞，因此内部政策应有助于确定关键水平）

• 方法：在这里您将讨论使用的工具、如何排除误报、哪些流程完成了此审核。这是为了提供一致性，并允许您的审计在发现有争议或认为不值得管理层修复的情况下可重复进行。

• 结论：基本结论，总结你已经放在一起的信息。

• 附录：这将是参考所需的任何额外附件。

一些在 PTES 上工作的人正在奠定一些良好的基础。虽然重点是渗透测试，但我认为许多方法，尤其是报告，可以转用于审计。您可以在http://www.pentest-standard.org/index.php/Reporting查看它们。

在渗透测试或混合应用程序分析之后，生成的报告以发现为中心。应该有一个高级概述来讨论缺陷及其对系统的集体影响。

发现是任何安全违规行为。这包括任何CWE 违规，但最常见的 Web 应用程序发现属于 OWASP 前 10 名。每个发现都应包含重现问题的步骤、严重性、此缺陷的影响、解决问题的建议以及包含更多信息的链接。例如，如果您发现 XSS 漏洞，请显示警报框的屏幕截图和用于触发问题的 URL，并链接到 XSS 上的 OWASP 页面。如果您可以使用 XSS 访问 cookie，则该问题可用于劫持会话，否则可用于破坏 CSRF 保护。

如果什么都找不到怎么办？继续寻找！CWE 系统庞大，即使是最老练的开发也会犯错误。有一些漏洞会影响我接触过的每一个应用程序。点击劫持、缺乏蛮力保护和信息泄露可能是最常见的。例如，通过忘记密码或注册功能泄露用户名/电子邮件地址。显示版本号（http 标头或其他任何地方）。详细的错误消息、本地路径、内部 IP 地址……任何可能对攻击者有用的东西。

我认为 Rook 说的很对，虽然这更多是关于报告的核心，而不是它的结构，放在报告格式设计之后。

尝试 STAR 模型（情况、任务、行动和结果）：我已经看到用这个模型编写的很棒的报告。它的伟大之处在于它几乎可以在所有情况下使用：您只需要适应与您相关的内容。在这种情况下，您可以围绕该模型构建您的报告，并使用 Rook 描述的内容来填充该结构。

此外，即使您没有实际发现，您仍然可以根据 STAR 模型编写完整的报告，并且仍然可以提供专业且连贯的内容。