白帽SRC百洞事件复盘；业务漏洞应对处理策略| FB甲方群话题讨论
白帽SRC百洞事件复盘；业务漏洞应对处理策略| FB甲方群话题讨论
FreeBuf 2025-03-22 18:01
各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第251期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。
话题抢先看
1、猜测一下某企业SRC事件会被挖到这么多洞，可能的原因是什么？
2、假如有一个业务真的被白帽子这样连续挖到大量漏洞（漏洞均确认存在），该如何应对处理？
3、大家有什么SRC的搭建或运营经验吗，分享一下
话题
前段时间发生了白帽子挖到某公司一百多个漏洞，在和SRC对接时出现了矛盾事件。这件事不论是从技术上还是舆论上都存在很多讨论之处。
Q：猜测一下为什么本次事件会被挖到这么多洞，可能的原因是什么?
A1：
挖到了某个组件的漏洞吧，然后这个组件还是比较通用的。
A2：
一个通用型漏洞，可以挖出一堆事件型漏洞。
A3：
听说是XSS内部一直没修，持续绕过。
A3：
内部已知 高->中->低 规则：xss不收
A4：
好像是自己写的扫描器+接入AI，具体不清楚。
A5：
用了老版本开源系统呗，我现在装个windows2003 r2也一样一堆漏洞。
A6：
使用了大量的第三方库或开源软件，这些库未及时更新，才会有这么多XSS漏洞吧。
A7：
挖到一个通杀，然后自动化跑呗。
A8：
但是通杀这么跑感觉有点离谱，我觉得是某个功能点上所有参数都出了问题，然后多次修复又被绕过。这不就轻易翻好几倍吗？
A9：
一个公司内的应该很正常，CMS都有很多企业套。一个大企业，自己有一些轮子反复使用，降低开发成本。一旦轮子被0day……
A10：
- Xscan 接入大模型，全面扫的；
- 上报漏洞，修复不彻底，又持续绕过了；
A11：
漏洞太多，对安全部门的工作能力引起怀疑。
A12：
感觉还是前期甲方、平台、白帽子没有沟通好，能挖出100个漏洞的系统或者项目，拿到SRC就不太合适吧。
A13：
我记得SRC同一个系统的同类型漏洞，都是认前面几个，后面都是重复提交了。
A14：
感觉是找到一些通用漏洞的利用方法，然后用来刷分了，类似于之前Struts2漏洞一出来能刷一波分。
A15：
1、有很多白帽子上报的漏洞可能是正常逻辑，但白帽子认为是漏洞；
2、某个或者某几个新上线系统漏洞很多，涉及接口较多；
3、安全设备被绕过，原来被拦截的测试漏洞被发现；
4、有内鬼，内外联合A16：
其实就是刷洞，不能说没用。只是有一种为了挖漏洞而去挖漏洞的感觉，我这边是按同一漏洞源产生算一个。
A17：
那就是规则问题，比如一类漏洞只按照一个算，比如我们搞这种测试，一个系统一个接口算一个。
A18：
为什么算一个？
A19：
因为规则就是这样，产生的危害是相似的。
A20：
比如先发现一个参数有漏洞，过几个月发现其他的参数还有漏洞也是算一个么？
A21：
按同一漏洞源算，例如String参数有问题是一个，如果是num又是一个了，这样的话就不合理，但是一般都会降级给奖励的，不会卡这么死。
A22：
这个在于甲方有没有完成修复了，如果确认修复了，再挖出来，我觉得应该算，如果没修复，再挖也没意义。
A23：
甲方应该更好挖洞，买了各种乙方产品，直接进去拖源码审计。
A24：
规矩没定好，被钻了空子，不过搞渗透的本来就是要钻空子思维，所以出现这种问题也很正常，至少发现了规则漏洞，不是吗？
这种事情如果是第一次出现，还是应该好好沟通，出个折中的方法才是。A25：
大概率是AI自动挖漏洞。
发现框架通用问题，但是入口分散在各个功能。
根因是给钱的问题，不一定是钱不够。
代理SRC是站在企业角度，白帽子站在个人角度。
各执一词的话，站在各自角度都是对的；这就很难判断谁有问题。
18年的时候我提交漏洞，也遇到赛季改规则的事情。不能说有问题，反正也挺搞心态。就好比已经在考场上，但是突然考试规则变了。A26：
内部沟通过，感觉两点：
（1）审核问题
审核人员要么就是不同项目组不同审核，导致几十个漏洞平均分到每个审核头上不超过个位数，没有敏感意识，并且没有互通。如果一个审核这种漏洞超过10个还没有敏感性，说实话只可能和白帽子里应外合。
（2）奖励发放问题
我们SRC的运营、审核、奖励发放是不同的人，奖励发放最终一定需要人工审核确认的。奖励发放明显异常没发现，这种一般就是接了AI自动发放，可能高危和严重会人工审核，低危就自动发放，导致没监控到异常
另外最终只是私信（还是微信私信），直接决定了之后给的通知，没沟通没给致歉信公告，估计没和公关部沟通。A27：
所以我从来不挖SRC，每天扯皮，还没啥钱。唯一参加过的活动就是某次线下马拉松，我去打马拉松还搞了5000多，其他的就不如护网代打了。
不做防守攻击，也可以卖day，都还可以。卖day一年也能赚个 5、6w。反正我感觉怎么搞都比挖SRC来得实在多了，国内SRC完全不讲武德。
A28：
之前挖XSS，以前还能给个200，后面就是给个小礼物，钱都不给了……
A29：
别给你送进去了，之前提过一个大学生四六级的考生信息泄漏漏洞，啥也没给我。
Q：假如有一个业务真的被白帽子这样连续挖到大量漏洞（漏洞均确认存在），该如何应对处理？
A30：
这种业务，直接下架重构。
A31：
业务上怎么处理啊？需要紧急下线这种极端操作吗？
A32：
我很赞成这种，说下架的，太槽了。第一，肯定是摸底大排查，不能来了就下架，某讯这么大体量而且做发布的时候，也要考虑时机的，我不信他们内部没有相关应急法案。
A33：
肯定有的，如果是架构问题，那就要逐步重构替换。
A34：
对呀，所以肯定不能盲目下架的。万一比较赚钱的业务也是这个，直接下架？业务老大直接喷死。又不是强监管部门。
A35：
所以还是先尝试降低或减少风险，后面慢慢替换或重构。
A36：
按规则处理，不然影响企业声誉。
A37：
规则最后都有一条，最终解释权归规则制定者所有。
A38：
建立熔断机制，发现漏洞的根本目的是帮助企业更安全，而不是趁人之危。
A39：
一般是遵循同种漏洞，收前三个吧。
A40：
熔断机制不仅仅是重复提交哈。当天最多收多少漏洞，到时间关闭收，明天再放开。
A41：
下次发现的漏洞和业务挂钩评级，这么多漏洞还上线运行干嘛，等着被通报还是打穿吗？
A42：
量大了可以用AI来评估和归类，同时应该倒查SDL那些环节出了问题，至于爆发的这次最好协商解决。
A43：
从SRC的运营来讲，如果不希望收到类似相同接口不同参数，或者同一个中间件漏洞导致的问题被刷大量漏洞的情况，在规则里就要定好规则。这个是后续和白帽子交涉的依据。
A44：
1、对外的漏洞收录规则需要提前沟通好并公示在平台，例如：对于同一接口不同参数，不予重复收录，最多收几个；对于框架性的问题，也做限制。
2、对于漏洞的解释以企业业务为主，比如某一个营销类的功能对于白帽子可能觉得是存在逻辑问题的，但是可能人家产品和业务逻辑就是那么设计的，不能你白帽子觉得是就是啊。
Q：大家有什么SRC的搭建或运营经验吗，分享一下
A45：
我这边已经想要常态化红蓝了，众测对我们作用不大了。
A46：
前小小微企业表示，直接把这个事儿外包出去，省心省力。
A47：
腾讯有个开源的直接搭就行了 https://security.tencent.com/index.php/xsrc
A48：
腾讯的xSRC可以SaaS部署，运营直接对着字节、腾讯、等大平台抄规则，按照本公司的漏洞管理策略和奖励改内容。
A49：
主要要靠奖金跟活动吸引白帽子，并且尽量少掰扯漏洞，重复给出来编号，内部已知给出来证据。
A50：
不是什么公司都适合搭SRC的，这需要大把的预算，以及内部管理。大部分企业是漏洞都修不起来。
A51：
这个问题好像之前有人提过，当时说正准备搞SRC，根据前两个问题，首先完善定制规则，然后多搞活动提高奖励？起码让人知道你这有这么个SRC。然后有洞给你比给黑产收益大。
A52：
跟黑产比，这个预算可要花不少。
A53：
起码部分等级的得让他们犹豫一下吧。高价值的那多半是拼不过黑产哥。
A54：
需要和业务部门确认一下，是不是要收漏洞，业务等级是什么？收什么类型的漏洞？奖金谁来承担？一方面是奖金奖励，另一方面是荣誉奖励、排名之类的。
A55：
这个本身机制不复杂，就是运营繁琐（人工）。你既不能乱通过审核，让漏洞方被瞎通报。又不能不通过审核，打消别人积极性。审核人员自己就需要是专业人员，举个例子：
白帽子真的交假漏洞，你要看出来；交的真漏洞，责任方胡扯说是假的，你也要看出来，不能说别人说啥就是啥。
我以前遇到过一个，同一个漏洞，文字描述和截图都不变，内部SRC先交一次，然后又交了补天的。
太坑，直接发邮件给集团举报了。
本周话题总结
近期，白帽子挖掘某公司超百个漏洞并与SRC对接矛盾的事件，引发技术与舆论热议。
从漏洞挖掘角度看，原因多样：或是找到通用组件漏洞，利用自动化工具批量挖掘；或是公司使用老旧系统、未及时更新第三方库，导致漏洞频出；也可能是审核规则、奖励机制不完善，让白帽子有空可钻。
对于企业SRC运营，需完善规则并提前公示，如对同一接口不同参数、框架性问题的漏洞限制收录数量；建立熔断机制，如当天最多收录漏洞数量，到时关闭；加强审核团队专业性，避免不同项目组分散审核导致敏感性不足；奖励发放需人工严格审核，防止异常发放。
当业务被连续挖到大量漏洞时，应先摸底排查，评估风险，而非盲目下架；从SRC运营角度，要明确漏洞收录规则，以企业业务逻辑为主，避免白帽子主观判断；同时，SRC 搭建运营需考虑预算、管理等，不是所有公司都适合，可参考大平台规则并结合自身情况定制。
总之，网络安全领域，漏洞挖掘与SRC运营需平衡规则、技术与沟通，才能实现安全与发展的双赢。
近期群内答疑解惑
Q：请教个问题，GB35273中的附录有个人信息和敏感信息的判定标准，如果是针对GDPR有什么标准可以参看？
A1：
GDPR第四条。
第29条工作组在2007年6月20日公布了Opinion 4/2007 on the concept of personal date（“Opinion 4/2007”），通过解释和案例的方式给出了关于个人数据的详细解释。根据Opinion 4/2007，个人数据的定义包含了四个要件：–any information任何信息–relating to相关–an identified or identifiable已识别或可识别–natural person自然人上述四个要件中，最后一个要件自然人最容易界定，即活着的人。死人，胎儿，法人都不是这里的自然人。
Q：大家日常漏洞扫描会勾选OPENSSH吗？感觉永远修不完
A1：
OPENSSH没用的，不用扫。安服洞+垃圾洞+修不了的洞，基本都不用扫。扫出来数量只是恶心自己，然后说不定还把服务器扫出问题。
A2：
今年修了一次，恶心坏了，再也不管了。反正都是内网，关键应用修了就好。修了20台遇到了9个问题，进行不下去。
A3：
SSH有堡垒机。修堡垒机就好，每台ssh去修，坑太多了。
A4：
漏扫还是先关注重点区域的吧，其他的非重点区域能弄就弄，不好弄的搁置。
A5：
重点区域接入堡垒机和跳板机，不给扫描开放权限。把SSH端口统一换了。假设换到5222，内网给5222端口做个被扫描监控。没说不修，只不是通过打补丁修复。
A6：
SSH换个banner信息，远程扫描是不是就扫不到漏洞了？
A7：
是的。这是最早的拟态防御。
Q：内容安全的架构模式是怎么样的？以前听过字节分情报挖掘、风控啥的团队的，具体是怎么样的一个团队组成、人员规模合适组建？
A1：
内容风控、反作弊，情报挖掘、申述举报、内容审核。
内容风控，申诉举报理论上属于内容审核上游，前面是通过策略规则发现违规内容，后面的是参与审核。审核分为：机审、人审。反作弊理论上就是大家理解的哪些工作内容较多，反爬，识别人机等等，这个主要还是看平台属性。
A2：
对于甲方来说，这一块要看行业性质吧，针对品牌企业对对应的内容监控。技术要跟得上，才慢慢开始配人吧。（适用于没有网络平台的企业）。
1、内容合规岗1-2人，做制度做标准做流程落实并执行。
2、产品运维1-2人：用相关内容安全的产品并优化策略。
Q：现在业界的堡垒机可以以负载的形式部署么？比如两台设备，互为主备，里面用户信息和被纳管资源信息同步，用户登录后按照负荷平均分配到两台设备上访问被纳管资源。现在我们交流的一家是，一主一备，备机除非主机挂了，才顶上来。实在是不想招惹制造商，先来问问。
A1：
虚拟化部署的就有，也硬件盒子的没见过。
A2：
有吧，分布式部署，这个算是双机部署，热备。
A3：
之前我们用qizhi的时候两台复制粘贴，但是独立运行。
A4：
jumpserver可以。
Q：有一个问题想请教一下，我们使用Continue IDE插件开发，通过一个中间网关对接后端各大模型API, 现在问题是Continue 使用的key都是同一个，没法识别用户使用的多少token，预算没法分摊到每个人头上，有没有比较好的解决方案？
A1：
按照业务系统分别划分权限，由业务主管部门按照最小权限和必须知道确定数据权限，谁管业务、谁管业务数据、谁管数据安全。
A2：
日常数据查阅是随着系统权限进行划分，关键是数据提取、接口这些，才需要通过流程来审批，跟数据等级从系统负责人、部门负责到分管领导，外部调取一般要求正式函件
A3：
权限矩阵，针对应用来做识别，认证机制。（可以用零信任来做，开不通的应用给不同的用户，系统的权限在开通的时候写死）
A4：
做完了数据分级分类，相应级别和相应分类应该都有专人专管，那让对应的管理人员出具他负责的数据内容的要求，然后咱就只需要把这些要求收集起来出个大文档或者查阅网站就行。
A5：
给数据划分了数据类别，并且标注数据等级。给岗位分配能够查看的数据类别，如何给岗位分配等级，依据：日常使用数据的敏感度，以及职级的差异。从管理层，职能主管，普通员工，以及不同岗位职责的考虑，如市场岗 财务岗提高权限等级，产品岗研发岗降低等级。
A6：
正常而言，你确定数据分类分级的时候，其中应包含这个数据使用范围的规则吧 ，如果分类分级的时候没有范围的规则，你怎么确定哪些数据是内部公开？哪些是外部公开？哪些是机密？
A7：
按照不同岗位定义的话这件事本身不可控。
因为做这件事，有前提：
1、要搞清楚涉及数据的岗位
2、要给岗位彻底定义(包括不出现人员离职后给岗位交接的问题) 3.部门与部门之间的界限要非常清晰(两个部门同岗位，给不同的数据权限，可能不太好哦；给相同的权限，但是有不同需求，也不太好)所以一般推荐的做法是因人而异，人有啥需求，就申请啥数据。（这种成本高）
送你一本网安“”小绿书
光看不过瘾？想要加入话题深入交流？
那就来FreeBuf知识大陆电台小程序
网安人的“小绿书”
找报告、搜文档行业新闻 、经验分享、职场八卦、同行互动
AI变声和匿名功能
专为社恐人士打造
让大家以更轻松的姿态
随时随地，想聊就聊
我们已经邀请数位网安行业大牛开设电台房间
等你来「撩」
甲方群最新动态
上期话题回顾：
活动回顾：
迈向安全服务化，探索网安行业和社区发展新动能 | FCIS 2024网络安全创新大会举行
近期热点资讯
安卓设备被Root后遭遇攻击的风险激增3000倍，iPhone亦不安全
Windows文件管理器重大漏洞，无需交互，PoC已发布
研究人员利用AI越狱技术大量窃取Chrome信息
Cisco智能许可工具漏洞遭攻击者利用，内置后门账户曝光
重大漏洞警示：AMI BMC漏洞可能导致远程认证绕过
FreeBuf甲方社群每周开展不同的话题讨论，快来扫码加入我们吧！
【申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入社群】
注：目前1群、2群、3群已满，如有疑问，
也可添加Kiki群助手微信：freebuf1024，
备注：甲方会员
“FreeBuf甲方群”帮会已建立，该帮会以三大甲方社群为基础，连接1300+甲方，持续不断输出、汇总各行业知识干货，打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口，让我们一同加入，共同建设帮会内容体系，丰富学习交流地。