移动应用安全测试¶

在以下章节中，我们将简要概述一般的安全测试原则和关键术语。所介绍的概念与在其他类型的渗透测试中发现的概念基本相同，因此，如果您是有经验的测试人员，您可能对某些内容很熟悉。

在本指南中，我们使用“移动应用安全测试”作为一个总括性的短语，指的是通过静态和动态分析来评估移动应用安全。诸如“移动应用渗透测试”和“移动应用安全审查”之类的术语在安全行业中使用的不一致，但是这些术语指的是大致相同的事情。移动应用安全测试通常是更大的安全评估或渗透测试的一部分，其中包括客户端-服务器架构和移动应用使用的服务器端 API。

在本指南中，我们在两种情况下介绍了移动应用安全测试。第一种是在开发生命周期结束时完成的“经典”安全测试。在这种情况下，测试人员访问几乎完成或准备好生产的版本应用，识别安全问题，并编写一份（通常是毁灭性的）报告。另一种情况的特征是从软件开发生命周期开始就实施需求和自动化安全测试。相同的基本要求和测试用例适用于这两种情况，但是高级方法和客户交互的级别有所不同。

测试原则¶

白盒测试与黑盒测试¶

让我们从定义概念开始

黑盒测试是在测试人员没有任何关于被测应用的信息的情况下进行的。此过程有时称为“零知识测试”。此测试的主要目的是允许测试人员像真正的攻击者一样，探索公开可用和可发现的信息的可能用途。
白盒测试（有时称为“完全知识测试”）与黑盒测试完全相反，因为测试人员完全了解应用。知识可能包括源代码、文档和图表。由于白盒测试具有透明性，并且测试人员可以通过获得的额外知识构建更加复杂和精细的测试用例，因此与黑盒测试相比，白盒测试可以更快地进行测试。
灰盒测试是介于上述两种测试类型之间的所有测试：向测试人员提供一些信息（通常仅是凭据），而其他信息则旨在被发现。这种类型的测试是在测试用例的数量、成本、速度和测试范围方面的一个有趣的折衷方案。灰盒测试是安全行业中最常见的测试类型。

我们强烈建议您索取源代码，以便您可以尽可能高效地利用测试时间。测试人员的代码访问权限显然不会模拟外部攻击，但是它简化了漏洞的识别，因为测试人员可以在代码级别验证每个已识别的异常或可疑行为。如果该应用以前没有经过测试，那么白盒测试是一个不错的选择。

即使在 Android 上反编译很简单，源代码也可能会被混淆，并且进行反混淆会很耗时。因此，时间限制是测试人员可以访问源代码的另一个原因。

漏洞分析¶

漏洞分析通常是在应用中寻找漏洞的过程。尽管可以手动完成，但是通常使用自动化扫描程序来识别主要漏洞。静态分析和动态分析是漏洞分析的类型。

静态分析与动态分析¶

静态应用程序安全测试 (SAST) 包括在不执行应用程序组件的情况下检查它们，方法是手动或自动分析源代码。 OWASP 提供了有关静态代码分析的信息，这些信息可能有助于您了解技术、优势、劣势和局限性。

动态应用程序安全测试 (DAST) 包括在运行时检查应用程序。这种类型的分析可以是手动的或自动的。它通常不提供静态分析所提供的信息，但是这是从用户的角度检测有趣元素（资产、功能、入口点等）的好方法。

现在我们已经定义了静态分析和动态分析，让我们更深入地研究一下。

静态分析¶

在静态分析期间，将审查移动应用的源代码，以确保安全控件的适当实施。在大多数情况下，将使用混合的自动/手动方法。自动扫描可以捕获容易发现的问题，而人工测试人员可以在考虑特定使用环境的情况下浏览代码库。

手动代码审查¶

测试人员通过手动分析移动应用的源代码来发现安全漏洞，从而执行手动代码审查。方法范围从通过“grep”命令进行基本关键字搜索到逐行检查源代码。 IDE（集成开发环境）通常提供基本的代码审查功能，并且可以通过各种工具进行扩展。

手动代码分析的常用方法是通过搜索某些 API 和关键字（例如数据库相关的方法调用，如“executeStatement”或“executeQuery”）来识别关键的安全漏洞指示器。包含这些字符串的代码是进行手动分析的一个很好的起点。

