在开篇《安全事件运营SOP【1】安全事件概述》中，介绍了安全事件的定义、分级、处置原则及处置流程。当发生某类安全事件时，该如何快速处置？以及如何保证不同人员处置的效果都达标？安全事件的种类虽然繁多，但是处理起来并非无据可循。为了解决上述两个问题，同时提升工作效率和降低安全风险。经过大量的运营处置实践，总结出以下常见的处置标准操作程序（SOP）。

本文将从基础概念、运营处置、内部响应实现和事件处置策略四个维度，对接收漏洞事件运营SOP进行阐述。由于作者所处平台及个人视野有限，总结出的SOP虽然经过大量重复的操作、总结及提炼，但仍会存在错误或不足，请读者同行们不吝赐教，这也是分享该系列实践的初衷。

01

—

基础概念

在企业网络安全运营中，有一类事情可能不太被重视，但却常会遇到，如果处置不当可能会给公司带来比较大的麻烦 - - 接收漏洞事件。之所以称之为安全事件，是因为存在不可控因素，处置时需要考虑的范围已经超过漏洞原理本身，被人利用可能给社会或公司带来负面的影响。

漏洞接收事件的渠道可以分为内部和外部两类，可能会有疑问：内部渠道为什么会算进来，以及内部渠道是指SDLC中发现的漏洞吗？从安全事件的定义来看，内部发现的漏洞也有可能导致负面影响，不过概率会比外部的低。内部的漏洞事件是指：非安全部门直接发现的漏洞。比如安全部门发起的SRC奖金悬赏活动收到的漏洞、安全公司有非常多懂攻防的员工、开发也可能对安全比较感兴趣从而提交漏洞…这并非他们的本职工作，所以也可以算作内部的“外部人员”，漏洞在他们手里就有可能导致事件。

内部渠道相对可控，外部就比较被动了。不仅不能清楚何时会以何种方式被通知有漏洞，还可能会被各种要求，比如有反馈要求、时限要求、处置动作说明、责令整改等。在外部的漏洞接收渠道中，包括国家级的漏洞库或平台、行业监管单位下发漏洞、民间漏洞收集相关平台，前两者会得到明确的漏洞通知，最后一种却比较艰难，因为民间平台不会通知企业、可能得通过白帽关系等才能弄清楚漏洞。以下为漏洞接收事件的常见渠道：

02

—

安全运营SOP

面对“在野”的漏洞细节，无论是何种渠道的漏洞事件，都需要快速响应与处置，通常可以参照以下流程：

在对应的环境进行漏洞信息验证，测试漏洞是否真实存在、以及判断被利用带来的影响。针对监管单位下发的漏洞，即使不存在也会被要求按照既定格式、时间进行正式回复。

除了漏洞的利用难度、被利用带来的直接影响，还应该从外部舆论、产品在客户侧的覆盖面等方面，全面对漏洞事件进行评估，从而采取不同的应对措施。

安全人员组织对应的产品线进行漏洞修复，在修复之后进行验证，验证漏洞是否被彻底修复、漏洞修复方法是否可能被bypass、漏洞修复是否带来新的安全问题。在确认无误的情况下，将验证结果告知产线，产线输出修复方案和经过验证的补丁。

漏洞修复后，对各来源渠道需要有明确、及时的答复，如在SRC上确认漏洞并定级给奖金、回复修复计划给监管单位/国家级漏洞库、记录并给与内部提交人一定奖励、对反馈漏洞的客户进行修复与致谢。

针对漏洞接收、处置、修复、验证、回复等整个环节进行总结，反向来优化现有标准与现有流程；对漏洞产生的原因进行分析，反向加强安全测试和内部安全管控。

2.1 – 2.5描述的内容，如下图所示：

注：图中的监管单位，默认包括国家级漏洞库、平台和相关行业的监管单位。对于民间的漏洞库或平台，由于没有固定的方式暂不纳入SOP。

03

—

内部响应实现

漏洞事件的处置其实是一件比较复杂的工作，仅凭安全部门是做不好的。比如漏洞事件需要与GA对接，事件在外部已经产生舆论，事件涉及到侵权，事件处置措施出现分歧无人拍板…

不少公司已经建立了SRC/安全运营团队，对于安全技术运营方面没问题，但当遇到“漏洞”升级为“事件”时，则需要将团队扩大化。比如在成立公司级PSIRT（Product Security Incident Response Team，产品安全应急响应小组-更适合于非SaaS化的产品及服务），由研发、安全、技术服务、客户经理、法务、公关等各岗位专家组成，覆盖供应链、研发、工程交付及技术服务等各环节。

同时设置领导小组和工作小组，领导小组负责产品安全事件的议事与决策，工作小组依据领导小组决策及职责分工进行工作落地。

在2.2中，简要介绍了影响定级的要素，但对于每个因素的占比、事件的分级未提及。此处将针对这部分内容进一步说明：

在日常运营中，按照以上规则，对每个接收漏洞事件进行评分，就可以得到事件等级。附：某次接收漏洞事件的定级示例

04

—

处置漏洞事件策略

被动就是处理起来比较难受，与其被动的等待不如主动接收。当安全建设到一定程度（如主要安全基础设施已建设，进入运营阶段），可以从以下方面着手：

在处置外部接收的漏洞事件时，经常会碰到一些特殊的场景：

曾尝试过与漏洞库沟通，此类漏洞是否出具证明就直接在系统上关闭？但得到了否定的答案，须按照时限和格式进行邮件反馈。自此以后，内部建立SOP和SLA标准化处置每一次漏洞事件。

除了上面撞洞的情况，还经常会有另一种情况：SRC前不久刚收到漏洞，怎么没过多长时间漏洞库就来通报了？仔细查看内容，所有的描述甚至连截图、涉及到的IP都一样。这很难不让人联想到一洞多投，价值最大化。

虽然SRC声明：要求白帽子对提交的信息进行保密、禁止传播，但还是很难去约束。我们曾经也是一名白帽子，很理解白帽子挖洞付出的辛劳，故在漏洞审核时间响应速度、漏洞现金奖励、季度奖励、年度奖励方面投入很多。但换来的却还是多平台刷洞，这难免有点让人心寒。不过好在绝大多数白帽子能坚守住，高质量的漏洞也基本没出现过此类情况。在此，还是想趁机呼吁所有的白帽师傅：遵守SRC或平台的规则，做个正直诚信的人。