OWASP Web 安全测试指南 WSTG

Eoin Keary的前言

软件不安全的问题可能是我们这个时代最重要的技术挑战。支持业务、社交网络等的 Web 应用程序的急剧兴起只会加剧建立一种强大的方法来编写和保护我们的 Internet、Web 应用程序和数据的要求。

在开放 Web 应用程序安全项目® （OWASP®）中，我们试图让世界成为一个不安全软件是异常而不是常态的地方。OWASP测试指南在解决这一严重问题方面发挥着重要作用。至关重要的是，我们测试软件安全问题的方法必须基于工程和科学原理。我们需要一种一致、可重复和定义的方法来测试 Web 应用程序。一个在工程和技术方面没有最低标准的世界是一个混乱的世界。

不言而喻，如果不对应用程序执行安全测试，就无法构建安全应用程序。测试是构建安全系统的更广泛方法的一部分。许多软件开发组织没有将安全测试作为其标准软件开发过程的一部分。更糟糕的是，许多安全供应商提供的测试具有不同程度的质量和严格性。

安全测试本身并不是衡量应用程序安全性的一个特别好的独立指标，因为攻击者可以通过无数种方式使应用程序崩溃，而且根本不可能测试所有方法。我们无法安全地入侵自己，因为我们只有有限的时间来测试和防御攻击者没有这种限制。

结合其他 OWASP 项目，如代码审查指南、开发指南和工具，如 OWASP ZAP，这是构建和维护安全应用程序的良好开端。本测试指南将向您展示如何验证正在运行的应用程序的安全性。我强烈建议将这些指南用作应用程序安全计划的一部分。

2.1为什么选择OWASP？

创建这样的指南是一项艰巨的任务，需要全球数百人的专业知识。有许多不同的方法可以测试安全漏洞，本指南收集了领先专家关于如何快速、准确和高效地执行此测试的共识。OWASP使志同道合的安全人员能够一起工作，并形成解决安全问题的领先实践方法。

以完全免费和开放的方式提供本指南对于基金会的使命非常重要。它使任何人都能够理解用于测试常见安全问题的技术。安全不应该是只有少数人才能实践的黑魔法或封闭的秘密。它应该向所有人开放，不仅对安全从业人员开放，还对 QA、开发人员和技术经理开放。构建本指南的项目将这些专业知识掌握在需要它的人手中 - 你、我和任何参与构建软件的人。

本指南必须交到开发人员和软件测试人员手中。世界上没有足够的应用程序安全专家来对整个问题产生任何重大影响。应用程序安全的初始责任必须落在开发人员的肩上，因为他们编写代码。如果开发人员没有对其进行测试或考虑引入漏洞的错误类型，那么他们就不会生成安全代码，这并不奇怪。

使这些信息保持最新是本指南项目的关键方面。通过采用 wiki 方法，OWASP 社区可以发展和扩展本指南中的信息，以跟上快速变化的应用程序安全威胁形势。

本指南很好地证明了我们的成员和项目志愿者对这一主题的热情和精力。它肯定有助于一次改变世界一行代码。

定制和优先排序

您应该在组织中采用本指南。您可能需要定制信息以匹配组织的技术、流程和组织结构。

通常，组织中有几种不同的角色可以使用本指南：

开发人员应使用本指南来确保他们正在生成安全代码。这些测试应该是正常代码和单元测试过程的一部分。
软件测试人员和 QA 应使用本指南来扩展他们应用于应用程序的测试用例集。及早发现这些漏洞可以节省大量时间和精力。
安全专家应将本指南与其他技术结合使用，以验证应用程序中是否遗漏了任何安全漏洞。
项目经理应该考虑本指南存在的原因，以及安全问题通过代码和设计中的错误表现出来。

执行安全测试时要记住的最重要的事情是不断重新确定优先级。应用程序失败的可能方式有无数种，而且组织的测试时间和资源总是有限的。确保明智地使用时间和资源。尽量关注对您的业务构成真正风险的安全漏洞。尝试根据应用程序及其用例将风险置于上下文中。

本指南最好被视为一组可用于查找不同类型的安全漏洞的技术。但并非所有技术都同样重要。尽量避免将指南用作清单，新的漏洞总是会显现出来，没有指南可以详尽地列出“要测试的事情”，而是一个很好的起点。

自动化工具的作用

有许多公司销售自动化安全分析和测试工具。记住这些工具的局限性，以便您可以将它们用于它们擅长的事情。正如 Michael Howard 在 2006 年西雅图举行的 OWASP AppSec 大会上所说，“工具并不能使软件安全！他们帮助扩展流程并帮助执行政策。

最重要的是，这些工具是通用的，这意味着它们不是为自定义代码设计的，而是为一般应用程序设计的。这意味着，虽然他们可以找到一些通用问题，但他们对您的应用程序没有足够的了解，无法检测到大多数缺陷。根据我的经验，最严重的安全问题不是通用的，而是在业务逻辑和自定义应用程序设计中紧密交织在一起的。

这些工具也非常有用，因为它们确实发现了许多潜在问题。虽然运行这些工具不会花费太多时间，但每个潜在问题都需要时间来调查和验证。如果目标是尽快发现并消除最严重的缺陷，请考虑您的时间最好花在自动化工具上还是使用本指南中描述的技术上。尽管如此，这些工具肯定是平衡的应用程序安全计划的一部分。如果使用得当，它们可以支持您的整个流程，以生成更安全的代码。

号召性用语

如果您正在构建、设计或测试软件，我强烈建议您熟悉本文档中的安全测试指南。这是一个很好的路线图，用于测试应用程序目前面临的最常见问题，但并不详尽。如果您发现错误，请在讨论页面添加注释或自行进行更改。您将帮助成千上万使用本指南的人。

web 安全测试指南（WSTG）项目为 Web 应用程序开发人员和安全专业人员提供了首屈一指的网络安全测试资源。

WSTG 是测试 Web 应用程序和 Web 服务安全性的综合指南。WSTG 由网络安全专业人员和敬业的志愿者共同努力创建，为世界各地的渗透测试人员和组织提供了一个最佳实践框架。

WSTG - Stable | OWASP Foundation

该指南用来指导进行安全测试、渗透测试，如何快速、准确和高效地执行安全测试。《测试指南》详细描述了通用测试框架和在实践中实现该框架所需的技术。

本指南的其余部分组织如下：本简介涵盖了测试 Web 应用程序的先决条件和测试范围。它还涵盖了成功测试和测试技术的原则、报告的最佳实践以及安全测试的业务案例。第 3 章介绍了 OWASP 测试框架，并解释了它与软件开发生命周期各个阶段相关的技术和任务。第 4 章介绍了如何通过代码检查和渗透测试来测试特定漏洞（例如，SQL 注入）。