与自动代码分析相比，手动代码审查非常适合识别业务逻辑中的漏洞、标准违规和设计缺陷，尤其是在代码技术上安全但逻辑上有缺陷的情况下。自动代码分析工具不太可能检测到此类情况。

手动代码审查需要一位精通移动应用所用语言和框架的专家代码审查员。对于审查员来说，完整的代码审查可能是一个缓慢、繁琐、耗时的过程，尤其是在具有许多依赖项的大型代码库的情况下。

自动化源代码分析¶

自动化分析工具可用于加快静态应用程序安全测试 (SAST) 的审查过程。它们检查源代码是否符合预定义的规则集或行业最佳实践，然后通常会显示一个发现或警告列表，并标记所有检测到的违规行为。一些静态分析工具仅针对已编译的应用程序运行，一些必须馈入原始源代码，而另一些则在集成开发环境 (IDE) 中作为实时分析插件运行。

尽管一些静态代码分析工具包含了大量关于分析移动应用所需的规则和语义的信息，但它们可能会产生许多误报，尤其是在它们未针对目标环境进行配置的情况下。因此，安全专业人员必须始终审查结果。

动态分析¶

DAST 的重点是通过应用程序的实时执行来测试和评估应用程序。动态分析的主要目标是在程序运行时查找程序中的安全漏洞或薄弱点。动态分析是在移动平台层以及后端服务和 API 上进行的，可以在其中分析移动应用的请求和响应模式。

动态分析通常用于检查安全机制，这些机制可以提供足够的保护来抵御最常见的攻击类型，例如传输中数据的泄露、身份验证和授权问题以及服务器配置错误。

避免误报¶

自动化扫描工具¶

自动化测试工具缺乏对应用环境的敏感性是一个挑战。这些工具可能会识别出一个不相关的前在问题。这些结果称为“误报”。

例如，安全测试人员通常会报告在 Web 浏览器中可利用的漏洞，但这些漏洞与移动应用无关。发生这种误报的原因是用于扫描后端服务的自动化工具是基于常规的基于浏览器的 Web 应用。因此，会报告诸如 CSRF（跨站请求伪造）和跨站点脚本 (XSS) 之类的问题。

让我们以 CSRF 为例。成功的 CSRF 攻击需要以下条件

能够引诱已登录用户在用于访问易受攻击站点的 Web 浏览器中打开恶意链接。
客户端（浏览器）必须自动将会话 cookie 或其他身份验证令牌添加到请求中。

移动应用不满足这些要求：即使使用了 WebView 和基于 Cookie 的会话管理，用户单击的任何恶意链接也会在默认浏览器中打开，该浏览器具有单独的 Cookie 存储。

如果应用包含 WebView，则存储的跨站点脚本 (XSS) 可能是一个问题，并且如果应用导出 JavaScript 接口，甚至可能导致命令执行。但是，反射型跨站点脚本很少成为问题（即使它们是否应该存在是有争议的，转义输出只是一种最佳实践）。

无论如何，在进行风险评估时，请考虑漏洞利用场景；不要盲目信任扫描工具的输出。

渗透测试¶

经典方法包括对应用程序的最终或接近最终的版本进行全面的安全测试，例如，在开发过程结束时可用的版本。对于开发过程结束时的测试，我们建议将移动应用安全验证标准 (MASVS) 和相关的清单作为测试的基线。典型的安全测试结构如下

准备 - 定义安全测试的范围，包括识别适用的安全控件、组织的测试目标和敏感数据。更一般而言，准备工作包括与客户端的所有同步以及合法保护测试人员（测试人员通常是第三方）。请记住，未经书面授权攻击系统在世界许多地方都是非法的！
情报收集 - 分析应用程序的环境和架构上下文，以获得一般的上下文理解。
应用映射 - 基于先前阶段的信息；可以辅以自动扫描和手动浏览应用程序。映射可以彻底了解应用程序、其入口点、其持有的数据以及主要的潜在漏洞。然后，可以根据利用这些漏洞造成的损害对这些漏洞进行排名，以便安全测试人员可以确定它们的优先级。此阶段包括创建可能在测试执行期间使用的测试用例。
漏洞利用 - 在此阶段中，安全测试人员尝试通过利用在前一阶段中识别出的漏洞来渗透该应用程序。此阶段对于确定漏洞是否真实以及是否为真正实阳性是必需的。
报告 - 在此阶段（这对客户端至关重要），安全测试人员报告漏洞。这包括详细的漏洞利用过程，对漏洞的类型进行分类，记录攻击者是否能够破坏目标的风险，并概述测试人员非法访问的数据。

