纵观互联网上公开的文章，专门介绍甲方安全测试的少之又少。入职甲方安全已将近一年又三个月，从甲方角度来做安全测试的流程和思路、痛处与难点也越加明晰。早就想着能总结一篇见闻与大家分享，诸多原因迟迟未能动笔。忽然，今夜性情大起，遂点亮台灯、打开电脑记录下这些零散的思绪。
一提到安全测试，不得不想起渗透测试。个人认为在测试覆盖面、流程以及想要达到的目标上有所差异吧。在甲乙双方的安全（渗透）测试在工作中，所体现出来的具体形态也各不一样，主要表现在安全测试流程、测试checklist、漏洞生命周期、安全测试风险以及更多更高的要求等方面。
本文以安全建设起步不久，但是有一定基础流程运转的甲方安全团队为例。
、专属名词说明在乙方做安全，或许没有听过或听过但不够了解这些名词。
.SDLSDL（SecurityDevelopmentLifecycle），一直被安全从业者知悉。尤其是最近几年以来，越来越被甲方应用安全所看重，不少公司也都在筹划、实施或践行着这整套软件安全流程，都希望能落地生根。
安全测试作为SDL中的重要一环，实现准确、高效的自动化也是大家追求的终极目标。目前为止，估计也就大型互联网公司有所建树。至于我们，还在努力的道路上。
.安全提测如果业务方有新的应用需要发布或老应用有新增功能，则需要进行安全提测，测试通过后才能上线发布。安全提测流程便由此产生，由有需求的业务方（一般而言是开发）发起安全任务单，提交至安全部门受理。安全任务单的工作流程为：
安全任务单的主要内容为：
.3漏洞工单通俗来讲，也就是提交给漏洞整改责任人（开发或运维）的漏洞工单。其内容必不可少的应该包括：漏洞名称、漏洞等级、整改责任人、所属部门、漏洞描述、漏洞危害、修复建议、提交人。
.4漏洞整改通知单当安全测试完毕后，需要向提测的业务部门进行正式的结果反馈，这时一封囊括所有漏洞以及需要完成整改时间的邮件十分有必要。一方面是告知业务方，让领导知晓，安全测试已经完成；另一方面是督促其进行漏洞修复的重要依据。
.5测试/预发/生产环境通常情况下，乙方渗透测试工程师从外网做测试，目标均是生产环境（不排除有的厂商会不做防护的把测试环境对外网开放）。但是在甲方，首先接触的便是测试环境，基本上所有的安全测试工作均在该环境。测试环境一般都和生产环境不一样，情况比生产环境复杂而且存在的安全问题比较多；预发环境的配置完全按照生产环境，漏洞修复后的最后验证可能会发生在该环境和生产环境。
安全测试流程为了进一步说明甲乙方的安全测试工作差异，该部分将安全测试涉及到的流程进行列举。
乙方渗透测试流程
乙方工程师在获得用户渗透测试授权书后，可能将着手开始测试。
甲方安全测试流程
甲方安全团队在收到业务方安全提测后，将先与提测方进行业务相关沟通（具体环境、功能等）并评估工作量，再进行测试，测试过程中一般都会进行多次沟通，对象包括对应开发、测试、产品甚至运维。
.漏洞描述当发现漏洞进行提交时，需要尽可能详细的写出漏洞细节，比如漏洞发生的位置（是否需要登录、哪个功能下的某处），附上请求包并指明存在漏洞的参数，将会在后续的回归验证工作中，减轻负担提高工效。
.漏洞危害有图有真相，漏洞利用成功的截图应该是放在漏洞描述中。到了阐述漏洞危害，可以适当的偏向更严重后果，因为漏洞危害的定级确定漏洞修复的优先级与速度。难免会有开发过来挑战，所以要做好充分理解漏洞及利用场景、演示漏洞进行攻击的准备。
.3修复建议在甲方会发现，编写漏洞修复建议时不能仅仅是依靠百度。在充分理解业务场景的基础上，提出针对性的建议。比如一个富文本编辑框存在XSS漏洞，如果单纯的提出对输入和输出做html实体编码或转义特殊字符，显然不能让开发信服。
更重要的是，常见的web漏洞单一的让开发去各自修复，显然不是一件明智的事情。如果安全团队有能力开发或请中间件等团队开发出安全组件，在软件开发过程中或遇到漏洞时进行调用，将不会占用开发过多的时间和精力，让他们花更多的心思在开发上，才是最佳之道。对于不通用的漏洞，安全团队的技能沉淀工作需要建立起来，下次在遇到相同漏洞时做到有所积累有所参考。
3、测试checklist3.测试思路不少甲方会有自己的安全测试checklist，在测试过程中严格按照表中具体的每一项测试（独具特色的、方便以后类似项目测试）进行流程化的测试操作。
在乙方，当工程师找到拿得出手的漏洞并不想在项目上投入更多精力时；在甲方，工程师可能会说功能点还没走完，还得继续测试。这就是双方的真实写照，甲方要求的是覆盖面，而乙方更多的是看重结果。
3.不同之处在测试方面，技能点都是通用的。但着重点在不同的公司会有所不同，比如：
不起眼的漏洞被列为高危：
协议安全，“一朝被蛇咬十年怕井绳”。
对外应用系统强制使用