什么是测试？

在 Web 应用程序的开发生命周期中，许多事情都需要测试，但测试实际上意味着什么？《牛津英语词典》将“测试”定义为：

测试（名词）：旨在确定某物的质量、性能或可靠性的程序，尤其是在它被广泛使用之前。

就本文档而言，测试是将系统或应用程序的状态与一组标准进行比较的过程。在安全行业，人们经常根据一套既不明确也不完整的心理标准进行测试。因此，许多局外人将安全测试视为一门黑色艺术。本文档的目的是改变这种看法，并使没有深入安全知识的人更容易在测试中有所作为

何时测试？

如今，大多数人在软件已经创建并处于其生命周期的部署阶段（即，代码已创建并实例化为一个有效的 Web 应用程序）之前不会对其进行测试。这通常是一种非常无效且成本高昂的做法。防止生产应用程序中出现安全漏洞的最佳方法之一是通过在每个阶段中包含安全性来改进软件开发生命周期（SDLC）。SDLC 是强加于软件工件开发的一种结构。如果您的环境中当前未使用 SDLC，那么是时候选择一个了！下图显示了一个通用的 SDLC 模型，以及（估计的）在此类模型中修复安全漏洞的成本增加。

define design develop deploy maintain 修改安全漏洞的成本随着这个流程阶段逐渐增加。

图 2-1：通用 SDLC 模型

公司应检查其整体 SDLC，以确保安全性是开发过程中不可或缺的一部分。SDLC 应包括安全测试，以确保在整个开发过程中充分覆盖安全性和有效控制。

2.2 测试原则

没有灵丹妙药 There is No Silver Bullet

虽然人们很容易认为安全扫描程序或应用程序防火墙将提供许多防御攻击或识别大量问题，但实际上，不安全软件的问题没有灵丹妙药。应用程序安全评估软件虽然可以作为发现唾手可得的果实的第一道关口，但在深入评估或提供足够的测试覆盖率方面通常不成熟且无效。请记住，安全是一个过程，而不是一个产品。

SDLC为王

将安全性集成到 SDLC 的每个阶段目前有几个安全的 SDLC 框架提供描述性和规范性建议。是选择描述性建议还是规范性建议取决于 SDLC 流程的成熟度。从本质上讲，规范性建议显示了安全 SDLC 应该如何工作，而描述性建议显示了它在现实世界中的使用方式。两者都有自己的位置。例如，如果您不知道从哪里开始，规范性框架可以提供可在 SDLC 中应用的潜在安全控制菜单。然后，描述性建议可以通过展示对其他组织有效的方法来帮助推动决策过程。描述性安全 SDLC 包括 BSIMM;规范性安全 SDLC 包括 OWASP 的开放软件保障成熟度模型（OpenSAMM）和 ISO/IEC 27034 第 1-7 部分，均已发布（第 4 部分除外）

尽早测试并经常测试

当在 SDLC 中及早检测到错误时，可以更快地以更低的成本解决该错误。在这方面，安全错误与功能或基于性能的错误没有什么不同。实现这一目标的一个关键步骤是教育开发和 QA 团队了解常见的安全问题以及检测和预防这些问题的方法。尽管新的库、工具或语言可以帮助设计具有更少安全漏洞的程序，但新的威胁不断出现，开发人员必须意识到影响他们正在开发的软件的威胁。安全测试方面的教育还有助于开发人员获得适当的思维方式，从攻击者的角度测试应用程序。这允许每个组织将安全问题视为其现有职责的一部分。

测试自动化

在现代开发方法中，例如（但不限于）：敏捷、DevOps/Devsecops 或快速应用程序开发（RAD），在将安全测试集成到持续集成/持续部署（CI/CD）工作流中时，应考虑将安全测试集成到持续集成/持续部署（CI/CD）工作流中，以维护基线安全信息/分析并识别“唾手可得”类型的弱点。这可以通过在标准自动发布工作流期间或定期计划利用动态应用程序安全测试（DAST）、静态应用程序安全测试（SAST）和软件组件分析（SCA）或依赖项跟踪工具来实现。

了解安全范围

重要的是要知道给定项目需要多少安全性。应对要保护的资产进行分类，说明如何处理这些资产（例如，机密、秘密、绝密）。应与法律委员会进行讨论，以确保满足任何特定的安全要求。在美国，要求可能来自联邦法规，例如《格雷姆-里奇-比利雷法案》，或来自州法律，例如加利福尼亚州 SB-1386。对于位于欧盟国家/地区的组织，特定国家/地区的法规和欧盟指令都可能适用。例如，指令 96/46/EC4 和法规（EU） 2016/679（通用数据保护条例）规定，无论何种应用，都必须以应有的谨慎态度处理应用程序中的个人数据。

培养正确的心态

成功测试应用程序的安全漏洞需要“跳出框框”进行思考。正常用例将测试用户以预期方式使用应用程序时的正常行为。良好的安全测试需要超越预期，并像试图破坏应用程序的攻击者一样思考。创造性思维可以帮助确定哪些意外数据可能导致应用程序以不安全的方式失败。它还可以帮助发现 Web 开发人员做出的任何并不总是正确的假设，以及这些假设如何被颠覆。自动化工具在漏洞测试方面做得很差的一个原因是自动化工具没有创造性地思考。创造性思维必须根据具体情况进行，因为大多数 Web 应用程序都是以独特的方式开发的（即使使用通用框架）。

Understand the Subject

在任何良好的安全计划中，首要的主要举措之一应该是要求对应用程序进行准确的文档记录。架构、数据流图、用例等应记录在正式文档中，并可供审查。技术规范和应用文档应包括的信息，不仅列出所需的用例，还列出任何明确不允许的用例。最后，最好至少有一个基本的安全基础设施，允许监控和趋势分析针对组织应用程序和网络（例如入侵检测系统）的攻击。

使用正确的工具

虽然我们已经说过没有银弹工具，但工具确实在整个安全计划中起着关键作用。有一系列开源和商业工具可以自动执行许多日常安全任务。这些工具可以通过协助安全人员完成任务来简化和加快安全流程。但是，重要的是要准确了解这些工具可以做什么和不能做什么，以免它们被过度销售或不正确使用。

The Devil is in the Details

