安全应急响应中心 Security Response Center（src）简介

【背景】

大型企业的业务模式多，涉及的产品也多，特别是互联网业务讲究“小步快跑敏捷迭代”，往往忽视了安全检查或者来不及进行细致的安全检查，同时安全系统本身是程序也会存在各种遗漏，因为互联网业务的在线特性，使得互联网的人都能够接触到，相对于传统业务被攻击面扩大，所以更容易被善意的、恶意的或者无意的人发现漏洞——如果漏洞被利用或者在黑市交易，对企业和用户是极大危害的。

既然漏洞被外部发现不可避免，那么该如何吸引外部安全力量规范地参与进来呢？

互联网工作组的“负责任的安全漏洞披露过程”（可以参考翰海源翻译的中文版本，微软提出的类似作法叫“协作式漏洞披露”）基本是业界共识。

具体的做法大致会分为微软模式和谷歌模式。

以微软为代表的IT企业主要采用的公告致谢方式。只要漏洞发现者将漏洞先报告给微软，微软就会在每个月的补丁发布日发布安全公告致谢漏洞报告者。由于微软是世界级的企业，能够发现它的漏洞并得到致谢，这个荣誉使得全世界的漏洞报告者乐此不彼。当然，时代在进步，现在微软也有了漏洞奖励计划。

以谷歌为代表的互联网公司采用了现金奖励方式。只要漏洞发现者将漏洞报告给官方而不直接公开，将会得到一笔价值不菲的现金奖励。这种模式又有公告又有钱，大大地调动了报告者的积极性。

腾讯安全团队为这两种模式的企业都提交过漏洞，从人性的角度体验，当然是后者的效果更好。

那么，腾讯的漏洞收集准备采用哪种模式呢？当然是符合中国国情的腾讯特色的SRC啦。

【一个划时代的建议】

圈内的朋友都知道，TSRC时代之前（2012年5月以前），向我们反馈腾讯业务的漏洞，无论多严重的漏洞最终都只有赠送QQ公仔表达谢意——也有发布安全公告的时候，我查阅了历史记录，总共只有三个公告（TX07040201、TX07092701、TX09040901）。

虽然回馈与漏洞报告者的贡献完全不对等，但是当时整个行业都是这样的，而且黑客们总有一种侠义精神，发现漏洞通知厂商似乎本身就是一种侠义之举，厂商的简单感谢似乎也是合情合理的。

直到2012年3月底，安全应急团队在处理完一个外部报告的严重的安全漏洞之后，我们的CTO、大师兄tony先生给我发了一封Email：“这个漏洞很严重，公仔不足以表达我们的感谢。我有一个建议，请加我的微信聊”。

于是，在微信群里一番讨论后，我、炽天使、coolc、ls、tony共同见证了腾讯漏洞奖励计划的起源。

【磕磕碰碰中成长】

接下来行政上就是一系列的特殊审批。

同时技术上我们也着手建设。没有开发、没有产品、没有设计、没有运营，这些职位我们都自己顶着（什么都懂一点，生活会精彩一点），TSRC一期的系统开发及与内部安全工单系统对接工作都是harite完成的，产品、网页设计、文案话术、处理流程、微博、博客文章大部分都是我和harite做的。

下面两个图就是TSRC的漏洞报告处理流程。其中的复查程序是后面优化迭代增加的功能。

比较核心的在于TSRC漏洞报告系统打通了内部的漏洞工单系统，一经确认的漏洞就会自动同步到工单系统驱动业务修复，修复后会自动同步状态到TSRC漏洞报到系统反馈给报告者复查。

说实话当时心里没底，毕竟TSRC是业内第一家企业自建漏洞收集平台，万一平台建好了没人来报漏洞怎么办？万一同时来了无数个漏洞怎么办？万一被竞争对手坑了怎么办？万一……

一系列小步快跑敏捷开发之后，腾讯漏洞报告平台于5月20日邀请了一些白帽子内测，5月31日正式上线。

比较欣慰的是，项目一上线就取得了不错的效果，大部分白帽子们对这个企业自建漏洞报告平台的模式也比较认同。2012年6月就有38位白帽子报告了上百个漏洞，其中不乏严重漏洞。这里还是非常感谢当时支持我们的朋友，如果没有大家的支持，TSRC肯定很难走到今天。感谢！

接下来几个月，漏洞数也一路攀升，7月176个，8月280个……这还是最终确认为漏洞的数量——还有更多确认不是漏洞的报告（数倍于确认）。漏洞报告直接关联到短信、微信，每天都听到我们几个人的手机滴滴响个不停。人力严重不足，顶着，每天除了其他工作，我们几个都要处理好些漏洞。更可怕的是每个月寄送礼物的时候，快递单都要自己手工填，每月五十个左右，手都快写废了（后来实现了一键直接连接EMS，再也不用手写快递单了）。

