一份干净的渗透测试报告并不代表系统安全，它只说明：特定的人，用特定的时间和权限，在被要求检查的范围内没有发现严重问题。只要不过度解读，这个信息很有用。
能证明什么，不能证明什么
好的测试能证明某些弱点确实可被利用，能说明攻击者借此能碰到什么，也能展示几个小问题如何串联成大问题。扫描器的输出给不了这种证据，而一条实际打通到客户数据的路径，往往能结束关于优先级的争论。
测试无法证明漏洞不存在。它只是一张快照，下一次发布就可能让结论失效。测试人员通常只有几天，有动机的攻击者却没有这种限制。多数测试也不会告诉你团队能否察觉入侵、应对得如何；想回答这些问题，应该做红队演练或桌面推演。
按问题选类型
- 漏洞扫描： 自动化、覆盖广，适合定期发现已知问题。有用，但不算渗透测试。
- 外部网络测试： 互联网上的人能接触并利用什么？
- 内部测试： 一台笔记本或一个账号失陷后会怎样？
- Web应用或API测试： 用户能否读取其他客户的数据或提升权限？这很依赖人对业务逻辑的理解。
- 云配置审查： 身份策略、存储和网络设置是否暴露过多？
- 社会工程： 员工和流程能否经受钓鱼或冒充来电？
- 红队： 以目标为导向的模拟攻击，同时检验检测与响应能力，适合基础问题已解决的机构。
测试者掌握的信息多少也有影响。黑盒测试听上去真实，却要把付费工时花在信息收集上，而攻击者有的是时间慢慢收集。对多数应用，我们认为灰盒测试更划算：提供各角色的账号和相关文档。
范围决定了大部分价值
从你担心什么谈起，而不是从一串IP地址谈起。“一个租户能否读到另一个租户的发票？”比“测一下门户网站”能换来更好的测试。开工前要约定：
- 哪些在范围内；同样明确地写出哪些不在范围内，以及原因。
- 由有权限的人出具书面授权，涉及第三方或托管系统时也要取得其所有者的授权。
- 在生产环境还是在有代表性的预发布环境测试。后者更安全，但前提是与生产环境一致。
- 每个角色的测试账号，最好跨两个租户。
- 交战规则：测试时段、禁用手段、紧急联系人，以及发现真实入侵痕迹时怎么办。
- 依据什么标准。Web应用可以参考OWASP Web安全测试指南。
怎么读报告
先看覆盖范围，不要先看发现项：测了什么、测了多久、什么没能测。对大型平台只测三天，发现项少说明不了什么。
严重性评分只是参考，不等于你的修复顺序。CVSS评估的是漏洞的技术严重程度，其基础分并不了解你的业务。面向互联网的支付流程上一个中危，可能比隔离测试服务器上一个高危更要紧。
接着找规律。五个分散的注入问题，其实是一个关于输入处理的问题。三个接口缺少授权检查，说明框架层有缺口，应该在那里修。如果报告基本是扫描结果换了格式，没有人工验证痕迹、复现步骤和攻击链，就要提高警惕。
复测才算闭环
报告归档之前，先给每个发现项定负责人和期限。尽量修根因，再请测试人员验证。复测只确认特定问题已解决，并不重新检查整个系统，所以复测函不应当作新的“安全证明”交给客户。预约首次测试时就把复测一起定下，期限从一开始就存在。
除了按日历，新认证流程、平台迁移这类重大变化发生时也应该再测。
本周可以做的事
- 找出最近一份报告，数一数还有多少发现项未关闭。
- 读一遍范围部分，列出此后上线了哪些内容。
- 写下你最想排除的两三种后果，这就是下次测试范围的开头。