至关重要的是，不要对应用程序进行肤浅的安全审查并认为它是完整的。这将灌输一种虚假的信心，这种信心可能与一开始就没有进行安全审查一样危险。仔细审查调查结果并清除报告中可能残留的任何误报至关重要。报告不正确的安全发现通常会破坏安全报告其余部分的有效信息。应注意验证应用程序逻辑的每个可能部分是否都经过测试，并且每个用例场景都已探索可能的漏洞。（这条很重要，甚至有的测评机构都是随便拉人肤浅的测一下就出测试报告，未对报告进行审查，误报）

Use Source Code When Available

虽然黑盒渗透测试结果令人印象深刻，并且可用于演示漏洞在生产环境中的暴露方式，但它们并不是保护应用程序的最有效或高效的方法。动态测试很难测试整个代码库，尤其是在存在许多嵌套条件语句的情况下。如果应用程序的源代码可用，则应将其提供给安全人员，以便在执行审查时为他们提供帮助。可以发现应用程序源中的漏洞，这些漏洞在黑盒参与期间会被遗漏。

开发指标

一个好的安全计划的一个重要部分是能够确定情况是否正在好转。跟踪测试活动的结果，并制定指标以揭示组织内的应用程序安全趋势非常重要。

好的指标将显示：如果需要更多的教育和培训;如果存在开发团队不清楚的特定安全机制;如果发现的安全相关问题的总数正在减少。

可以从可用源代码中以自动方式生成的一致指标也将有助于组织评估为减少软件开发中的安全错误而引入的机制的有效性。指标不容易制定，因此使用IEEE提供的标准是一个很好的起点。

记录测试结果

为了结束测试过程，重要的是要制作一份正式的记录，说明采取了哪些测试措施，由谁执行，何时执行，以及测试结果的详细信息。明智的做法是就报告的可接受格式达成一致，该格式对所有相关方都有用，其中可能包括开发人员、项目管理、业务所有者、IT 部门、审计和合规性。

报告应向企业主明确指出存在重大风险的地方，并以足以获得他们支持后续缓解措施的方式进行。报告还应明确开发人员，以开发人员能够理解的语言查明受漏洞影响的确切功能以及解决问题的相关建议。该报告还应允许其他安全测试人员重现结果。编写报告不应给安全测试人员本身带来过重的负担。安全测试人员通常并不以其创造性的写作技巧而闻名，就复杂的报告达成一致可能会导致测试结果未正确记录的情况。使用安全测试报告模板可以节省时间，并确保准确、一致地记录结果，并且采用适合受众的格式。

2.3 测试技术解释

2.4人工审查

Manual inspections are human reviews that typically test the security implications of people, policies, and processes. Manual inspections can also include inspection of technology decisions such as architectural designs. They are usually conducted by analyzing documentation or performing interviews with the designers or system owners.

人工检查是人工审核，通常测试人员、策略和流程的安全影响。人工检查还可以包括对技术决策（如设计）的检查。它们通常通过分析文档或与设计人员或系统所有者进行访谈来进行。

其他活动，包括手动审查文档、安全编码策略、安全要求和架构设计，都应使用手动检查来完成。

2.5威胁建模 Threat Modeling

威胁建模已成为一种流行的技术，可帮助系统设计人员考虑其系统和应用程序可能面临的安全威胁。因此，威胁建模可以看作是应用程序的风险评估。它使设计人员能够针对潜在漏洞制定缓解策略，并帮助他们将不可避免的有限资源和注意力集中在系统中最需要它的部分。建议所有应用程序都开发并记录威胁模型。应尽早在 SDLC 中创建威胁模型，并应随着应用程序的发展和开发的进展而重新审视。

若要开发威胁模型，我们建议采用遵循 NIST 800-30 风险评估标准的简单方法。这种方法包括：

分解应用程序 – 使用手动检查过程来了解应用程序的工作方式、其资产、功能和连接性。
对资产进行定义和分类 – 将资产分为有形资产和无形资产，并根据业务重要性对其进行排名。
探索潜在的漏洞 - 无论是技术、运营还是管理漏洞。
探索潜在威胁 – 通过使用威胁场景或攻击树，从攻击者的角度对潜在攻击媒介进行现实的了解。
制定缓解策略 – 针对每个被认为现实的威胁制定缓解控制措施。

威胁模型本身的输出可能会有所不同，但通常是列表和图表的集合。各种开源项目和商业产品都支持应用程序威胁建模方法，这些方法可用作测试应用程序设计中潜在安全漏洞的参考。开发威胁模型和对应用程序执行信息风险评估的方法没有对错之分。

优势

系统的实际攻击者视图
灵活
在 SDLC 的早期

劣势

好的威胁模型并不意味着好的软件

2.6 源代码审查 Source Code Review

源代码审查是手动检查 Web 应用程序源代码是否存在安全问题的过程。

优势

完整性和有效性
准确性
快速（适用于称职的审稿人）

弊

需要具有高技能安全意识的开发人员
可能会错过已编译库中的问题
无法轻松检测运行时错误
实际部署的源代码可能与正在分析的源代码不同

有关代码审查的详细信息，请参阅 OWASP 代码审查项目

2.7 渗透测试 Penetration Testing

几十年来，渗透测试一直是用于测试网络安全的常用技术。它通常也被称为黑盒测试或道德黑客。渗透测试本质上是远程测试系统或应用程序以查找安全漏洞的“艺术”，而无需了解目标本身的内部工作原理。通常，渗透测试团队能够像用户一样访问应用程序。测试人员的行为类似于攻击者，并试图查找和利用漏洞。在许多情况下，测试人员将在系统上获得一个或多个有效帐户。

虽然渗透测试已被证明在网络安全方面是有效的，但该技术并不能自然地转化为应用程序。在网络和操作系统上执行渗透测试时，所涉及的大部分工作是查找然后利用特定技术中的已知漏洞。由于 Web 应用程序几乎完全是定制的，因此 Web 应用程序领域的渗透测试更类似于纯粹的研究。已经开发了一些自动化渗透测试工具，但考虑到 Web 应用程序的定制性质，仅凭它们的有效性可能很差。

许多人使用 Web 应用程序渗透测试作为他们的主要安全测试技术。虽然它在测试程序中肯定有一席之地，但我们认为不应将其视为主要或唯一的测试技术。正如 Gary McGraw 在《软件渗透测试》一书中所写的那样，“在实践中，渗透测试只能识别系统中所有可能的安全风险的一小部分代表性样本。但是，有针对性的渗透测试（即尝试利用先前审查中检测到的已知漏洞的测试）可用于检测某些特定漏洞是否在部署的源代码中实际得到修复。

优势

可以快速（因此便宜）
与源代码审查相比，需要相对较低的技能
测试实际公开的代码

弊

