【SDL最初实践】安全测试

SDL可视作为软件安全方面的纵深防御，到了测试阶段也就代表着软件架构与设计已经定型、第三方开源组件的引用已基本不太可能改变、前面各环节的漏网安全bug已迎来最后一次发布前的检测。

01 安全目标

在我的最初实践中，SDL的发展和很多公司一样：由最开始的安全测试发展而来，一步步将安全前置，并保留系统发布上线前设置的卡点。不过已经将安全检查内容丰富化，把安全设计checklist、静态代码扫描、web漏洞扫描与人工安全测试的结果纳入检查，原则上各项均合格达标才能发布上线。

02 安全活动

在测试阶段，安全活动主要围绕安全报告验收、人工安全测试、漏洞验证开展。

1）报告验收

要求业务方将安全设计checklist自检报告、静态代码扫描报告、web漏洞扫描报告纳入安全提测工单中，待安全测试人员进行检查并通过后进行人工安全测试，各项的安全标准可参照：

值得注意的是需要设置抽查和复测机制，防止业务方有意或无意的提供不符合实际的报告，包括安全活动实施范围、安全活动结果。

2）人工测试

待各项安全报告均验收通过后，进行人工安全测试。在自动化验收和自动化安全测试之前，该活动往往会成为整个流程中压力最大和最易造成阻塞的点。据了解，部分公司会选择性进行人工安全测试；有的会针对特有的常见问题进行专项安全测试，比如仅测试越权漏洞…；有的会通过堆人进行较为全面的人工安全测试，比如内部没有hc就让很多外包驻场。

3）漏洞验证

人工安全测试往往是进一步提高软件的安全质量，发现之前各环节遗留的安全漏洞，包括但不限于：越权类漏洞、安全配置错误类漏洞、API返回过多敏感信息类漏洞、重要场景重放攻击以及常见的较为隐蔽web漏洞。然而同样重要的，还有推动安全漏洞修复，再次验证直至修复闭环。

03 安全实践

1）安全提测信息

• 测试环境一致：确保待测系统与生产环境一样，是保证安全测试质量的基础，但往往却较难实现。
• 测试环境可访问：由于网络ACL限制等因素导致安全测试人员一时不能访问，也是常见的一种现象，将安全测试时间花费在环境的准备上比较可惜。
• 测试账号提供：待测系统通常会有不同权限的账号，如果业务方不能完整提供，可能会导致越权、SQLi、信息泄露等常见安全bug漏测。
• 测试范围确定：指明安全提测类型是全量还是增量，如果是增量需要说明新增功能点至关重要，可提升安全测试的速度并保证一定的安全质量。

解决安全提测信息中可能遇到的各类问题，可以通过规范提测信息填写要求、提测信息核对处理流程、设置专人校对（刚入门不久的外包、实习生等）来解决。

2）安全测试思路

• 安全测试用例：在实现自动化安全测试前，沉淀一份具有本公司特点、集成团队成员测试技能的安全测试用例，变得十分有必要。首先，一定程度上能弥补团队成员因能力层次不齐而导致的安全测试质量不一，再者可以为实现自动化提供高命中规则；其次，可提供给新人快速上手，帮助新人成长至胜任安全测试工作；最后，对外输出给测试团队，赋能测试团队减轻安全团队的压力。
• 安全测试工具：被动测试工具，在团队内部越来越收到青睐，特别是面对多工单任务繁重的场景。将针对性强检测的插件集成到BurpSuite，进行被动式扫描，不失为一种简单高效的方法。
• 安全测试方法论：标准的安全测试流程不能督促团队成员去标准作业，亦不能弥补团队成员的能力差异。自动化安全测试，或许是解决这些问题的最佳方案。

3）安全漏洞管理

漏洞的产生到修复离不开安全人员和业务方，然而串联起他们之间的便是漏洞的管理流程和扭转状态。前者需要流程管理系统来支持，比如jira；后者需要自定义漏洞状态以及状态改变的触发动作，整个环节最终目标就是让漏洞被及时修复。

04 安全测试培训

（节选）

安全测试，最容易上手的我想应该是测试人员，基础技能知识相似，只需要改变一下思路，便可实现转型。以下是给测试团队培训过的几页培训材料，以及简短的课程大纲：

（图中截图表格来自于互联网）

05 持续优化

无论是什么技术，安全测试自动化是行业一致追求的目标，有效检出漏洞的同时较少人力投入。但在实现自动化前，还有半自动化、标准化可以选择，借助一些开源或现成的工具快速进行安全测试工作，往往也会有不错的效果。