跟所有的产品一样，建设完成只是一个开始，关键要靠运营。TSRC建设运营的十六字箴言是：小步快跑，大胆试错，沟通为王，以德服人。

前期由于没有规则，经常出现漏洞评分的争议。改！于是我们很快发布了《腾讯外部报告漏洞处理流程》并且不断更新，现在都还在维护更新。

然后又是因为跟白帽子沟通不畅，产生摩擦。改！于是增加了评论功能。发现还是不够。再改！又增加了一键QQ联系的功能。

然后又发现有些漏洞推送到业务修复后，没有修复彻底，又会被外部发现。改！于是增加了“报告者确认修复”的流程。

……

就是在这种不断迭代的运营过程中，TSRC形成了现在的框架。

下图是统计的这几年腾讯和几个大型友商在乌云漏洞报告平台上的漏洞数量，可以看到，2012年腾讯位居“漏洞之王”，2013年已摆脱这个“桂冠”。

再来看看腾讯的外部发现漏洞数量趋势（来源主要是TSRC和乌云漏洞报告平台）。

我们可以看到，TSRC的漏洞奖励计划启动后，报告的漏洞数量突飞猛进（一度让我们震惊。SRC收集的漏洞越多，越说明企业的安全体系需要优化），2013年数量达到顶峰，但2014年终于将漏洞数量收敛——这几年团队是做了很多努力的，终于看到效果了。

2013年1月，网易也推出了漏洞报告平台。接着京东、百度、阿里等都相继推出，SRC模式基本被大型互联网企业接受并且如火如荼地开展。这一年可以称为“SRC元年”。

现在我们可以看到，随着安全行业的发展，像深信服、国家电网、中兴（中兴特别提到参考了TSRC，让我们小小骄傲一下吧）、联想这样的传统企业都开展了“漏洞奖励计划”（见附录），相信未来还有更多的企业SRC出现。

【思考：沟通为王，以人为本】

漏洞的奖励模式与过去的侠义模式最大的区别就是现在漏洞报告者是利益驱动的（这也没有错，王阳明心学早就说过“天理即人欲”），漏洞评分会直接影响收益，所以漏洞评分要特别谨慎，不然会引起争议。

早期我分析过TSRC惹出争议的所有问题，发现80%以上都是跟报告者的沟通问题。换句话也就是说只要沟通得当，这些争议是不会出现的。

厂商和漏洞报告者对同一个漏洞的评级不一致是很正常的，所以这个时候就要充分沟通。所以TSRC在漏洞处理的时候增加了评论功能，但是后来又发现通过评论沟通起来太慢仍然有问题，于是又增加了一键QQ联系的功能。对于不怎么使用即时聊天工具的报告者，那就想办法要到电话号码（邮寄礼品的时候也需要电话号码）。

如果报告者对处理流程有异议，还可以绕过当前漏洞处理人员一键QQ联系TSRC首席运营官沟通；如果仍然有异议，可以联系到首席执行官（嘿嘿，表误会，是TSRC的CEO）；仍然无法达成一致的，可以邀请双方认可的业界大牛一起来进行判断。

所以，我认为沟通是SRC运营过程的重中之重——与人的矛盾解决了，其他都好说了。

漏洞报告平台的核心是上面的漏洞报告者，没有人给你报漏洞，你的平台有什么意义呢？所以平台粘性很重要。

怎么提升平台粘性？奖励额度是一方面，另外你要让报告者乐于到你的平台来。其实就可以看作一个垂直细分领域的社区类产品，这个产品运营模式可以多摸索。

早期我们推出了虚拟的企鹅勋章用以奖励做出突出贡献的漏洞报告者，当时还夸下还说说要实体化，现在我们真的制作了实体的企鹅勋章。下图是设计稿之一。

【思考：不仅仅是漏洞收集平台】

若干企业的SRC建立后，我见到一些企业的SRC只是收集外部漏洞（更有甚者只是一个摆设），我认为这是不够的（知道我的标题为什么叫应急响应中心建设了吧）。

SRC本身就是企业的一个窗口，传递企业对安全的态度，在这个框架之下，SRC要承担更多的工作。

SRC一个很直接的功能就是内部安全系统的试金石。稍具规模重视安全的企业肯定有自己的安全团队和系统，那为何还会被外部发现漏洞？一定是相关团队和系统存在这样那样的疏漏所致。

接下来就是要分析和改进。TSRC的每个漏洞都会复盘，找出和修复相应的团队和系统的疏漏。漏洞报告者帮助腾讯发现漏洞的同时也在优化着腾讯的安全系统。

下图就是针对Web漏洞复盘后发现的腾讯漏洞扫描器系统的问题及优化方案以及历年来从TSRC漏洞中收获到的优化点数量（这个数据趋势和外部漏洞数据趋势基本吻合）。