在 SDLC 中为时已晚
仅正面碰撞试验

2.8 需要采取兼顾各方利益的测试办法

由于有如此多的技术和方法来测试 Web 应用程序的安全性，因此很难理解使用哪些技术或何时使用它们。经验表明，对于究竟应该使用哪种技术来构建测试框架的问题，没有正确或错误的答案。事实上，所有技术都应该用于测试所有需要测试的区域。

尽管很明显，没有一种技术可以有效地涵盖所有安全测试并确保所有问题都得到解决，但许多公司只采用一种方法。过去使用的单一方法是渗透测试。渗透测试虽然有用，但不能有效地解决许多需要测试的问题。在SDLC中，它只是“太少太晚”。

正确的方法是平衡的方法，包括多种技术，从手动审查到技术测试，再到 CI/CD 集成测试。平衡的方法应涵盖 SDLC 所有阶段的测试。此方法利用了最合适的可用技术，具体取决于当前的 SDLC 阶段。

当然，有时和情况下只有一种技术是可能的。例如，考虑对已创建的 Web 应用程序进行测试，但测试方无权访问源代码。在这种情况下，渗透测试显然比完全没有测试要好。但是，应鼓励测试方挑战假设，例如无法访问源代码，并探索进行更完整测试的可能性。

平衡的方法取决于许多因素，例如测试过程的成熟度和企业文化。建议平衡测试框架应类似于图 3 和图 4 中所示的表示形式。下图显示了叠加到 SLDC 上的典型比例表示。根据研究和经验，公司必须更加重视开发的早期阶段。

Proportion of Test Effort in SDLC

图 2-3：SDLC 中测试工作的比例

Proportion of Test Effort According to Test Technique

图 2-4：根据测试技术的测试工作量比例

在定义和设计阶段，使用50%的安全测试，方法为过程审查和人工审查

开发阶段，采用code review方法

部署和生产阶段，采用security testing 安全测试方法（这里应该是指的渗透测试）

关于web扫描工具

自动的黑盒测试可能是无效的，但是也不应阻止使用 Web 应用程序扫描程序。相反，目的是确保理解这些限制并适当地规划测试框架。

了解自动漏洞检测工具的有效性和局限性很有帮助。为此，OWASP Benchmark Project 是一个测试套件，旨在评估自动化软件漏洞检测工具和服务的速度、覆盖范围和准确性。基准测试可以帮助测试这些自动化工具的功能，并有助于明确其有用性。

有的安全漏洞，可能通过手动检查（例如审查或代码检查）快速发现，而自动化黑盒测试则无法发现。可以用工具，但工具不是银弹

关于静态源代码审查工具的说明

许多组织已经开始使用静态源代码扫描程序。虽然它们无疑在综合测试计划中占有一席之地，但有必要强调一些基本问题，即为什么这种方法在单独使用时无效。仅靠静态源代码分析无法识别由于设计缺陷而导致的问题，因为它无法理解构建代码的上下文。源代码分析工具在确定由于编码错误引起的安全问题方面很有用，但是需要大量的手动工作来验证结果。

2.9派生安全测试要求

要有一个成功的测试程序，必须知道测试目标是什么。这些目标由安全要求指定。本节详细讨论如何通过从适用的标准和法规、正面应用程序要求（指定应用程序应该做什么）和负面应用程序要求（指定应用程序不应执行的操作）派生安全测试要求来记录这些要求。它还讨论了安全要求如何在 SDLC 期间有效地推动安全测试，以及如何使用安全测试数据来有效管理软件安全风险。

测试目标

安全测试的目标之一是验证安全控制是否按预期运行。这是通过描述安全控制的功能来记录的。在高层次上，这意味着证明数据和服务的机密性、完整性和可用性。另一个目标是验证实施的安全控制是否具有很少或没有漏洞。这些是常见的漏洞，例如 OWASP Top Ten，以及之前在 SDLC 期间通过安全评估确定的漏洞，例如威胁建模、源代码分析和渗透测试。security requirements

安全需求文档

记录安全要求的第一步是了解业务需求文档 .业务需求文档可以提供有关应用程序预期功能的初始高级信息。例如，应用程序的主要目的可能是向客户提供金融服务或允许从在线目录中购买商品。业务需求的安全部分应强调保护客户数据以及遵守适用的安全文档（如法规、标准和策略）的必要性。

适用法规、标准和策略的一般清单是 Web 应用程序的良好初步安全合规性分析。例如，可以通过检查有关业务部门以及应用程序将运行的国家或州的信息来识别合规性法规。其中一些合规性准则和法规可能会转化为安全控制的特定技术要求。例如，就金融应用程序而言，遵守联邦金融机构检查委员会（FFIEC）网络安全评估工具和文档要求金融机构实施应用程序，通过多层安全控制和多因素身份验证来降低弱身份验证风险。

通用安全要求清单还必须涵盖适用的安全行业标准。例如，对于处理客户信用卡数据的应用程序，遵守 PCI 安全标准委员会数据安全标准（DSS）禁止存储 PIN 和 CVV2 数据，并要求商家通过加密保护存储和传输中的磁条数据，并通过屏蔽来保护显示中的磁条数据。这种PCI DSS安全要求可以通过源代码分析来验证。

清单的另一部分需要强制执行遵守组织信息安全标准和策略的一般要求。从功能需求的角度来看，安全控制要求需要映射到信息安全标准的特定部分。此类要求的一个示例可以是：“应用程序使用的身份验证控件必须强制执行 10 个字母数字字符的密码复杂性。当安全要求映射到合规性规则时，安全测试可以验证合规性风险的暴露。如果发现违反信息安全标准和政策，这些将导致可以记录的风险，并且企业必须管理或解决。由于这些安全合规性要求是可强制执行的，因此需要通过安全测试对其进行充分的记录和验证。

（意思是安全需求可以来自需求文档、法律法规、行业法规、组织的一般规定）

安全要求验证

信息安全评估的主要目标是识别安全控制中的差距，例如缺乏基本的身份验证、授权或加密控制。进一步来说，安全评估的目标是风险分析，例如识别安全控制中的潜在弱点，以确保数据的机密性、完整性和可用性。例如，当应用程序处理个人身份信息（PII）和敏感数据时，要验证的安全要求是是否符合公司信息安全策略，该策略要求对传输和存储中的此类数据进行加密。假设使用加密来保护数据，则加密算法和密钥长度需要符合组织的加密标准。这些可能要求仅使用某些算法和密钥长度。例如，可以进行安全测试的安全要求是验证是否仅使用允许的密码（例如，SHA-256、RSA、AES）和允许的最小密钥长度（例如，对称加密超过 128 位，非对称加密超过 1024 位）。