准备工作¶

必须在测试之前确定要测试应用程序的安全级别。安全要求应在项目开始时确定。不同的组织对于测试活动的投资具有不同的安全需求和可用资源。尽管 MASVS 1 级 (L1) 中的控件适用于所有移动应用，但与技术和业务利益相关者一起浏览 L1 和 2 级 (L2) MASVS 控件的整个清单是确定测试覆盖范围的好方法。

组织在某些地区可能具有不同的监管和法律义务。即使应用程序不处理敏感数据，某些 L2 要求也可能相关（由于行业法规或地方法律）。例如，对于金融应用程序，双因素身份验证 (2FA) 可能是强制性的，并且由国家/地区的中央银行和/或金融监管机构强制执行。

在与利益相关者的讨论期间，还可以审查在开发过程早期定义的安全目标/控制。某些控件可能符合 MASVS 控件，但是其他控件可能特定于组织或应用程序。

所有相关方必须就清单中的决定和范围达成一致，因为这些将定义所有安全测试的基线。

与客户协调¶

设置工作测试环境可能是一项具有挑战性的任务。例如，对企业无线访问接入点和网络的限制可能会阻碍在客户端场所执行的动态分析。公司政策可能禁止在企业网络中使用获得 Root 权限的手机或（硬件和软件）网络测试工具。实施 Root 检测和其他逆向工程对策的应用程序可能会大大增加进一步分析所需的工作量。

安全测试涉及许多侵入性任务，包括监视和操纵移动应用程序的网络流量，检查应用程序数据文件以及对 API 调用进行检测。安全控件（例如证书固定和 Root 检测）可能会阻碍这些任务，并大大降低测试速度。

为了克服这些障碍，您可能需要从开发团队请求该应用程序的两个构建变体。一个变体应该是发布版本，以便您可以确定已实施的控件是否正常工作并且无法轻易绕过。第二个变体应该是调试版本，对于该版本，某些安全控件已被禁用。测试两个不同的构建是覆盖所有测试用例的最有效方法。

根据参与的范围，此方法可能不可行。请求白盒测试的生产版本和调试版本将有助于您完成所有测试用例并清楚地说明应用程序的安全成熟度。客户可能希望黑盒测试侧重于生产应用程序及其安全控件有效性的评估。

应在准备阶段讨论两种测试类型的范围。例如，是否应调整安全控件应在测试之前确定。下面讨论了其他主题。

识别敏感数据¶

敏感信息的分类因行业和国家/地区而异。此外，组织可能会对敏感数据采取限制性观点，并且他们可能具有明确定义敏感数据的数据分类策略。

数据可能从三种一般状态访问

静态 - 数据位于文件或数据存储中
使用中 - 应用程序已将数据加载到其地址空间中
传输中 - 数据已在移动应用程序和设备上的终结点或使用进程之间交换，例如，在 IPC（进程间通信）期间

每种状态适当的审查程度可能取决于数据的重要性及其被访问的可能性。例如，与 Web 服务器上的数据相比，保存在应用内存中的数据可能更容易受到通过核心转储访问的攻击，因为攻击者比 Web 服务器更有可能获得对移动设备的物理访问权限。

如果没有数据分类策略，请使用以下通常被认为是敏感的信息列表

用户身份验证信息（凭据、PIN 等）
可被滥用于身份盗用的个人身份信息 (PII)：社会安全号码、信用卡号码、银行账号、健康信息
可能识别人员的设备标识符
损害将导致声誉损害和/或财务成本的高度敏感数据
任何其保护是一种法律义务的数据
应用程序（或其相关系统）生成的任何技术数据，用于保护其他数据或系统本身（例如，加密密钥）

必须在测试开始之前确定“敏感数据”的定义，因为如果没有定义，则可能无法检测到敏感数据的泄漏。