另外就是平台上的漏洞报告者可以换一个相对第三方的视角来检验我们的安全系统。比如腾讯自研的WAF上线前就让漏洞报告者进行了专门的绕过测试，发现了一些问题，效果非常赞。这篇文章《WAF之SQL注入绕过挑战实录》就是当时WAF绕过挑战的一些总结——这样的活动即增加了用户粘性，又优化了系统。

现在安全行业开始受到重视，高级安全人才急缺，SRC是绝佳的人才招聘渠道。我们团队的部分实习生、应届毕业生和社招人员都曾是TSRC上优异的漏洞报告者，TSRC的现任负责人flyh4t也曾是TSRC的漏洞报告者。

SRC还要承担企业的安全影响力输出，TSRC也会在官网分享一些腾讯安全建设方面的经验和工具。不过目前来看做得还不够（有人在群里说腾讯安全不分享，不过欣慰的是马上有另一个非腾讯的人说腾讯是有分享的。感谢支持啊），未来肯定还会更多。后续flyh4t还计划把优质漏洞报告里的思路提炼出来发在博客里，供大家切磋，共同提高。

除了自身企业的漏洞，SRC还可以做得更多。以OpenSSL心脏出血、Bash Shell破壳漏洞为典型案例，一些基础组件的安全漏洞对互联网企业的影响很大，所以TSRC也推出了“互联网生态安全漏洞奖励计划”（The Security Hero Project），将漏洞奖励的范围扩大到基础组件，希望能对互联网安全有点帮助。

【思考：排行制 vs 兑换制】

早期的几个月，考虑到如果按漏洞个数发奖，有经费不足的风险，所以我们采用了“排行制”，即对每个月的白帽子进行积分排序，按等级赠送礼品（iPad、手机、QQ公仔等实物）。下图就是2012年10月排行制下获得礼品规则：

过了几个月，排行制的弊端就显现了：报告者无法得到喜欢的东西。这等于严重打击了漏洞报告者的积极性。那不行，得改！

于是“兑换制”诞生了。也就是通过漏洞的评分获得相应数量的金币，报告者可以使用这个金币去积分商城自由兑换物品。仍然为了防止破产，上线礼品的时候，我们通过简单的经济学手段利用金币-人民币兑换系数来控制礼品的“通货膨胀”。不过一段时间后发现经费还是足够的，同时白帽子普遍反映挖腾讯漏洞难度提高了，我们就逐步调大了这个系数。

这就等于是让市场来决定漏洞价值。如果漏洞越少越难发现，单个漏洞的奖励越贵。在内部的一次讨论会上，我们笑称等以后一个腾讯的反射型XSS漏洞都奖励500美金了，就说明腾讯安全做得不错了。也有很多朋友吐槽腾讯奖励不如谷歌、Facebook，我的答案还是市场来决定漏洞价值，现阶段还没有到一个腾讯漏洞500美金的时候。

之前我们担心直接奖励现金对行业有负面影响，不过看到其他平台也用现金，业界比较接受，后来TSRC也有了直接的现金奖励，今年还增加了金币直接兑换现金功能。

【思考：江湖险恶，小心炒作】

自从PR介入安全行业以来，普通安全问题可能会被竞争对手炒作，SRC作为直接处理安全问题的官方团队，一定要小心谨慎。

有朋友吐槽过腾讯对于安全问题的官方答复一律是“非常感谢您的报告。这个问题我们已经确认，正在与业务部门进行沟通制定解决方案。如有任何新的进展我们将会及时同步”。这个答复是我们内部讨论改进过多个版本的安全问题官方标准答复口径，不过这不是因为敷衍，而是为了避免被炒作。

早些时候，我们的工作人员在乌云漏洞报告平台答复安全漏洞的时候，由于话术过于随意，发生了被竞争对手炒作的情况。

2013年TSRC发布过一个年度报告，公布了上一年度TSRC处理的漏洞及奖励情况，然后当天晚上就出现了利用报告里的数据指责腾讯漏洞多、奖励少的软文。

TSRC邮箱曾经收到过某公司的邮件，称要来合作，TSRC答复说非常欢迎但是这事不是我们的职责所以我们转给某某部门了。结果第二天就出现了指责腾讯对于安全问题多次催促还推诿的软文。

类似的血泪教训还有几个，总之企业SRC对外的话术口径一定要谨慎，要注意避免被竞争对手利用。

【思考：云SRC】

我们可以把SRC看成一种安全能力或者产品，由一个SRC服务商来为没有资源建设SRC的企业整合资源提供SRC系统，这就是云SRC了。就跟我们普通用户自己没有资源搭建个人博客而使用新浪博客一样。

