|
安全测试是在整个产品研发生周期中的各个阶段接入多种能力进行检查，以确保产品符合安全需求定义和产品质量标准的过程。 安全测试涉及多种角色，不同角色参与安全测试落地的形式也各不相同。 以测试工程师为例：安全测试时从内容安全、数据合规、功能合规、隐私保护等安全角度考虑，在需求迭代流程中评估安全风险，通过引入安全测试工具，编写安全角度的测试用例及测试用例执行，以挖掘安全漏洞和风险的一系列动作。 安全测试的目的是确定软件系统所有可能的安全漏洞和风险点，它们会带来信息、资金、声誉等多方面的影响。 随着互联网融入人们生活的方方面面，用户的衣食住行都有各种应用提供便利的服务，而与此同时也存在诸多风险，如隐私泄露、资产受损、身份盗用、文件加密勒索等，这些风险严重威胁着企业与用户的利益。 随着网络技术的不断发展，网络攻击的种类越来越多，攻击方式也越来越复杂，在这种情况下我们应用采用什么措施来应对及降低安全风险呢？这就涉及下面所提到的安全测试的落地。 根据开源安全测试方法手册 OSSTMM（Open Source Security Testing Methodology Manual）的表述，安全测试包括但不限于漏洞扫描、安全扫描、渗透测试、风险评估、安全审核、“道德”黑盒这几种做法。
在实际业务中，常见的安全漏洞有扫号漏洞、撞库漏洞、短信轰炸漏洞、接口越权、文件下载漏洞、接口敏感信息泄露漏洞等。 安全测试所涉及的知识领域十分庞大，除了各种安全测试方法、类型（黑盒、白盒、模糊测试）等，还涉及不同的端，如服务端、客户端、前端等。 那么有没有一套通用的规范将安全测试以较小的成本自然融入研发活动中，让RD（后端工程师）尽可能少做对各种工具的配置呢？ 这里要介绍的S-SDLC（Secure Software Development Lifecycle Project ，轻量级应用安全开发生命周期（S-SDLC) — OWASP-CHINA），可以将安全测试纳入，作为其中的一环，使安全测试和研发动作结合，同时进行。 随着互联网的不断发展，人们使用各种应用的时长越来越长和频次越来越高，与之而来的是不断加深的安全风险，而社会对于用户的数据安全也越发关注（如交易数据、浏览数据、搜索数据等）。 在这个大背景下，公司在寻求业务高速发展的同时把安全合规放到了特别重要的地位，S-SDLC也就逐步被引入。 微软最早提出了安全软件开发生命周期（S-SDLC），从安全角度指导软件开发过程的管理模式，定义软件开发生命周期中需求、设计、开发、测试及维护各个阶段的安全活动，其核心概念是让安全活动融合到整个开发生命周期，以发挥安全测试的最大能力。
S-SDLC 遇到的瓶颈： 安全本身并不是安全团队能够独立解决的问题。 由于 SDLC 无法实现责任共担，与现在的研发生命周期流程有割裂，因此更多的是安全部门主动向业务灌输需要解决哪些问题，业务方并不了解对应的收益。 对安全人员的投入与对业务人员的投入不成正比，目前（且长期也会）流程上是一对多的关系。公司内部对安全问题缺乏奖惩制度和规范；缺乏有效的度量框架，如 S-SDLC 做得好还是不好，由谁评估指标。如何激发业务人员对安全的积极性和投入度，尤其是在业务高速发展需要快速迭代的阶段。 如何突破以上瓶颈，下面介绍SDLC的进阶模式——DevSecOps。 DevSecOps是一种全新的安全理念于模式，从DevOps的概念延伸和演变而来，其核心理念为安全是整体IT团队（包括开发团队、运维团队、安全团队）中每个人的责任，需要贯穿从开发到运营整个业务生命周期的所有环节。 安全培训是S-SDLC流程中最早开展的一环，“流程未立意识先行”。 S-SDLC 流程的落地在一定程度上会改变大家早已习以为常的研发流程，这需要提前沟通；S-SDLC流程的落地也需要各种角色互相配合，只有这样流程才能顺利流转并发现安全漏洞。 基于以上两点，我们先进行安全培训的落地，其受众主要是业务RD，QA等直接参与流程建设的角色。培训内容主要有以下四个方面：
安全培训可以按照管理层对齐、试点子业务培训、整体业务培训等方式逐步递进，在顺利落地后，也可以考虑增加安全考核环节。如果RD为未参加安全培训，没有通过安全考核，则限制其合并代码、编译、提工单上线等权限，以保证安全培训在业务方的有效覆盖率。 安全测试在需求评审阶段就需要介入，S-SDLC流程跟敏捷测试流程一样，越早发现问题，修复的成本就越低，因此在需求评审阶段开展安全测试是十分有必要且有效的。 其中，安全测试是指在需求评审阶段增加 “安全评审环节” ，安全评审的执行方主要是安全部门、法务部门、审计部门、PR（公共关系）部门等，目的是在需求评审阶段就能够对本次提出的需求，从合规、反作弊、PR风险、数据敏感度、隐私保护等多方面进行评审。 若发现存在安全风险，则直接停止此项需求，防止风险流入后续环节，同时也避免了因为安全风险导致后续开发、测试、上线阶段的工作返工，造成资源浪费。 在需求评审阶段完成对需求的安全评审后，说明此项需求本身无安全风险，可以进入技术评审阶段。 技术评审更多关注的是代码实现维度上有无安全漏洞。在进行技术评审过程中，需要RD提供详细的技术方案，同时也需要详尽回复评审团队的疑问。 安全技术评审团队主要由公司的安全团队代表构成，此阶段主要从技术设计维度识别权限申请、日志记录、数据传输、编码等是否存在安全风险。 技术评审阶段完成后，RD 将进行针对本地需求的代码开发和自测/联调，这时我们也可以提供一些自测安全风险的工具，如白盒安全扫描工具，即将白盒安全扫描工具作为一个插件融入研发流程线，每次RD提交代码到开发分支后，自动出发流水线进行白盒安全扫描，查看有无安全漏洞。 若发现安全漏洞则将工单发送给安全工程师（Sec）进行回顾以确认是否需要立即修复，同时安全漏洞也会阻碍测试环境部署及后续代码合并操作，以此保证自测阶段的安全测试效果。 RD自测联调阶段的安全流程：
RD提测后进行QA测试阶段，这时QA可以对安全测试用例进行构造补充，通过对应的安全测试方法和工具进行安全测试，提交记录BUG单，并反馈给RD进行修复。 安全漏洞BUG单的修复情况也是判断后续能否进行代码合并上线的标准之一。 当测试完毕进入上线阶段时，可以进行安全测试的最后一轮验收，如需求的黑盒扫描，即通过一些SQL注入、服务端请求伪造等操作进行安全验证；也可以进行安全漏洞BUG单状态检查；App端也可以在打包时进行自动化安全扫描。上线完毕后，针对必要场景也可以申请外部“道德”黑盒资源对系统安全性进行再次验收。 上面几点是研发过程中进行的安全测试任务，与此同时，我们也需要配置一些常态化的安全测试任务进行相关验证，比如进行流量采集并将其去重和格式化、将请求分发到扫描节点后修改请求的参数进行流量回访，以此进行对应的安全漏洞扫描，若发现问题则通过消息机器人通知对应的RD。 其中，流量采集后也可以通过模糊测试的方式构建异常流量，生产出较为丰富的异常用例再次进行流量回放，以验证系统鲁棒性和安全性。 由于安全测试涉及的技术领域比较广泛，同时随着S-SDLC流程在业务中的逐步落地，所涉及的角色也在不断增加，因此无法由一种角色来完成安全测试的能力提供、推进落地、效果数据收集、流程优化等整个闭环。 一般而言，需要有以下三种角色参与：
角色安全测试合作模式如图：
当前，在隐私安全愈发重要的前提下，公司在追求业务高速发展的同时都更加求稳，而安全测试就是能最大限度降低数据、权限、隐私、PR等多方面带来极端风险的有效解决方案。 安全测试是必须开展的一项能力建设，毫不夸张地将，在某种程度上产品安全性的价值比功能丰富度的价值更高，甚至影响整个公司的发展，因此风险就是最大的损失，安全就是最好的回报。 Microsoft SDL 的简化实施 - 过程图示
安全培训贯穿始终：
|
|
|