识别代码中与安全相关的上下文¶

在开发移动应用程序时，准确识别和处理代码库中与安全相关的上下文至关重要。这些上下文通常涉及诸如身份验证、加密和授权之类的操作，这些操作通常是安全攻击的目标。在这些区域中不正确地实现加密功能可能会导致重大的安全漏洞。

正确区分与安全相关的上下文有助于在安全测试期间最大限度地减少误报。误报会转移对实际问题的注意力并浪费宝贵的资源。以下是一些常见的场景

随机数生成：在身份验证或加密密钥生成之类的上下文中，使用可预测的随机数生成器可能是一个严重的安全漏洞。但是，并非所有随机数的用途都与安全相关。例如，对于非安全目的（例如对游戏中的项目列表进行洗牌）使用不太强大的随机数生成器通常是可以接受的。
哈希：哈希通常用于安全领域，用于存储密码或确保数据完整性。但是，对非敏感值（如设备的屏幕分辨率进行分析）进行哈希处理不是安全问题。
加密与编码：一种常见的误解是将编码（如 Base64）与加密混淆。 Base64 编码不是保护敏感数据的安全方法，因为它很容易逆转。至关重要的是要认识到何时数据需要实际加密（用于保密），何时因兼容性或格式化原因（如将二进制数据编码为文本格式进行传输）而被编码。将编码误解为安全措施可能会导致忽略敏感数据的实际加密需求。
API 令牌存储：在应用程序的代码中或不安全的位置（如 Android 上的 SharedPreferences 或 iOS 上的 UserDefaults）中以纯文本形式存储 API 令牌或密钥是一个常见的安全错误。但是，如果令牌用于非敏感的只读公共 API，这可能不是安全风险。将其与存储用于敏感或写入访问 API 的令牌进行对比，在其中不正确的存储将是一个重要的安全问题。

情报收集¶

情报收集涉及收集有关应用程序架构、应用程序服务的业务用例以及应用程序运行的上下文的信息。这些信息可以分为“环境”或“架构”。

环境信息¶

环境信息包括

组织对于该应用程序的目标。功能塑造用户与应用程序的交互方式，并且可能会使某些表面比其他表面更容易成为攻击者的目标。
相关行业。不同的行业可能有不同的风险概况。
利益相关者和投资者；了解谁对应用程序感兴趣并负责。
内部流程、工作流程和组织结构。组织特定的内部流程和工作流程可能会为业务逻辑漏洞创造机会。

架构信息¶

架构信息包括

移动应用：应用如何访问数据并在进程内对其进行管理，应用如何与其他资源通信并管理用户会话，以及应用是否检测到自身在越狱或 Root 的手机上运行并对这些情况做出反应。
操作系统：应用在其上运行的操作系统和 OS 版本（包括 Android 或 iOS 版本限制），应用是否应在具有移动设备管理 (MDM) 控件的设备上运行，以及相关的 OS 漏洞。
网络：安全传输协议（例如，TLS）的使用、使用强密钥和加密算法（例如，SHA-2）来保护网络流量加密、使用证书固定来验证终结点等。
远程服务：应用使用的远程服务以及它们是否受到破坏可能会破坏客户端。

应用映射¶

安全测试人员获得有关应用及其环境的信息后，下一步是映射应用的结构和内容，例如，识别其入口点、功能和数据。

当在白盒或灰盒范例中执行渗透测试时，项目内部的任何文档（架构图、功能规范、代码等）都可以极大地促进该过程。如果源代码可用，则使用 SAST 工具可以揭示有关漏洞的宝贵信息（例如，SQL 注入）。 DAST 工具可以支持黑盒测试并自动扫描应用：而测试人员将需要数小时或数天，而扫描程序可以在几分钟内执行相同的任务。但是，重要的是要记住，自动工具有局限性，并且只会找到已编程要查找的内容。因此，可能需要人工分析来补充自动工具的结果（直觉通常是安全测试的关键）。

威胁建模是一项重要的工件：来自研讨会的文档通常极大地支持识别安全测试人员需要的许多信息（入口点、资产、漏洞、严重性等）。强烈建议测试人员与客户讨论此类文档的可用性。威胁建模应成为软件开发生命周期的关键部分。它通常发生在项目的早期阶段。

