职业生涯
2022-2023 字节跳动
应用安全
经过前五年的应用安全建设实践,想要在更庞大的业务去验证“我的应用安全观”思路的通用性,在TikTok的应用安全建设中,通过风险摸排、漏洞复盘、“SDLC工作台”的综合思路,提效、跟踪、闭环,有效实现外部漏洞数量的大幅收敛以及完整SDLC体系的构建。
2017-2022 阿里巴巴
应用安全/数据安全
从零开始,全程参与菜鸟BU技术安全体系的构建,带领团队不断建设和深耕应用安全领域,致力于线上数据批量泄漏的治理和基础安全建设,推动并实现DevSecOps在菜鸟的落地。
应用安全观
必经之路
第一阶段:从0到1,表面上补齐了各类安全能力,但是风险仍遍地开花
SDLC的流程所有人都背的滚瓜烂熟,在进行一个新业务的SDLC建设时,第一步要做的几乎都是通过各种方式,将拼图补齐,至少看起来是五脏俱全,但是这些拼图是否在起作用就未知可否了。判断当前业务是否处于这个阶段有个很简单的办法,就是分析下历史漏洞,是否各个类型的漏洞都在占有一定的比例,外部上报漏洞数量忽高忽低并且处于一个相对较高的位置。啥啥都有,啥啥都不行。
第二阶段:自动化能力得到提升,风险集中到某几类特定类型
一直持续的投入人力进行漏洞挖掘是ROI相对较低,所以在第一阶段的风险适当收敛后,自然而然的会将重心转移到工具自动化发现漏洞上,但是工具也不是万能的,风险最终会被收敛到越权、数据泄漏或业务特色风险等几类中,这时往往需要通过一些风险治理专项进行攻坚克难。
第三阶段:核心风险基本得到解决,SDLC左移,重心转移到上线前,安全水位可度量
无数个应急的夜晚之后,救火队员角色的比重可以降低一点,这个阶段我们的重心更多的是防患于未然——“治未病”;这时候也会遇到个严峻的问题,左移的时候如何让RD看到并看清楚,这时候就需要科学的度量衡,设计良好“安全分”在这时会起到很大的作用。
第四阶段:经过持续的SDLC深耕,实现理想的DevSecOps,产品、开发、测试、安全所有人都在为安全负责
经过持续的左移、深耕,理想情况下我们会再次经历一次角色的转变,“安全工程师提供安全能力支持,业务为产品自身的安全负责”,安全大同。
浅谈“技术安全运营”
末等:漏洞修复只要无法复现便结束工单,全程几乎与RD无沟通;
下乘:结合历史漏洞与RD探讨漏洞产生根因,并能根据业务现状因地制宜给出修复方案,并且能在关键时候对稳定性与安全性的取舍做出决断;
中庸:总结发现漏洞或风险的共性,通过深入业务,能在架构层给出“默认安全”的解决方案,并能推动落地,需要有一定的知识广度、架构能力、项目管理能力;
上乘:提出并推动更普世的安全解决方案,适用于全部业务或成为行业解决方案,例如“可信安全架构”
“漏洞”是SDLC的发动机
漏洞运营的核心是“复盘”
不只是关心“为什么没发现”,更关心“为什么会出现”
不仅要知道“为什么会出现”,更要知道复盘后的效果“发现了多少”
如何找到我
有一个小小的公众号,偶尔会发一些平常的所思所想,当然也可以直接留言