G.J.Myers在《软件测试的艺术》中提出：从心理学角度来说，测试是一个为了寻找错误而运行程序的过程。
那么安全测试则是一个寻找系统潜在安全问题的过程，通过测试手段发现系统中可能存在的安全问题和风险，分析并进行优化，保障系统的安全质量。
从应用安全维度出发，展开系列安全测试工作，包括不限于：安全前置扫描、安全渗透测试、数据安全、SDL流程引入等。
本文我们将以围绕系统安全质量提升为目标，讲述在安全前置扫描上实践开展过程。
希望通过此篇文章，帮助大家更深入、透彻地了解安全测试，能快速开展安全测试。
1.工单分析-明确来源
在开展扫描前，首先对现有工单漏洞进行分析。
（1）漏洞来源分析
漏洞占比分布：
开源组件-版本问题、代码扫描 ，这两类占比91%；
这两类主要为编译时，平台自动调用安全部代码扫描接口发起的扫描；
安全部按照规则，则形成漏洞工单下发研发。
白盒漏洞分布：
检测分支：master分支、uat分支、test分支等。
即：所有在jdos上进行部署的分支都会进行扫描，扫描出的问题都是工单的产生来源。
JSRC类分析：
外部白帽在JSRC上提交的问题：https://security.jd.com，相关部门再下发形成工单。
（2）形成预防措施
通过上述分析，开展的具体措施：
1.开展前置扫描。在行云部署编译之前，主动发起安全前置扫描，避免遗漏到线上。并且统一代码安全扫描规则，避免内部扫描过代码仍存在代码扫描类漏洞。
2.安全质量卡控。研发测试落实代码安全扫描，安全扫描作为上线必备环节，触发形成自动扫描，漏出问题修复后才可进行上线编译。
3.开展渗透测试。针对外网系统和内网敏感系统已上线系统开展渗透测试，新需求接入安全SDL安全研发生命周期进行管理。
4.前置扫描-解决存量
通过对应用代码白盒扫描，应用域名的黑盒扫描，前置识别问题，预防缺陷，减少漏洞。以及在扫描过程中进行工具提效，近一步提高前置识别预防的范围。
①基于流水线源代码安全审计原子的master分支扫描
在部门刚开始做扫描时，使用流水线方式，优先流水线方式，实现持续的集成扫描，流水线主要步骤为：
扫描分支：master分支
触发条件：码提交触发、定时触发
邮件通知：通过邮件进行扫描报告链接下发
问题跟进：人工查看报告-漏洞分类整理-下发任务至研发
总结：
能有效地覆盖master分支的扫描，但是存在的问题是：
覆盖分支有限，造成非master分支漏洞遗漏；
如需新增覆盖分支，则需新建流水线，耗时不变；
人工方式的问题梳理，效率低，易出错。
②活跃分支的预防扫描
部署平台上的编译分支，除master外，其他编译分支也会产生漏洞工单。
仅进行master分支扫描，不能完全预防白盒漏洞问题。
故：抓取活跃分支-提交活跃分支代码扫描-形成全分支扫描覆盖
识别活跃分支：
安全代码扫描平台：
活跃分支扫描结果。
总结：
基于以上，实现了master分支+活跃分支的扫描覆盖，完全覆盖，可完全前置识别白盒漏洞问题。
Step1：获取域名基于域名、解析IP的黑盒扫描。
**Step2：**白盒漏洞扫描执行：
整理漏洞扫描结果：
问题：白盒&黑盒扫描，包含【提交任务-获取结果-漏洞整理-问题下发】的实施步骤，过程中，纯手工操作：时
间长，问题收集、整理，易遗漏&出错 。白盒扫描覆盖率低，遗漏的问题形成工单。
方案：基于开放接口实现批量提交任务-获取结果-报告整理工具
收益：
效率提升：人工4小时->1小时，提效75%
覆盖率提升：master分支->近两周活跃分支+master分支，扫描覆盖率100%，发现更多问题，避免遗漏。
1.漏洞修复-闭环跟踪
完成白盒和黑盒扫描之后，要将扫出的漏洞推送至研发解决，以及完成漏洞的闭环跟踪验证。
•以应用对应的代码库为维度，进行安全漏洞扫描；
•一个代码库一次扫描出一份报告，报告中展示工程代码当前存在的所有安全类问题；
•每次扫描出的结果会在行云上记录一个问题，反馈到研发接口人，由研发接口人分配到具体研发；
总结：
•基于行云缺陷录入管理，录入过程耗时耗力，未实现自动录入；
•过程不精细；
•扫描完成之后->对问题进行整理->通过OE接口人（或OE接口）进行批量下发任务；
•研发修复解决；
•每周测试接口人、研发接口人，组织会议对本周安全工单、漏洞问题进行复盘；
•周二、周四上线日的黑白合扫描的常态化执行，发送安全测试报告邮件；
•每周安全测试周报；每月安全测试月报；
•研发安全自测意识建立，行云部署编译之前，使用平台进行自测；
1.浅析漏洞
使用污点分析检测程序漏洞的工作原理如下图所示：
•基于数据流的污点分析：
在不考虑隐式信息流的情况下，可以将污点分析看做针对污点数据的数据流分析。根据污点传播规则跟踪污点信息或者标记路径上的变量污染情况，进而检查污点信息是否影响敏感操作。
•基于依赖关系的污点分析：
考虑隐式信息流，在分析过程中，根据程序中的语句或者指令之间的依赖关系，检查 Sink 点处敏感操作是否依赖于 Source 点处接收污点信息的操作。
参考资料：https://firmianay.gitbooks.io/ctf-all-in-one/content/doc/5.5_taint_analysis.html#基本原理
本文我们讲述了体验保障的安全质量提升过程。重点讲述黑盒、白盒的扫描过程。
首先对漏洞工单进行了分析，确定了漏洞的来源、种类、分布，摸清了漏洞的现阶段情况。
然后通过进行安全前置扫描，对工单中的白盒、黑盒问题前置识别。过程中通过开发工具来提升效率，最终形成一套可行的前置开展方案。
但需注意：除了解决存量漏洞问题，还需要新增类问题，需要持续不断地建设，需要实现安全测试的常态化运行。并且要利用更多自动化工具，去进行提效。