从安全评估的角度来看，可以通过使用不同的工件和测试方法在 SDLC 的不同阶段验证安全要求。例如，威胁建模侧重于在设计过程中识别安全漏洞;安全代码分析和审查侧重于在开发过程中识别源代码中的安全问题;渗透测试侧重于在测试或验证期间识别应用程序中的漏洞。

在 SDLC 早期发现的安全问题可以记录在测试计划中，以便以后可以通过安全测试进行验证。通过结合不同测试技术的结果，可以得出更好的安全测试用例，并提高安全要求的保证水平。例如，当渗透测试和源代码分析的结果结合起来时，可以将真正的漏洞与不可利用的漏洞区分开来。例如，考虑到 SQL 注入漏洞的安全测试，黑盒测试可能首先涉及对应用程序进行扫描以识别漏洞。可以验证的潜在 SQL 注入漏洞的第一个证据是 SQL 异常的生成。对 SQL 漏洞的进一步验证可能涉及手动注入攻击媒介，以修改 SQL 查询的语法，以利用信息泄露漏洞。在执行恶意查询之前，这可能涉及大量的试错分析。假设测试人员拥有源代码，他们可能会直接从源代码分析中学习如何构建能够成功利用漏洞的 SQL 攻击媒介（例如，执行恶意查询，将机密数据返回给未经授权的用户）。这可以加快对 SQL 漏洞的验证。

威胁和对策分类法

对于 Web 应用程序，将安全控制暴露于常见漏洞（如 OWASP Top Ten）可以成为推导一般安全要求的良好起点。OWASP 测试指南清单是指导测试人员完成特定漏洞和验证测试的有用资源。

wstg/checklists/checklist.md at master · OWASP/wstg · GitHub

威胁和对策分类的重点是根据威胁和漏洞的根本原因定义安全要求。可以使用 STRIDE 对威胁进行分类，STRIDE 是欺骗、篡改、否认、信息泄露、拒绝服务和特权提升的首字母缩写词。根本原因可以归类为设计中的安全漏洞、编码中的安全错误或由于不安全的配置导致的问题。例如，弱身份验证漏洞的根本原因可能是当数据跨越应用程序的客户端和服务器层之间的信任边界时缺少相互身份验证。在架构设计审查期间捕获不可否认性威胁的安全要求允许记录对策（例如，相互身份验证）的要求，这些要求可以在以后通过安全测试进行验证。

漏洞的威胁和对策分类还可用于记录安全编码的安全要求，例如安全编码标准。身份验证控件中常见编码错误的一个示例包括应用哈希函数来加密密码，而不对值应用种子。从安全编码的角度来看，这是一个漏洞，它会影响用于身份验证的加密，其根本原因在于编码错误。由于根本原因是不安全的编码，因此可以在安全编码标准中记录安全要求，并在 SDLC 的开发阶段通过安全代码审查进行验证。

（意思是要对威胁进行分类，可以参考OWASP top10，）

安全测试与风险分析

安全需求需要考虑漏洞的严重性，以支持风险缓解策略 .假设组织维护在应用程序中发现的漏洞存储库（即漏洞知识库），则可以按类型、问题、缓解措施、根本原因报告安全问题，并将其映射到发现这些问题的应用程序。这样的漏洞知识库还可用于建立指标，以分析整个 SDLC 中安全测试的有效性。

例如，考虑输入验证问题，例如 SQL 注入，该问题通过源代码分析进行识别，并报告编码错误根本原因和输入验证漏洞类型。可以通过渗透测试来评估此类漏洞的暴露程度，方法是探测具有多个 SQL 注入攻击媒介的输入字段。此测试可能会验证在访问数据库之前是否筛选了特殊字符，并缓解了漏洞。通过结合源代码分析和渗透测试的结果，可以确定漏洞的可能性和暴露程度，并计算漏洞的风险等级。通过在调查结果（例如测试报告）中报告漏洞风险评级，可以决定缓解策略。例如，可以优先修复高风险和中风险漏洞，而低风险漏洞可以在将来的版本中修复。

通过考虑利用常见漏洞的威胁场景，可以识别应用程序安全控制需要进行安全测试的潜在风险。例如，OWASP 十大漏洞可以映射到网络钓鱼、侵犯隐私、身份盗窃、系统泄露、数据更改或数据破坏、经济损失和声誉损失等攻击。此类问题应作为威胁方案的一部分进行记录。通过考虑威胁和漏洞，可以设计一系列测试来模拟此类攻击场景。理想情况下，组织的漏洞知识库可用于派生安全风险驱动的测试用例，以验证最可能的攻击场景。例如，如果标识盗窃被视为高风险，则负面测试方案应验证因利用身份验证、加密控制、输入验证和授权控制中的漏洞而产生的影响的缓解措施。

推导功能和非功能测试要求

功能安全要求

从功能安全要求的角度来看，适用的标准、策略和法规既需要一种安全控制，也需要控制功能。这些要求也称为“积极要求”，因为它们说明了可以通过安全测试验证的预期功能。正面要求的示例包括：“应用程序将在六次登录尝试失败后锁定用户”或“密码至少需要包含 10 个字母数字字符”。对积极需求的验证包括断言预期的功能，可以通过重新创建测试条件并根据预定义的输入运行测试来测试。然后，结果显示为失败或通过条件。

为了通过安全测试验证安全要求，安全要求需要由功能驱动。他们需要突出预期的功能（什么）并暗示实现（如何实现）。身份验证的高级安全设计要求示例可以是：

在传输和存储中保护用户凭据或共享机密。
屏蔽显示中的任何机密数据（例如密码、帐户）。
在一定次数的登录尝试失败后锁定用户帐户。
不要由于登录失败而向用户显示特定的验证错误。
仅允许字母数字密码、包含特殊字符且长度至少为 10 个字符的密码，以限制攻击面。
通过验证旧密码、新密码和用户对质询问题的回答，仅允许经过身份验证的用户使用密码更改功能，以防止通过密码更改暴力破解密码。
密码重置表单应验证用户的用户名和用户注册的电子邮件，然后再通过电子邮件向用户发送临时密码。颁发的临时密码应为一次性密码。密码重置网页的链接将发送给用户。密码重置网页应验证用户的临时密码、新密码以及用户对质询问题的回答。

风险驱动的安全要求

安全测试也必须以风险为导向。他们需要验证应用程序是否存在意外行为或负面要求。

负面要求的示例包括：

应用程序不应允许更改或销毁数据。
恶意用户不应破坏或滥用该应用程序进行未经授权的金融交易。

