报告编写

执行技术方面的评价只是整体评价进程的一半；最终产品是一份内容详实的报告。报告应该简单易懂、突出所有评估期间找到的风险，并将之呈现给管理员工和技术员工。

报告需要有三个主要部分，并且在一定程度上允许每个部分被单独分离出来，打印并交与相关的团队，比如开发人员或者系统管理员。

通常推荐有如下几个部分：.

1. 内容提要

内容提要集合了所有评价，并给予管理层或系统管理员一个对全局风险的认识。使用的语言应该更适合没有技术背景的人看，还应该使用图表来显示风险等级。请牢记，内容提要的读者是那些仅仅有时间阅读摘要的人，他需要描述清楚下面两个问题：

1. 哪里发生问题了？
2. 我该如何修复问题？

你只能用一页纸来回答这些问题。

内容提要应该明确地陈述清楚漏洞和它的严重程度是组织风险管理的一个输入，而不是结果或者整治措施。最安全的，可以向组织解释，测试者并不清楚漏洞被利用后会给组织或者商业行为带来何种威胁。这些是风险控制专家在结合漏洞和计算风险等级后的工作。风险管理通常是组织IT安全管控（GRC）的一部分。这份报告只是简单地向这个过程提供一个输入。

2. 测试详情

这里介绍安全测试、问题发现、整改措施大纲，推荐章节标题如下：

2.1 测试项目目标:

这部分大略描述评估项目整体目标和期望结果。

2.2 测试项目范围:

这部分描述项目范围。

2.3 测试项目进度：

这部分描述测试正式开始和结束时间

2.4 测试目标：

这部分应列清楚测试应用数量和测试系统数量。

2.5 测试限制条件：

这部分应表达出在整个评估过程中存在的限制条件。比如项目关注度限制，测试方法、性能、技术水平限制以及测试中测试者所遇到的问题等等。

2.6 测试结果小结

这部分介绍在测试中发现的漏洞和问题。

2.7 整改方案小结

这部分规划修复发现的漏洞的方案和计划。

3. 测试结果

报告的最后部分需要包含详细的漏洞技术细节以及解决技术方案。这部分以一个技术层为目标，它应该包括关于所有必要的信息，使得技术团队理解问题并解决问题。每个发现的问题应该明确简练，并让报告阅读者能立即理解问题所在。

测试结果部分应当包括:

• 一定数量的截图和命令参考，用以做简单的参考
• 被影响的事物
• 对问题的技术描述
• 如何解决问题的章节
• 问题严重等级，可以使用CVSS描述的向量标记[1]

下面是在评估中测试的清单列表:

附录部分

这部分常用于描述评估中使用的商业以及开源工具。当在评价过程中使用用户脚本/代码时，应该在这部分中说明或以附件形式标记。通常用户很喜欢该测试包含了顾问的使用方法。他们可以知道该评估的全面性已经包含了哪些方面。

参考资料

Industry standard vulnerability severity and risk rankings (CVSS) [1] – http://www.first.org/cvss