OWASP 中定义的威胁建模指南通常适用于移动应用。

漏洞利用¶

不幸的是，时间和财务限制将许多渗透测试限制为通过自动化扫描程序进行应用映射（例如，进行漏洞分析）。尽管在上一阶段中识别出的漏洞可能很有趣，但必须根据五个方面确认其相关性

损害潜力 - 利用漏洞可能造成的损害
可重现性 - 重现攻击的容易程度
可利用性 - 执行攻击的容易程度
受影响的用户 - 受攻击影响的用户数量
可发现性 - 发现漏洞的容易程度

与所有可能性相反，某些漏洞可能无法利用，并且可能导致很小的妥协（如果有）。其他漏洞乍看之下可能无害，但在实际测试条件下可能会被确定为非常危险。仔细完成漏洞利用阶段的测试人员可以通过描述漏洞及其影响来支持渗透测试。

报告¶

仅当安全测试人员的发现被清楚地记录下来时，它们才对客户有价值。好的渗透测试报告应包括以下信息，但不限于以下内容

执行摘要
范围和环境的描述（例如，目标系统）
使用的方法
信息来源（由客户端提供或在渗透测试期间发现）
优先考虑的发现（例如，已通过 DREAD 分类构建的漏洞）
详细的发现
针对每个缺陷的修复建议

互联网上有许多渗透测试报告模板：谷歌是你的朋友！

安全测试与 SDLC¶

尽管安全测试的原则在最近的历史中并没有发生根本性的变化，但是软件开发技术已经发生了巨大的变化。虽然敏捷实践的广泛采用正在加速软件开发，但是安全测试人员必须变得更快、更敏捷，同时继续交付值得信赖的软件。

以下部分侧重于这种演变，并描述了当代的安全测试。

软件开发生命周期中的安全测试¶

毕竟，软件开发并不是很古老，因此很容易观察到在没有框架的情况下开发的结束。随着源代码的增长，我们都经历了控制工作的一组最小规则的需求。

过去，"瀑布"方法是最广泛采用的：开发按照预定义的顺序进行步骤。瀑布方法仅限于单个步骤，回溯能力是一个严重的缺点。虽然它们具有重要的积极特征（提供结构、帮助测试人员明确需要投入精力的地方、清晰易懂等），但它们也存在负面特征（创建信息孤岛、速度慢、专业团队等）。

随着软件开发的成熟，竞争加剧，开发人员需要更快地响应市场变化，同时以更小的预算创建软件产品。减少结构的想法变得流行，更小的团队进行协作，打破了整个组织的信息孤岛。"敏捷"概念应运而生（Scrum、XP 和 RAD 是敏捷实现的著名例子）；它使更自主的团队能够更快地协同工作。

安全最初并不是软件开发的组成部分。它是一种事后才考虑的做法，由运维团队在网络层面执行，他们不得不弥补糟糕的软件安全！虽然当软件程序位于边界内时，未集成的安全性是可能的，但随着网络、移动和物联网技术等新型软件消费方式的出现，这个概念变得过时了。如今，安全必须内置于软件中，因为弥补漏洞通常非常困难。

在以下部分中，"SDLC"将与 "安全 SDLC"交替使用，以帮助您内化安全是软件开发过程的一部分这一理念。同样，我们使用 DevSecOps 这个名称来强调安全性是 DevOps 的一部分这一事实。

SDLC 概述¶

SDLC 的一般描述¶

SDLC 总是包含相同的步骤（总体流程在瀑布范式中是顺序的，在敏捷范式中是迭代的）