负面需求更难测试，因为没有预期的行为要查找。寻找符合上述要求的预期行为可能需要威胁分析师不切实际地提出不可预见的输入条件、原因和影响。因此，安全测试需要由风险分析和威胁建模驱动。关键是记录威胁场景，以及作为缓解威胁的因素的对策的功能。

例如，在身份验证控制的情况下，可以从威胁和对策的角度记录以下安全要求：

对存储和传输中的身份验证数据进行加密，以降低信息泄露和身份验证协议攻击的风险。
使用不可逆加密（例如使用摘要（例如 HASH）和种子）来加密密码，以防止字典攻击。
在达到登录失败阈值后锁定帐户，并强制实施密码复杂性，以降低暴力破解密码攻击的风险。
在验证凭据时显示一般错误消息，以降低帐户收集或枚举的风险。
对客户端和服务器进行相互身份验证，以防止不可否认性和中间操纵器（MiTM）攻击。

威胁建模工具（如威胁树和攻击库）可用于派生负面测试方案。威胁树将假设根攻击（例如，攻击者可能能够读取其他用户的消息）并识别安全控制的不同漏洞（例如，由于 SQL 注入漏洞导致数据验证失败）和必要的对策（例如，实施数据验证和参数化查询），这些措施可以被验证为有效缓解此类攻击。

通过使用和误用案例推导出安全测试要求

描述应用程序功能的先决条件是了解应用程序应该做什么以及如何做。这可以通过描述用例来完成。用例，以软件工程中常用的图形形式，显示参与者的交互及其关系。它们有助于识别应用程序中的参与者、它们的关系、每个方案的预期操作顺序、替代操作、特殊要求、前提条件和后置条件。

与用例类似，误用或滥用案例描述了应用程序的意外和恶意使用场景。这些误用案例提供了一种方法来描述攻击者如何误用和滥用应用程序的方案。通过浏览使用场景中的各个步骤并考虑如何恶意利用它，可以发现应用程序的潜在缺陷或未明确定义的方面。关键是要描述所有可能的，或者至少是最关键的使用和误用场景。

滥用场景允许从攻击者的角度分析应用程序，并有助于识别潜在的漏洞和需要实施的对策，以减轻潜在暴露于此类漏洞所造成的影响。鉴于所有使用和滥用案例，重要的是要分析它们以确定哪些是最关键的，需要记录在安全要求中。识别最严重的误用和滥用案例会推动安全要求的记录，以及应减轻安全风险的必要控制措施。

为了从使用和误用案例中得出安全需求，定义功能场景和负面场景并以图形形式放置它们非常重要。以下示例是派生身份验证安全要求的分步方法。

步骤 1：描述功能方案

用户通过提供用户名和密码进行身份验证。应用程序根据应用程序对用户凭据的身份验证向用户授予访问权限，并在验证失败时向用户提供特定错误。

第 2 步：描述负面场景

攻击者通过对应用程序中的密码和帐户收集漏洞进行暴力破解或字典攻击来破坏身份验证。验证错误向攻击者提供特定信息，用于猜测哪些帐户是有效的注册帐户（用户名）。然后，攻击者尝试暴力破解有效帐户的密码。对最小长度为四位数的密码的暴力攻击可以在有限的尝试次数（即 10\^4）下成功。

第 3 步：使用和误用案例描述功能和负面场景

下面的图形示例描述了通过使用和误用案例推导安全要求的过程。功能方案由用户操作（输入用户名和密码）和应用程序操作（对用户进行身份验证并在验证失败时提供错误消息）组成。误用案例包括攻击者的行为，即试图通过字典攻击暴力破解密码和从错误消息中猜测有效用户名来破坏身份验证。通过以图形方式表示对用户操作（误用）的威胁，可以将对策推导出为缓解此类威胁的应用程序操作。

图 2-5：使用和误用案例

第 4 步：引出安全要求

在这种情况下，将派生以下身份验证的安全要求：

密码要求必须与当前标准保持一致，才能达到足够的复杂性。
帐户必须在五次登录尝试失败后锁定。
登录错误消息必须是通用的。

这些安全要求需要记录和测试。

2.10 安全测试集成在开发和测试工作流程中

开发工作流程中的安全测试

SDLC 开发阶段的安全测试是开发人员确保他们开发的各个软件组件在与其他组件集成或内置到应用程序中之前进行安全测试的第一个机会。软件组件可能由软件工件（如函数、方法和类）以及应用程序编程接口、库和可执行文件组成。对于安全测试，开发人员可以依靠源代码分析的结果来静态验证开发的源代码是否包含潜在漏洞，并且符合安全编码标准。安全单元测试可以进一步动态（即在运行时）验证组件是否按预期运行。在应用程序构建中集成新的和现有的代码更改之前，应查看和验证静态和动态分析的结果。

在集成到应用程序构建中之前验证源代码通常是高级开发人员的责任。高级开发人员通常是软件安全方面的主题专家，他们的角色是领导安全代码审查。他们必须决定是接受要在应用程序构建中发布的代码，还是要求进一步的更改和测试。这种安全的代码审查工作流可以通过正式验收以及工作流管理工具中的检查来强制执行。例如，假设用于功能错误的典型缺陷管理工作流，则可以在缺陷或变更管理系统上报告开发人员已修复的安全错误。然后，生成主机可以查看开发人员在工具中报告的测试结果，并授予将代码更改签入应用程序生成的批准。

测试工作流中的安全测试

在开发人员测试组件和代码更改并签入应用程序构建后，软件开发过程工作流中最有可能的下一步是对应用程序作为一个整体实体执行测试。这种级别的测试通常称为集成测试和系统级测试。当安全测试成为这些测试活动的一部分时，它们可用于验证整个应用程序的安全功能，以及应用程序级漏洞的暴露情况。应用程序上的这些安全测试包括白盒测试（如源代码分析）和黑盒测试（如渗透测试）。测试还可以包括灰盒测试，在灰盒测试中，假设测试人员对应用程序有一定的了解。例如，通过对应用程序的会话管理有一定的了解，测试人员可以更好地了解注销和超时函数是否得到适当的保护。

安全测试的目标是易受攻击的完整系统。在此阶段，安全测试人员可以确定漏洞是否可以被利用。其中包括常见的 Web 应用程序漏洞，以及 SDLC 中早些时候通过威胁建模、源代码分析和安全代码审查等其他活动确定的安全问题。

通常，当应用程序在集成系统测试范围内时，测试工程师（而不是软件开发人员）会执行安全测试。测试工程师具有 Web 应用程序漏洞、黑盒和白盒测试技术的安全知识，并负责此阶段安全需求的验证。为了执行安全测试，安全测试用例必须记录在安全测试指南和程序中。

