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