云SRC是为企业提供免费的漏洞收集服务与平台，盈利点是为平台上的企业提供安全增值服务的方式（比如漏洞修复方案咨询、安全加固甚至是安全情报，具体的增值服务方式还可以再摸索）。

我理解的云SRC是免费提供给所有有需要的厂商的漏洞信息私有的服务，所以不论是传统的第三方漏洞报告平台（乌云或者补天）还是新兴的安全众测平台（乌云众测、漏洞盒子、Sobug、威客众测）都不能算是云SRC。某些众测平台的厂商常驻模式有点那个形式。

随着信息安全得到重视，未来各种企业特别是试图进军互联网业务的传统企业肯定是需要有自己的SRC的，但是大部分企业又未必有资源自己来做，所以我认为云SRC这种服务是值得尝试的。

【思考：xSRC联盟】

xSRC是指所有的SRC，这里的“x”是通配符，代表一个或多个字符，相当于正则里面的“*”。记得前几个SRC出来的时候，就有人戏言xSRC太多，26个字母不够用了，得扩大x的位数。

所谓xSRC联盟就是企业的SRC有共同的需求而联合起来交换资源合作共赢的联盟。

这里可以合作的事情比较多：漏洞收集平台相关的统一帐号体系、漏洞评分标准、经验分享；业界安全情报共享（有点类似MAPP）；企业之间的安全问题沟通（漏洞通报/僵尸网络通报/攻击协查）；安全系统共享……

当然了，涉及到各家公司的安全团队协同了，所以以上大部分想法实施起来稍微有点困难。

【后记】

信息技术发展到物联网时代，信息安全与我们的生活息息相关，随着各企业对安全的重视增加，可能就会有SRC的需求。这是时代进化的一个趋势，那么SRC的未来该怎么走呢，本文抛砖引玉，与业界各位同仁一起探讨。

安全应急响应中心 Security Response Center（src）简介相关推荐

最全SRC集锦，并附上每家应急响应中心SRC额外奖励，有些是隐藏奖励哦(最全)
介绍本人在各大应急响应中心SRC都有高质量漏洞产出,数家SRC排名前十,单个漏洞获得奖金数万元,所以这里对每家应急响应中心SRC的额外奖励都了解的比较清楚,有些还是隐藏奖励哦:这里各位师傅可以参考看 ...
src 漏洞平台应急响应中心提交漏洞简介
目录 1 漏洞平台 2 网站情况 3 发现/提交漏洞 4 思路总结 1 漏洞平台漏洞银行 https://www.bugbank.cn/ 漏洞盒子 https://www.vulbox.com/ i ...
SRC漏洞提交平台和应急响应中心
SRC平台及应急响应中心漏洞银行 https://www.bugbank.cn/ 漏洞盒子 https://www.vulbox.com/ i春秋SRC部落 https://www.ichunqiu ...
收集SRC漏洞提交平台和应急响应中心
有些SRC平台及应急响应中心搜不到,这是我收集整理的,后续再添加. 漏洞银行 https://www.bugbank.cn/ 漏洞盒子 https://www.vulbox.com/ i春秋SRC部落 ...
《爱奇艺安全应急响应中心漏洞评分标准2021》来了！
发行版本 V3.0 本文件适用范围 1.适用于爱奇艺安全应急响应中心(https://security.iqiyi.com/)收到的所有涉及爱奇艺的产品和业务的安全漏洞: 2.爱奇艺安全应急响应中心下 ...
绿盟科技应急响应中心安全研究员邓永凯：那些年，你怎么写总会出现的漏洞...
11月18号,2017看雪安全开发者峰会在北京悠唐皇冠假日酒店举行.来自全国各地的开发人员.网络安全爱好者及相应领域顶尖专家,在2017看雪安全开发者峰会汇聚一堂,只为这场"安全与开发&qu ...
蚂蚁金服安全应急响应中心上线用户可提交漏洞
蚂蚁金服安全应急响应中心(AFSRC)已于今日上线.该平台旨在集合安全领域的专家.白帽子.社会团体及个人共同发现潜在的漏洞信息,并依此建立漏洞统计分析中心,预知并自查风险,及时修复漏洞,帮助提升自身产 ...
16.div+css实战五阿里云src响应中心底部制作
1.代码示例: <!DOCTYPE html> <html><head><meta charset="utf-8" /><ti ...
OpenShift 4 - 应急响应Demo应用（AMQ+Knative+Quay+BPM+BDM+SSO）
<OpenShift 4.x HOL教程汇总> 说明:本文已经在OpenShift 4.8环境中验证文章目录架构安装演示参考架构应急响应(Emergency Response ...

安全应急响应中心 Security Response Center（src）简介

安全应急响应中心 Security Response Center（src）简介相关推荐

最新文章

热门文章