在集成系统环境中验证应用程序安全性的测试工程师可能会发布应用程序以在操作环境中进行测试（例如，用户验收测试）。在 SDLC（即验证）的这个阶段，应用程序的功能测试通常由 QA 测试人员负责，而白帽黑客或安全顾问通常负责安全测试。一些组织依靠自己的专业道德黑客团队在不需要第三方评估时（例如用于审计目的）进行此类测试。

由于这些测试有时可能是在应用程序发布到生产环境之前修复漏洞的最后一道防线，因此按照测试团队的建议解决问题非常重要。这些建议可以包括代码、设计或配置更改。在这个级别，安全审计员和信息安全官根据信息风险管理程序讨论报告的安全问题并分析潜在风险。此类过程可能要求开发团队在部署应用程序之前修复所有高风险漏洞，除非此类风险得到承认和接受。

开发人员的安全测试

编码阶段的安全测试：单元测试

从开发人员的角度来看，安全测试的主要目标是验证代码的开发是否符合安全编码标准要求。开发人员自己的编码工件（例如函数、方法、类、API 和库）在集成到应用程序构建之前需要进行功能验证。

开发人员必须遵循的安全要求应记录在安全编码标准中，并通过静态和动态分析进行验证。如果单元测试活动遵循安全代码评审，则单元测试可以验证安全代码评审所需的代码更改是否已正确实现。通过源代码分析工具进行安全代码审查和源代码分析都可以帮助开发人员在开发源代码时识别源代码中的安全问题。通过使用单元测试和动态分析（例如调试），开发人员可以验证组件的安全功能，并验证正在开发的对策是否减轻了以前通过威胁建模和源代码分析确定的任何安全风险。

对于开发人员来说，一个好的做法是将安全测试用例构建为通用安全测试套件，该套件是现有单元测试框架的一部分。通用安全测试套件可以从先前定义的使用和误用案例派生到安全测试功能、方法和类。通用安全测试套件可能包括安全测试用例，以验证安全控制的正面和负面要求，例如：

身份、身份验证和访问控制
输入验证和编码
加密
用户和会话管理
错误和异常处理
审核和日志记录

开发人员可以通过集成到其 IDE 中的源代码分析工具、安全编码标准和安全单元测试框架来评估和验证正在开发的软件组件的安全性。可以运行安全测试用例来识别源代码中具有根本原因的潜在安全问题：除了进入和退出组件的参数的输入和输出验证外，这些问题还包括组件完成的身份验证和授权检查、组件内数据的保护、安全异常和错误处理以及安全审计和日志记录。可以调整单元测试框架（如 JUnit、NUnit 和 CUnit）来验证安全测试要求。对于安全功能测试，单元级测试可以在软件组件级别测试安全控件的功能，例如函数、方法或类。例如，测试用例可以通过断言组件的预期功能来验证输入和输出验证（例如，变量卫生）和变量的边界检查。

使用和误用案例标识的威胁场景可用于记录测试软件组件的过程。例如，在身份验证组件的情况下，安全单元测试可以断言设置帐户锁定的功能，以及不能滥用用户输入参数来绕过帐户锁定的事实（例如，通过将帐户锁定计数器设置为负数）。

在组件级别，安全单元测试可以验证正面断言和负面断言，例如错误和异常处理。捕获异常时，应不使系统处于不安全状态，例如，由于未取消分配资源（例如，连接句柄未在最终语句块中关闭）导致的潜在拒绝服务，以及潜在的权限提升（例如，在引发异常之前获得的更高权限，并且在退出函数之前未重新设置为上一级）。安全错误处理可以通过信息丰富的错误消息和堆栈跟踪来验证潜在的信息泄露。

单元级安全测试用例可以由安全工程师开发，安全工程师是软件安全领域的主题专家，还负责验证源代码中的安全问题是否已修复，是否可以签入集成系统构建。通常，应用程序构建的管理器还会确保在将第三方库和可执行文件集成到应用程序构建中之前，对潜在漏洞进行安全评估。

开发人员的安全测试指南中还记录了常见漏洞的威胁场景，这些漏洞的根本原因在于不安全的编码。例如，当对通过源代码分析识别的编码缺陷实施修复时，安全测试用例可以验证代码更改的实现是否遵循安全编码标准中记录的安全编码要求。

源代码分析和单元测试可以验证代码更改是否缓解了以前发现的编码缺陷所暴露的漏洞。自动安全代码分析的结果还可以用作版本控制的自动签入入口，例如，软件工件无法签入具有高或中等严重性编码问题的生成。

功能测试人员的安全测试

集成和验证阶段的安全测试：集成系统测试和操作测试

集成系统测试的主要目标是验证“纵深防御”概念，即安全控制的实施在不同层提供安全性。例如，在调用与应用程序集成的组件时缺少输入验证通常是可以通过集成测试进行测试的一个因素。

集成系统测试环境也是测试人员可以模拟真实攻击场景的第一个环境，这些场景可能由应用程序的恶意外部或内部用户执行。此级别的安全测试可以验证漏洞是否真实，是否可被攻击者利用。例如，在源代码中发现的潜在漏洞可能被评定为高风险，因为暴露于潜在的恶意用户，以及潜在的影响（例如，访问机密信息）。

可以使用手动测试技术和渗透测试工具来测试真实的攻击场景。这种类型的安全测试也称为道德黑客测试。从安全测试的角度来看，这些是风险驱动的测试，目的是在操作环境中测试应用程序。目标是代表要部署到生产中的应用程序版本的应用程序版本的应用程序内部版本。

在集成和验证阶段包括安全测试对于识别由于组件集成而导致的漏洞以及验证此类漏洞的暴露至关重要。应用程序安全测试需要一套专门的技能，包括软件和安全知识，这些技能不是安全工程师所具备的。因此，组织通常需要对其软件开发人员进行道德黑客技术以及安全评估程序和工具的安全培训。一个现实的方案是在内部开发此类资源，并将它们记录在安全测试指南和程序中，这些指南和程序考虑到了开发人员的安全测试知识。例如，所谓的“安全测试用例备忘单或清单”可以提供简单的测试用例和攻击向量，测试人员可以使用这些测试用例和攻击向量来验证暴露于常见漏洞，例如欺骗、信息泄露、缓冲区溢出、格式字符串、SQL 注入和 XSS 注入、XML、SOAP、规范化问题、拒绝服务以及托管代码和 ActiveX 控件（例如 .NET）。这些测试的第一组可以手动执行，并具有非常基本的软件安全知识。

