这个圈子，需要愿意较真的人

原创

kk
kk

Yfansec

2026年10月21日 14:12
河北

去阅读

这个公众号叫 yfansec，yfan，要饭的意思。挖了几年洞，我第一次走申诉，是早年因为一个并发漏洞。当时跟厂商运营来回沟通很久，我坚持认为这个问题不该被忽略；现在回想自己刚入行时，确实幼稚没理。换个角度回看，那个漏洞本身危害其实并不大。

慢慢地我也变得佛系，很少再主动争执，只有遇到明显离谱的判定才会申诉。有些项目、有些厂商，踩过一次坑之后我就不再去挖了，主动停下这种无用的争论和内耗。毕竟没有哪个 SRC 是求着白帽子来挖洞的，你不挖，有的是人挖；在 AI 提速之后，这个现象只会更明显。

前段时间冲双十一活动，提交了一个信息泄露类漏洞：涉及一批用户敏感信息，数量不小，获取门槛很低，注册一个普通账号就能拿到访问凭证。

初次定级偏低，我发起申诉，对方给出评级标准，圈出高危的判定条件——获取核心重要数据。

我对着规则继续追问：这些用户信息难道不算敏感信息？对方表示需要内部核查，不久后等级上调了一档。

我再次申诉，说明这属于用户核心数据；也提到，一个漏洞需要反复申诉才能敲定等级，其实对审核效率和研究者的耐心都是消耗。这一次对方换了理由：该系统不属于核心系统。

话讲到这，继续申诉好像已经没意义了。我反复对照公开的评级规则，依然觉得这个判定不合理。有些规则写得很抽象，不少描述模糊不清。逐条核对下来，即便认可\"系统非核心\"这个结论，规则里还有别的评估维度：数据量级、数据敏感度、利用链难度，都会影响等级。而这个漏洞获取门槛极低，数据规模和敏感程度都已经达标。

常规申诉走到头，我通过正式渠道进一步沟通，等级再次上调，但附带一条新的说明：报告撰写不够规范、逻辑不够清晰。

如果最开始就拿\"报告不规范\"说事儿，我还能接受；到反复申诉之后才抛出这个理由，就显得很牵强。

挖了五年洞，报告逻辑清不清楚，我心里是有数的。这里也算是白帽子一个很微妙的困境：AI 生成的报告写得太详细，审核方觉得冗余；自己手写精简，又容易被判定为信息不足。反馈集中在报告里部分信息只做了文字说明，缺少更详细的定位信息。

到这一步，我没有再继续申诉。就算继续举证证明报告没问题，好像也改变不了什么。

属实没想到，同一个漏洞，前后申诉几轮，定级理由一变再变：从最初判定不算敏感，到\"系统非核心\"，最后理由变成报告不规范。说实话，我挖这个漏洞花的时间精力，已经超过了所有申诉的成本。

很多时候，SRC 明明放出了公开评级规则，但落地判定的结果常常和规则对不上。白帽子不认可，只能走申诉：翻规则、补证据、一遍遍解释漏洞的实际影响，来回拉扯好几轮，等级才调整到位。问题最后虽然解决了，但我心里总觉得别扭。

既然白纸黑字写好了规则，为什么要反复申诉，才能拿到规则本该给的结果？规则摆在那里，执行的时候为什么标准飘忽不定？

平时和业内朋友聊天，其中也有做过 SRC 审核、运营的同行，经常会聊起白帽子和 SRC 的关系。外界偶尔会产生疑问：定级是不是和奖励预算挂钩。我不想做这种动机判断，也没有证据下这个结论。

不同立场的人，看待同一个漏洞本来就容易有分歧：白帽子优先关注漏洞能造成什么危害；安全审核人员聚焦风险本身；业务方更在意这套系统在业务里重不重要。立场不一样，结论不同，这件事本身可以理解。

但有一点我一直觉得值得拿出来讨论：系统本身是否核心，和漏洞有没有风险，是两件独立的事。 一套系统哪怕不属于核心业务，里面存储的数据、对外开放的接口、权限逻辑出了问题，一样会产生真实的安全影响。如果仅仅因为系统不重要，就直接压低评级，这个判断依据，到底是漏洞风险本身，还是别的因素？

我不想贸然断定每次评级争议背后的内情，也不会简单把所有分歧归为厂商刻意压级。可规则既然对外公开，就该尽量按规则落地执行。不然规则写得再漂亮，也只是一纸摆设。最消耗人的，就是无休止的申诉拉锯。

试想，如果我嫌麻烦、放弃申诉，最初那个不合理的定级，是不是就直接敲定了？