对应用程序及其组件执行风险评估，以识别其风险概况。这些风险概况通常取决于组织的风险偏好和适用的监管要求。风险评估还基于各种因素，包括应用程序是否可以通过 Internet 访问以及应用程序处理和存储的数据类型。必须考虑到所有类型的风险：财务、营销、工业等。数据分类策略指定哪些数据是敏感的以及必须如何保护它们。
安全需求是在项目或开发周期的开始阶段确定的，此时正在收集功能需求。 滥用案例在创建用例时添加。如果团队（包括开发团队）需要，他们可能会接受安全培训（例如安全编码）。您可以使用 OWASP MASVS 根据风险评估阶段确定移动应用程序的安全需求。迭代地审查需求（当添加功能和数据类时）是很常见的，尤其是在敏捷项目中。
威胁建模基本上是对威胁的识别、枚举、优先级排序和初始处理，它是一个基础性的工件，必须随着架构开发和设计的进展而执行。安全架构（威胁模型的一个因素）可以在威胁建模阶段之后进行优化（包括软件和硬件方面）。建立安全编码规则，并创建将要使用的安全工具列表。阐明安全测试的策略。
所有安全需求和设计考虑因素都应存储在应用程序生命周期管理 (ALM) 系统（也称为问题跟踪器）中，开发/运维团队使用该系统以确保安全需求与开发工作流程紧密集成。安全需求应包含相关的源代码片段，以便开发人员可以快速参考这些片段。创建一个受版本控制的专用存储库，并且只包含这些代码片段，这是一种比传统方法（将指南存储在 Word 文档或 PDF 中）更有益的安全编码策略。
安全地开发软件。为了提高代码安全性，您必须完成诸如 安全代码审查、静态应用程序安全测试和 安全单元测试之类的活动。虽然这些安全活动存在质量类似物，但同样的逻辑必须应用于安全，例如，审查、分析和测试代码是否存在安全缺陷（例如，缺少输入验证、未能释放所有资源等）。
接下来是期待已久的发布候选版本测试：手动和自动 渗透测试（“Pentests”）。 动态应用程序安全测试通常也在这个阶段执行。
在软件通过所有利益相关者的验收期间被认证之后，它可以安全地过渡到运维团队并投入生产。
最后一个阶段，也经常被忽视，是软件在其使用寿命结束后安全地停用。

下图说明了所有阶段和工件

根据项目的一般风险概况，您可以简化（甚至跳过）某些工件，并且可以添加其他工件（正式的中介审批、某些点的正式文档等）。 始终记住两件事：SDLC 旨在降低与软件开发相关的风险，它是一个框架，可以帮助您建立控制以实现该目的。 这是 SDLC 的通用描述；始终根据您的项目定制此框架。

定义测试策略¶

测试策略指定将在 SDLC 期间执行的测试以及测试频率。测试策略用于确保最终软件产品满足安全目标，这些目标通常由客户的法律/营销/公司团队确定。测试策略通常在安全设计阶段创建，在风险已明确（在启动阶段期间）并且在代码开发（安全实施阶段）开始之前。该策略需要来自风险管理、先前的威胁建模和安全工程等活动的输入。

测试策略不需要正式编写：它可以通过故事（在敏捷项目中）来描述，可以在检查表中快速枚举，或者可以指定为给定工具的测试用例。但是，该策略必须绝对共享，因为它必须由不同于定义它的团队的团队来实施。此外，所有技术团队必须同意它，以确保它不会给他们中的任何一个带来不可接受的负担。

测试策略解决以下主题

目标和风险描述
满足目标、降低风险的计划，哪些测试是强制性的，谁将执行它们，如何以及何时执行它们
验收标准

为了跟踪测试策略的进度和有效性，应该定义指标，在项目期间不断更新，并定期沟通。可以写一整本书来选择相关指标；我们在这里能说的最多的是它们取决于风险概况、项目和组织。指标的示例包括以下内容

已成功实施的与安全控制相关的故事数量
安全控制和敏感功能的单元测试的代码覆盖率
通过静态分析工具为每个构建发现的安全错误的数量
安全错误积压的趋势（可以按紧急程度排序）

这些只是建议；其他指标可能与您的项目更相关。指标是控制项目的强大工具，前提是它们为项目经理提供了对正在发生的事情和需要改进的事情的清晰而综合的视角。

区分内部团队执行的测试和独立第三方执行的测试非常重要。内部测试通常有助于改进日常运营，而第三方测试对整个组织更有益。内部测试可以很频繁地执行，但是第三方测试最多一年发生一两次；此外，前者比后者便宜。两者都是必要的，并且许多法规强制要求独立第三方进行测试，因为此类测试可能更值得信赖。

瀑布模型中的安全测试¶

什么是瀑布模型以及如何安排测试活动¶

