开发工作流程中的安全测试
SDLC开发阶段的安全测试代表了开发人员第一次有机会确保他们开发的各个软件组件在与其他组件集成并内置到应用程序之前进行了安全测试。软件组件可能包含软件工件，如函数，方法和类，以及应用程序编程接口，库和可执行文件。对于安全性测试，开发人员可以依靠源代码分析的结果来静态验证开发的源代码不包含潜在的漏洞并且符合安全编码标准。安全单元测试可以进一步动态地（即，在运行时）验证组件按预期运行。
在应用程序构建中集成之前验证源代码通常是高级开发人员的责任。这些高级开发人员也是软件安全方面的主题专家，他们的角色是领导安全的代码审查。他们必须决定是否接受要在应用程序构建中发布的代码，还是需要进一步的更改和测试。可以通过正式接受以及工作流管理工具中的检查来强制执行此安全代码审查工作流程。例如，假设用于功能错误的典型缺陷管理工作流，可以在缺陷或变更管理系统上报告由开发人员修复的安全漏洞。
测试工作流程中的安全测试
在开发人员测试组件和代码更改并检入应用程序构建之后，软件开发过程工作流程中最可能的下一步是作为整个实体对应用程序执行测试。此级别的测试通常称为集成测试和系统级测试。当安全测试是这些测试活动的一部分时，它们可用于验证整个应用程序的安全功能，以及应用程序级漏洞的风险。这些应用程序的安全测试包括白盒测试（如源代码分析）和黑盒测试（如渗透测试）。灰盒测试类似于黑盒测试。在灰盒子测试中，假设测试人员对应用程序的会话管理有一些部分知识，
安全测试的目标是可能受到攻击的完整系统，包括整个源代码和可执行文件。在此阶段，安全测试的一个特点是安全测试人员可以确定是否可以利用漏洞并将应用程序暴露给真正的风险。其中包括常见的Web应用程序漏洞，以及早期在SDLC中发现的安全问题，以及威胁建模，源代码分析和安全代码审查等其他活动。
通常，当应用程序处于集成系统测试的范围内时，测试工程师而不是软件开发人员会执行安全测试。这些测试工程师具有Web应用程序漏洞，黑盒和白盒安全测试技术的安全知识，并且在此阶段拥有安全要求的验证。为了执行此类安全测试，必须在安全测试指南和过程中记录安全测试用例。
在集成系统环境中验证应用程序安全性的测试工程师可能会释放应用程序以在操作环境中进行测试（例如，用户验收测试）。在SDLC的这个阶段（即验证），应用程序功能测试通常是QA测试人员的责任，而白帽黑客或安全顾问通常负责安全测试。当不需要第三方评估时（例如出于审计目的），一些组织依靠他们自己的专业道德黑客团队来进行此类测试。
由于这些测试是在将应用程序发布到生产之前修复漏洞的最后手段，因此按照测试团队的建议解决此类问题非常重要。建议可包括代码，设计或配置更改。在此级别，安全审计员和信息安全官员根据信息风险管理程序讨论报告的安全问题并分析潜在风险。此类过程可能需要开发团队在部署应用程序之前修复所有高风险漏洞，除非这些风险得到承认和接受。
开发人员的安全测试
编码阶段的安全测试：单元测试
从开发人员的角度来看，安全测试的主要目标是验证代码的开发是否符合安全编码标准要求。开发人员自己的编码工件（例如函数，方法，类，API和库）需要在集成到应用程序构建之前进行功能验证。
开发人员必须遵循的安全要求应记录在安全编码标准中，并通过静态和动态分析进行验证。如果单元测试活动遵循安全代码审查，则单元测试可以验证安全代码审查所需的代码更改是否正确实现。通过源代码分析工具进行安全的代码审查和源代码分析，帮助开发人员在开发源代码时识别安全问题。通过使用单元测试和动态分析（例如，调试），开发人员可以验证组件的安全功能，并验证正在开发的对策可以减轻先前通过威胁建模和源代码分析确定的任何安全风险。
开发人员的一个好习惯是将安全测试用例构建为通用安全测试套件，它是现有单元测试框架的一部分。通用安全测试套件可以从先前定义的使用和误用情况导出到安全测试功能，方法和类。通用安全测试套件可能包含安全测试用例，以验证安全控制的正面和负面要求，例如：
- 身份，身份验证和访问控制
- 输入验证和编码
- 加密
- 用户和会话管理
- 错误和异常处理
- 审计和记录
开发人员可以使用集成到其IDE中的源代码分析工具，安全编码标准和安全单元测试框架来评估和验证正在开发的软件组件的安全性。可以运行安全测试用例来识别源代码中存在根本原因的潜在安全问题：除了进入和退出组件的参数的输入和输出验证之外，这些问题还包括组件进行的身份验证和授权检查，以及对组件内数据的保护。组件，安全异常和错误处理，以及安全审计和日志记录。可以调整Junit，Nunit和CUnit等单元测试框架以验证安全测试要求。在安全功能测试的情况下，单元级别测试可以测试软件组件级别的安全控件的功能，例如函数，方法或类。例如，测试用例可以通过断言组件的预期功能来验证输入和输出验证（例如，变量卫生）和变量的边界检查。
使用和滥用情况确定的威胁情景可用于记录测试软件组件的过程。例如，在认证组件的情况下，安全单元测试可以断言设置帐户锁定的功能以及不能滥用用户输入参数以绕过帐户锁定的事实（例如，通过将帐户锁定计数器设置为负数）。
在组件级别，安全单元测试可以验证肯定断言以及否定断言，例如错误和异常处理。应该在不使系统处于不安全状态的情况下捕获异常，例如由于资源未被解除分配而导致的潜在拒绝服务（例如，连接句柄未在最终语句块中关闭），以及可能的特权提升（例如，在退出异常之前获取的更高权限，并且在退出函数之前不会重新设置为上一级别。安全的错误处理可以通过信息性错误消息和堆栈跟踪验证潜在的信息泄露。
单元级安全测试用例可由安全工程师开发，安全工程师是软件安全的主题专家，并且还负责验证源代码中的安全问题已得到修复并可以检入集成系统构建中。通常，应用程序构建的管理者还确保第三方库和可执行文件在集成到应用程序构建之前针对潜在漏洞进行安全评估。
开发人员的安全测试指南中还记录了在不安全编码中具有根本原因的常见漏洞的威胁情景。例如，当针对源代码分析识别的编码缺陷实施修复时，安全测试用例可以验证代码更改的实现是否遵循安全编码标准中记录的安全编码要求。
源代码分析和单元测试可以验证代码更改可以减轻先前识别的编码缺陷所暴露的漏洞。自动安全代码分析的结果也可以用作版本控制的自动检入门，例如，软件工件无法检查到具有高或中等严重性编码问题的构建。
功能测试人员的安全测试
集成和验证阶段的安全测试：集成系统测试和操作测试集成系统测试
的主要目标是验证“纵深防御”概念，即安全控制的实现在不同层提供安全性。例如，在调用与应用程序集成的组件时缺少输入验证通常是可以使用集成测试进行测试的因素。
集成系统测试环境也是测试人员可以模拟真实攻击场景的第一个环境，可能由应用程序的恶意外部或内部用户执行。此级别的安全测试可以验证漏洞是否真实并且可以被攻击者利用。例如，源代码中发现的潜在漏洞由于潜在的恶意用户的暴露以及潜在的影响（例如，访问机密信息）而被评为高风险。
可以使用手动测试技术和渗透测试工具测试真实的攻击情形。此类安全测试也称为道德黑客测试。从安全测试的角度来看，这些是风险驱动的测试，其目标是在操作环境中测试应用程序。目标是应用程序构建，代表正在部署到生产中的应用程序的版本。
在集成和验证阶段包括安全测试对于识别由于组件集成而导致的漏洞以及验证此类漏洞的暴露至关重要。应用程序安全测试需要一组专业技能，包括软件和安全知识，这些技能并非典型的安全工程师。因此，组织经常需要对其软件开发人员进行道德黑客技术，安全评估程序和工具的安全培训。一个现实的场景是在内部开发此类资源，并将其记录在安全测试指南和程序中，并考虑开发人员的安全测试知识。例如，所谓的“安全测试用例作弊列表或检查列表” 可以提供简单的测试用例和攻击向量，测试人员可以使用它们来验证常见漏洞的暴露，例如欺骗，信息泄露，缓冲区溢出，格式字符串，SQL注入和XSS注入，XML，SOAP，规范化问题，拒绝服务和托管代码和ActiveX控件（例如，.NET）。可以使用非常基本的软件安全知识手动执行这些测试的第一组电池。
安全测试的第一个目标可能是验证一组最低安全要求。这些安全测试用例可能包括手动强制应用程序进入错误和异常状态，并从应用程序行为中收集知识。例如，可以通过用户输入注入攻击向量并检查SQL异常是否被抛回用户来手动测试SQL注入漏洞。SQL异常错误的证据可能是可以利用的漏洞的表现。
更深入的安全测试可能需要测试人员对专业测试技术和工具的了解。除了源代码分析和渗透测试之外，这些技术还包括，例如，源代码和二进制故障注入，故障传播分析和代码覆盖，模糊测试和逆向工程。安全测试指南应提供程序并推荐安全测试人员可用于执行此类深入安全评估的工具。
集成系统测试后的下一级安全测试是在用户接受环境中执行安全测试。在操作环境中执行安全测试具有独特的优势。用户验收测试环境（UAT）是最能代表发布配置的环境（UAT），但数据除外（例如，使用测试数据代替实际数据）。UAT中的安全测试的一个特征是测试安全配置问题。在某些情况下，这些漏洞可能代表高风险。例如，承载Web应用程序的服务器可能未配置最低权限，有效SSL证书和安全配置，禁用基本服务以及未从测试和管理网页清除Web根目录。
来源：oschina
链接：https://my.oschina.net/u/3447023/blog/3017483