安全测试的第一个目标可能是验证一组最低安全要求。这些安全测试用例可能包括手动强制应用程序进入错误和异常状态，以及从应用程序行为中收集知识。例如，可以通过用户输入注入攻击媒介，并检查是否将 SQL 异常抛回给用户来手动测试 SQL 注入漏洞。SQL 异常错误的证据可能是可被利用的漏洞的表现形式。

更深入的安全测试可能需要测试人员了解专门的测试技术和工具。除了源代码分析和渗透测试外，这些技术还包括：源代码和二进制故障注入、故障传播分析和代码覆盖率、模糊测试和逆向工程。安全测试指南应提供安全测试人员可用于执行此类深入安全评估的过程和推荐工具。

集成系统测试之后的下一个安全测试级别是在用户验收环境中执行安全测试。在操作环境中执行安全测试具有独特的优势。用户验收测试（UAT）环境是最能代表发布配置的环境，但数据除外（例如，使用测试数据代替真实数据）。UAT中安全测试的一个特点是测试安全配置问题。在某些情况下，这些漏洞可能代表高风险。例如，托管 Web 应用程序的服务器可能未配置最低权限、有效的 SSL 证书和安全配置、禁用基本服务以及清除测试和管理网页的 Web 根目录。

2.11安全测试数据分析和报告

安全测试指标和度量的目标

定义安全测试指标和度量的目标将安全测试数据用于风险分析和管理流程的先决条件。例如，度量值（例如通过安全测试发现的漏洞总数）可以量化应用程序的安全状况。这些度量还有助于确定软件安全测试的安全目标，例如，在将应用程序部署到生产环境之前，将漏洞数量减少到可接受的最小数量。

另一个可管理的目标可能是将应用程序安全态势与基线进行比较，以评估应用程序安全流程的改进。例如，安全指标基线可能包含仅通过渗透测试进行测试的应用程序。与基线相比，从在编码期间也经过安全测试的应用程序获得的安全数据应显示出改进（例如，更少的漏洞）。

在传统的软件测试中，软件缺陷的数量，例如在应用程序中发现的错误，可以提供软件质量的衡量标准。同样，安全测试可以提供软件安全性的衡量标准。从缺陷管理和报告的角度来看，软件质量和安全测试可以使用类似的分类来处理根本原因和缺陷补救工作。从根本原因的角度来看，安全缺陷可能是由于设计错误（例如安全漏洞）或编码错误（例如安全错误）造成的。从修复缺陷所需的工作量的角度来看，安全和质量缺陷都可以根据开发人员实施修复的时间、所需的工具和资源以及实施修复的成本来衡量。

与质量数据相比，安全测试数据的一个特征是根据威胁、漏洞暴露程度以及漏洞带来的潜在影响进行分类，以确定风险。测试应用程序的安全性包括管理技术风险，以确保应用程序对策满足可接受的级别。因此，在 SDLC 期间，安全测试数据需要支持关键检查点的安全风险策略。例如，通过源代码分析在源代码中发现的漏洞代表了风险的初始度量。漏洞的风险度量（例如，高、中、低）可以通过确定暴露和可能性因素，并通过渗透测试验证漏洞来计算。与安全测试中发现的漏洞相关的风险指标使业务管理层能够做出风险管理决策，例如决定是否可以在组织内的不同级别接受、减轻或转移风险（例如，业务风险和技术风险）。

在评估应用程序的安全状况时，必须考虑某些因素，例如正在开发的应用程序的大小。应用程序大小已通过统计证明与测试期间在应用程序中发现的问题数量有关。由于测试可以减少问题，因此比较小尺寸的应用程序更频繁地测试较大尺寸的应用程序是合乎逻辑的。

当安全测试分几个阶段进行时，测试数据可以证明安全测试在引入漏洞后立即检测漏洞的能力。测试数据还可以证明通过在SDLC的不同检查点实施对策来消除漏洞的有效性。这种类型的度量也被定义为“遏制指标”，并提供在开发过程的每个阶段执行的安全评估的度量，以维护每个阶段的安全性。这些遏制指标也是降低修复漏洞成本的关键因素。在发现漏洞的同一阶段处理漏洞的成本较低，而不是在以后的另一个阶段修复它们。

当安全测试指标与有形和定时目标相关联时，它们可以支持安全风险、成本和缺陷管理分析，例如：

将漏洞总数减少 30%。
在特定截止日期之前修复安全问题（例如，在测试版发布之前）。

安全测试数据可以是绝对的，例如在手动代码审查期间检测到的漏洞数量，也可以是比较的，例如与渗透测试相比，在代码审查中检测到的漏洞数量。要回答有关安全过程质量的问题，重要的是要确定可以被认为是可接受和良好的基线。

安全测试数据还可以支持安全分析的特定目标。这些目标可以是遵守安全法规和信息安全标准、管理安全流程、确定安全根本原因和流程改进以及安全成本效益分析。

当报告安全测试数据时，它必须提供指标来支持分析。分析的范围是对测试数据的解释，以找到有关所生产软件安全性以及过程有效性的线索。

安全测试数据支持的线索的一些示例可以是：

漏洞是否减少到可接受的发布级别？
本产品的安全质量与同类软件产品相比如何？
是否满足所有安全测试要求？
安全问题的主要根本原因是什么？
与安全漏洞相比，安全漏洞有多少？
哪种安全活动在查找漏洞方面最有效？
哪个团队在修复安全缺陷和漏洞方面更有效率？
高风险漏洞占总体漏洞的百分比是多少？
哪些工具在检测安全漏洞方面最有效？
什么样的安全测试在发现漏洞（例如，白盒与黑盒）测试方面最有效？
在安全代码审查期间发现了多少安全问题？
在安全设计评审期间发现了多少安全问题？

为了使用测试数据做出合理的判断，对测试过程和测试工具有很好的了解是很重要的。应采用工具分类法来决定使用哪些安全工具。当针对不同的工件时，安全工具可以被定性为善于发现常见的已知漏洞。

需要注意的是，未知的安全问题不会被测试。安全测试没有问题的事实并不意味着软件或应用程序是好的。

即使是最复杂的自动化工具也无法与经验丰富的安全测试人员相提并论。仅仅依靠自动化工具的成功测试结果会给安全从业者带来一种虚假的安全感。通常，安全测试人员对安全测试方法和测试工具越有经验，安全测试和分析的结果就越好。重要的是，对安全测试工具进行投资的管理人员还要考虑在雇用熟练的人力资源以及安全测试培训方面进行投资。