基本上，SDLC 没有强制要求使用任何开发生命周期：可以肯定地说，在任何情况下都可以（并且必须！）解决安全性问题。

瀑布方法在 21 世纪之前很流行。最著名的应用称为“V 模型”，其中各个阶段按顺序执行，您只能回溯一个步骤。此模型的测试活动按顺序发生，并且作为一个整体执行，主要是在生命周期中大多数应用程序开发完成的时候。这种活动顺序意味着即使在发现缺陷后可以更改代码，也很难更改在项目开始时建立的体系结构和其他因素。

敏捷/DevOps 和 DevSecOps 的安全测试¶

DevOps 指的是专注于软件开发（通常称为 Devs）和运营（通常称为 Ops）中涉及的所有利益相关者之间密切协作的实践。 DevOps 不是关于合并 Devs 和 Ops。开发和运营团队最初在信息孤岛中工作，当时将开发的软件推送到生产环境可能需要大量时间。当开发团队通过使用敏捷开发使更多交付到生产环境变得必要时，运营团队不得不加快速度以适应节奏。 DevOps 是解决该挑战的必要演变，因为它允许软件更快地发布给用户。这主要通过广泛的构建自动化、测试和发布软件的过程以及基础设施变更（除了 DevOps 的协作方面）来实现。这种自动化体现在部署管道中，具有持续集成和持续交付 (CI/CD) 的概念。

人们可能认为术语“DevOps”仅代表开发和运营团队之间的协作，但是，正如 DevOps 思想领袖 Gene Kim 所说：“乍一看，似乎问题仅仅存在于 Devs 和 Ops 之间，但是测试也在其中，并且您具有信息安全目标以及保护系统和数据的需求。这些是管理层的首要关注事项，并且它们已成为 DevOps 蓝图的一部分。”

换句话说，DevOps 协作包括质量团队、安全团队以及与项目相关的许多其他团队。当您今天听到“DevOps”时，您可能应该想到类似 DevOpsQATestInfoSec 的东西。实际上，DevOps 的价值不仅在于提高速度，还在于提高质量、安全性、可靠性、稳定性和弹性。

对于业务成功而言，安全性与应用程序的整体质量、性能和可用性同样重要。随着开发周期缩短和交付频率增加，确保从一开始就构建质量和安全至关重要。 DevSecOps 的全部内容是将安全性添加到 DevOps 流程中。大多数缺陷是在生产期间发现的。 DevOps 指定了最佳实践，用于在生命周期早期尽可能多地识别缺陷，并最大限度地减少已发布应用程序中的缺陷数量。

但是，DevSecOps 不仅仅是一个面向向运营部门交付最佳软件的线性流程；它还要求运营部门密切监控生产中的软件，以识别问题并通过与开发部门形成快速有效的反馈回路来修复问题。 DevSecOps 是一个非常强调持续改进的过程。

这种强调的人性化方面体现在创建跨职能团队，这些团队共同努力以实现业务成果。本节重点介绍必要的交互以及将安全性集成到开发生命周期中（从项目开始到最终向用户交付价值）。

什么是敏捷和 DevSecOps 以及如何安排测试活动¶

概述¶

自动化是 DevSecOps 的一项关键实践：如前所述，与传统方法相比，从开发到运营的交付频率有所提高，并且通常需要时间的活动需要跟上，例如，在减少时间的同时交付相同的附加值。因此，必须放弃非生产性活动，并且必须加快基本任务。这些变化会影响基础设施变更、部署和安全性

基础设施正在作为 基础设施即代码 实现
部署变得更加脚本化，通过 持续集成 和 持续交付 的概念进行转换
安全活动 正在尽可能地自动化，并在整个生命周期中进行

以下各节提供了有关这三个点的更多详细信息。

基础设施即代码¶

基础设施即代码不是手动配置计算资源（物理服务器、虚拟机等）和修改配置文件，而是基于使用工具和自动化来加快配置过程并使其更可靠和可重复。相应的脚本通常存储在版本控制下，以方便共享和解决问题。

基础设施即代码实践促进了开发和运营团队之间的协作，结果如下

Devs 从熟悉的角度更好地了解基础设施，并且可以准备正在运行的应用程序将需要的资源。
Ops 运营一个更适合应用程序的环境，并且他们与 Devs 共享一种语言。

