所以这对于整个行业来说实际上是一个非常有趣的问题。我建议你处理它的方式是

• 在你的合同中有一些东西对测试期间没有注意到的漏洞不承担责任。这样做的原因是，基本上不可能确定您已经在网站或任何其他系统中找到了所有可利用的问题。举一个例子，想一想多年来易受炮击攻击的所有网站，所有接触过其中一个网站的渗透测试公司都应该为不告诉他们的客户负责吗？

• 有一个方法论，说你会做什么。这应该涵盖将要完成的一般测试领域。对于网站，请考虑以 OWASP Top 10 之类的内容为起点。这为您与客户就您将要查看的内容提供了一些共同点。

• 确保您的公司使用清单涵盖基础知识。正如@rapli 所说，记录所有小事，但不要夸大其严重性。虽然确保您的测试不仅仅是一份清单很重要，但使用它可以避免错过基本测试的尴尬错误。

您可能/将会遇到的问题是来自客户的不切实际的期望。那是逐案处理的。如果您的客户希望他们的复杂应用程序将在 5 个人日的测试中得到全面审查，那么您应该解释为什么这不是一个实际的概念 :)

在合同中指定您调查哪些安全方面并仅对这些方面负责。你不会总是发现漏洞。但我保证你会发现一些小问题，我建议你在报告中包含所有你能做到的小细节，标题中缺少 HSTS，弱密码等。这样他们就会看到你做了一些事情。

我知道有一些报告工具，但它们要么不是公开可用的，要么是付费产品。

除了其他答案：

当您的合同说明您的范围以及要测试哪些漏洞时，您可以写下您在范围内针对合同中定义的已知漏洞实际测试了案例。就像是：

SQL injection:

SQL-Injections are ...

We identified 42 Input fields in the Webpages in Scope. We identified 0 
Input fields vulnerable to SQL injection (with our used method).

缺点是：如果在附加到报告的列出的字段之一中实际上可能存在 SQL 注入；你没有承诺 100% 的安全性，但承诺这不是一个漏洞，但你肯定做错了什么——这就是为什么你应该以某种方式说明你使用了哪种测试，哪种 SQL 注入是最先进的在 SQL-Injections 的介绍中，因此您不会因为没有发现将来会发现的攻击而受到指责。

这也适用于一般的网站安全内容：

HTTPS: https is ... recommended to use TLS X.Y ...

We determined the usage of https for all websites in Scope with TLS X.Y.
Certificates expire Dates are set to Date X which is in the recommended
certificate expire time range. Certificates hold an 4096-Bit key which is
acceptable for current usage.

还要尝试创建报告模板，因为您不想一遍又一遍地重写有关 SQL 注入和 HTTPS/TLS 等的所有内容，因此您只需填写测试结果。这也将确保您进行了所有测试并且没有错过任何测试，当您看到某些段落没有写完并且没有发现任何内容或没有任何发现时。