当然，白帽子的判断也未必永远正确，厂商有自己的审核标尺，出现分歧本来正常。只是在我看来，申诉应该用来纠正审核错误，而不是白帽子拿到合理评级的必经流程。

我们花大量时间踩点、梳理业务、复现验证漏洞，已经投入不少成本。提交报告之后，还要额外花精力研读评级文档、整理佐证材料、反复解释漏洞影响。说实在的，很累。我们是来挖漏洞的，不是专职研究怎么写申诉话术的。

还有一个圈内很矛盾的现象：很多争议漏洞，正常申诉渠道走不通，一旦写成文章公开发出来，事情反而能推进，等级上调、奖励补发；等风波平息，文章删掉，这件事仿佛就此翻篇。

我不想去定性这里面有多少是恶意压级，多少只是正常的审核偏差。白帽子会判断失误，厂商审核同样有疏漏。只是我一直想不通：为什么一部分争议，正常沟通解决不了，公开之后就能快速处理？如果最初判定本身有问题，为什么申诉阶段无法修正？如果原始判定没问题，公开之后调整结果的逻辑又是什么？

AI 普及之后，整个 SRC 生态确实变了很多。挖掘门槛被拉低，报告提交量暴涨，里面混进了大量没经过人工复现、纯 AI 生成的无效报告；也有刚入行的新手跟着工具跑，连漏洞是不是真存在都没验证清楚就提交，判得不合意就无脑申诉、反复纠缠。审核团队面对的噪音陡增，这是客观事实，我完全理解。

所以这几个月各个src平台也在收紧：纯 AI 生成、未人工复现、拿不出验证材料的报告直接驳回，累计提交多个无效报告的直接拉黑，造假的追回奖励、永久封禁；奖励资源也在往严重、高质量漏洞上倾斜。像腾讯九月份刚生效的严重漏洞额外奖励升级，额外奖励提到两万到十万，季度评选只看利用手法新颖性和真实业务影响，就是这个方向。这些针对\"刷量\"的整顿，我觉得该做，也支持做。

平台整顿的是无脑刷量、虚假报告，这和认真挖洞的人拿着真实漏洞走正常申诉，根本不是一回事。审核压力大，不该让后者去承担额外的沟通成本。

报告质量不达标，可以优化前置指引、细化审核反馈；漏洞风险存在争议，可以把每一条扣分、降级的依据清晰写出来。不能因为报告变多、审核工作量上涨，就让真实有效的漏洞很难拿到匹配风险的评级。

白帽子靠技术和时间挖出漏洞，希望拿到匹配风险的奖励，这本来就是 SRC 这套机制设计的初衷；厂商想把控审核效率、控制预算，诉求同样无可厚非。

说到底，双方只是基于各自的逻辑做事，不该让所有额外的沟通、举证、拉扯成本，全部压在白帽子这一侧。

我始终认为，白帽子和厂商从来不是对立关系。白帽子发现隐患，厂商修复漏洞，双方依托公开规则合作，这件事原本可以很简单。

一旦规则模糊、定级依据不透明、申诉反馈含糊，每一次争议都在消耗双方的信任。时间久了，白帽子会怀疑规则到底有没有用；厂商也会觉得白帽子越来越难沟通。两边都觉得委屈，根源的标准问题却没解决。

我并不打算把所有问题归责厂商，也给不出一套完美的解决方案。我只希望，公开的规则能尽量保证执行上的一致性。存在分歧可以协商，审核出错也允许更正。

我也不是要求所有漏洞都顺着白帽子的预期定级，不是所有申诉都该通过。

我只是觉得：一个漏洞该给什么评级，可以有理有据地讨论，但反复申诉、甚至被迫公开发声，不该成为争取公平结果的常态。

对我这样的白帽子来说，看重的从来不止奖金，更在意规则是否公平、沟通是否顺畅，自己投入的时间和技术能不能得到基本尊重。当然，圈内也有不少 SRC 做得不错，定级打分有理有据，审核专业、反馈高效。想减少争议，其实有些事情并不复杂：比如重复漏洞编号、内部已知工单这类不涉及敏感内容的信息，能同步给到白帽子，就能避免很多无谓拉扯。我自己就遇到过重复提交自己曾经上报过漏洞的情况。

这个圈子，从来都需要愿意较真、认真做事的人。我没有宏大的理想，不谈守护数据安全、抵御境外威胁。上面讲的平台之前挖的洞提现还没到账，至于文章发出去会不会封号已经无所谓了，本来也不打算继续挖了，发出来也不求于提高赏金什么的。我只是希望自己付出的劳动能被看见、被尊重，所求不过公平二字。