基础设施即代码还有助于构建经典软件创建项目所需的环境，用于开发 (“DEV”)、集成 (“INT”)、测试 (“PPR”表示预生产。一些测试通常在较早的环境中执行，并且 PPR 测试主要与在数据方面与生产中使用的数据相似的数据进行非回归和性能测试）和生产 (“PRD”)。基础设施即代码的价值在于环境之间可能存在的相似性（它们应该相同）。

基础设施即代码通常用于具有基于云的资源的项目，因为许多供应商提供可用于配置项目（例如虚拟机、存储空间等）和处理配置（例如，修改虚拟机使用的内存大小或 CPU 数量）的 API。这些 API 为管理员从监视控制台执行这些活动提供了替代方案。

该领域的主要工具是 Puppet、Terraform、Packer、Chef 和 Ansible。

部署¶

部署管道的复杂性取决于项目组织或开发团队的成熟度。在其最简单的形式中，部署管道由提交阶段组成。提交阶段通常涉及运行简单的编译器检查和单元测试套件，以及创建应用程序的可部署工件。发布候选版本是已签入到版本控制系统主干中的最新版本。部署管道会评估发布候选版本是否符合必须满足的用于部署到生产环境的标准。

提交阶段旨在为开发人员提供即时反馈，因此在每次提交到主干时都会运行。由于这种频率，因此存在时间限制。提交阶段通常应在五分钟内完成，并且不应超过十分钟。在安全性方面，坚持这一时间限制非常具有挑战性，因为许多安全工具无法足够快地运行 (#paul, #mcgraw)。

CI/CD 在某些上下文中表示“持续集成/持续交付”，而在另一些上下文中表示“持续集成/持续部署”。实际上，逻辑是

持续集成构建操作（由提交触发或定期执行）使用所有源代码来构建候选发布版本。然后可以执行测试，并且可以检查发布版本是否符合安全性、质量等规则。如果确认合规性，则可以继续该过程；否则，开发团队必须修复问题并提出更改。
持续交付候选发布版本可以进入预生产环境。如果随后可以验证该版本（手动或自动），则可以继续进行部署。如果不是，将会通知项目团队，并且必须采取适当的措施。
持续部署发布版本直接从集成过渡到生产环境，例如，用户可以访问它们。但是，如果在先前的活动中发现了重大缺陷，则不应将任何发布版本投入生产。

敏感性低或中的应用程序的交付和部署可以合并为一个步骤，并且可以在交付后执行验证。但是，强烈建议对敏感应用程序保持这两个操作分开并使用强验证。

安全性¶

此时，最大的问题是：既然交付代码所需的其他活动完成得更快、更有效，那么安全性如何跟上？我们如何保持适当的安全级别？更频繁地向用户交付价值，而安全性降低肯定不好！

再一次，答案是自动化和工具：通过在整个项目生命周期中实施这两个概念，您可以维护和提高安全性。预期的安全级别越高，将进行的控制、检查点和强调就越多。以下是一些示例

静态应用程序安全测试可以在开发阶段进行，并且可以集成到持续集成过程中，或多或少地强调扫描结果。您可以建立或多或少苛刻的安全编码规则，并使用 SAST 工具来检查其实现的有效性。
动态应用程序安全测试可以在应用程序构建后（例如，在持续集成之后）和交付之前自动执行，或多或少地强调结果。
您可以在连续阶段之间添加手动验证检查点，例如，在交付和部署之间。

必须在运营期间考虑使用 DevOps 开发的应用程序的安全性。以下是一些示例

应定期进行扫描（在基础架构和应用程序级别）。
可以定期进行渗透测试。（在生产中使用的应用程序版本是应该进行渗透测试的版本，并且测试应该在专用环境中进行，并且包括与生产版本数据相似的数据。有关更多详细信息，请参见渗透测试部分。）
应执行主动监视，以识别问题并通过反馈回路尽快修复它们。

参考资料¶

[paul] - M. Paul. Official (ISC)2 Guide to the CSSLP CBK, Second Edition ((ISC)2 Press), 2014
[mcgraw] - G McGraw. Software Security: Building Security In, 2006