简单聊聊应用安全领域中的技术安全运营

技术安全运营是一个上限极高同时又下限极低的一个角色，做好不易。

注解：本文中“技术安全运营”的定义

安全团队中的工种基本可以分为两类，“运营岗”和“技术岗”，而“技术岗”又可以分为开发安全产品的“研发岗/算法岗”和使用这些安全产品的“(技术)运营岗“。因此，例如各类安全产品的运营人员、SDLC安全人员等均可称为”技术安全运营“。

本文中以几个实际场景中的例子来讨论不同能力的技术安全运营人员之间的差别。因视野有限，以下仅当胡言乱语，勿对号入座。

场景一：漏洞运营

SRC或黑白灰扫描器等发现漏洞后：

“初级的”技术安全运营

简单验证/不验证后点击确认漏洞下发到研发进行修复，同时针对研发的修复疑问进行答疑(一般在此处多是针对漏洞本身进行修复，而不是考虑是否是最优解)，在修复完成后验证/不验证后关闭工单，某漏洞的运营到这里就结束了。

“中级的”技术安全运营

简单验证漏洞后给到研发进行修复，同时主动找到开发确定产生漏洞的根本原因，是系统架构层面原因还是安全意识原因，修复方案是否可以实现“默认安全”，该系统中是否还存在类似问题，在漏洞止血/修复后，进行漏洞复盘，寻找根因，优化研发流程/SDLC流程来避免该风险。

“高级的”技术安全运营

在“中级”之上，不定期归结历史漏洞产生原因，抽象当前应用层面临的核心风险TOP，然后针对不同的TOP风险，统筹资源，进行全域治理，优先从架构层、框架层进行风险解决，而不是将所有疑似风险下发让研发自查(如果所有的问题都用这种方式解决，那未必也太无能了)，避免沦为成为“工单下发工程师”、“首席客服官”。

场景二：RASP/WAF等等安全产品运营(非安全产品角色，而是产品使用方)

安全产品的使用可以简单分为“部署”、“响应”两部分

“初级的”技术安全运营

“部署”

从安全产品研发侧拿到部署文档和模棱两可的稳定性影响，然后进行通过邮件/群组通知到研发，进行部署，当研发产生疑问/部署失败时，拉相关安全产品研发进行答疑，而自己全程都是一个“proxy”。

“响应”

当事件发生告警时，拉群应急，完成止血，影响不大则应急结束，影响较大往往被动复盘，效果不佳。

“中级的”技术安全运营

“部署”

在部署前，建立标准的部署流程，验证稳定性和防护效果，与安全产品团队制定稳定性标准和规则下发标准，同时建立完善的稳定性问题解决SOP和部署答疑指南。

在部署时，与架构师团队协作，分优先级、分批次进行灰度部署，以稳定性为核心。

在部署后，监测覆盖率变化，进行动态全覆盖。

“响应”

事件发生告警时，止血遏制，然后进行详细复盘，确定正式修复方案和排期、安全产品告警是否准确和及时、全域同类风险解决方案等。

同时安全产品不可避免的会产生大量误报，通过对告警风险进行分析(更进一步进行自动化告警优化)，同时与安全产品团队进行规则优化，降低误报率。

“高级的”技术安全运营

让自己成为安全产品的半个PD，将自己安全经验融入到产品的设计中去，帮助安全产品进行架构优化。（这部分笔者并无多少经验，是未来要进行深入的方向之一）

透过这两个简单例子，便是我对“技术安全运营”这个角色的简单理解。

做与做好之间的差距是巨大的，衡量的核心是是否对自己的能力有成长。

在最近的新人周会上，我送给他们同时也送给我自己一句话

以及对团队氛围的理解（来自一位大佬的解惑

原文始发于微信公众号（电驭叛客）：简单聊聊应用安全领域中的“技术安全运营”