聊聊白帽子与审核的对立面

白帽子与审核是安全圈矛盾最多的群体，俗话说，屁股决定脑袋，因为白帽子和漏洞审核人员所处的位置不同，从而导致针对漏洞危害的评估无法达成一致，从而造成大量矛盾。

我之前从事过几年甲方安全工作，也做过短期的漏洞审核工作，最近两年成为了一名白帽子，也经历过一些让自己很不爽的事儿，当然，我也理解，所以没有过多与审核进行 battle，今天就站在不同的角度聊聊对漏洞的理解。

审核的角度

审核人员通常是企业安全团队的成员，工作内容属于 SDL 范畴，审核漏洞是其中的一部分，更多的工作是推动内部的漏洞整改，以及基于漏洞情报，举一反三，发现更多安全风险，从而提升企业应用系统的安全性。

白帽子提交的漏洞属于漏洞发现中的一部分，每天上班的第一件事儿，就是打开漏洞平台，看看那些漏洞没有审核，然后联系业务方，对漏洞的危害进行评估，然后根据业务方的反馈，来对漏洞评分。

所以审核并非只看漏洞的危害有多大，还要参考业务方的意见，以及当前系统的重要程度，大多数的 SRC 都有评分准则，将应用系统进行分类分级，然后不同级别的应用系统有不同的系数，最终的评分就是：

漏洞危害系数 * 系统重要程度系数 * 基础平台

审核也是根据评分准则，按部就班的对漏洞进行评分评级，这就是日常工作的一部分，根本不会考虑太多潜在危害。

在审核眼里，给你多少分对自己的绩效没有任何影响，心情好，多给点，心情不好，少给点，这都很正常，这跟哪个公司没有关系，跟审核个人关系比较大，毕竟公司很少有对漏洞评分复核的流程，审核也不会因为分给少了而扣工资。

白帽子的角度

对于白帽子而言，本身就是弱势群体，挖漏洞需要花费大量的时间和精力，投入产出是相当不平衡的，所以很多白帽子在业余时间挖洞，还是得依靠工作来生存，当然，也有那么屈指可数的大佬，靠挖洞生存。

白帽子并不会知道目前挖到的漏洞资产在公司内部属于什么样的重要程度，也不知道是不是测试系统，唯一能确定的就是漏洞危害程度，通过这个漏洞能造成多大的危害，白帽子考虑的更多是拿到系统权限，那么危害肯定是最大的，至于这个系统是不是内部重要系统的，不关心，也不知道。

当白帽子发现一个 RCE 之后，心里非常开心，眼看就要来大钱了，毕竟能拿到系统权限，也算漏洞危害中最高的存在了，提交之后，经过审核的多方计算，发现系统并非重要系统，而是什么测试系统，马上要下线处置的，这么一来，对公司并没有太大危害，所以给个十几二十分，安慰安慰吧。

这个时候，矛盾就来了，白帽子对于漏洞的期待是非常高的，毕竟也是花了大量时间去找的，而且危害又这么高，怎么给了这么点分，太可恶了，然后白帽子与审核之间开启了一轮又一轮的 battle。

我的一些经历

这两年我也陆续交过一些 SRC 的漏洞，也来回忆一下这些不好的回忆：

1、在备份扫描的时候，发现某个 SRC 的一个备份文件，配置文件中包含了内部数据库的账号密码，危害很有限，但是也不能说完全没有，所以提交试试吧，经过了漫长的一个月时间，终于审核完了，打开一看，忽略，理由是漏洞不存在，当我再次访问的时候，确实 404 了，这种白嫖手段，确实厉害。

2、在 nday 漏洞扫描的时候，发现某个 SRC 的一个任意文件上传漏洞，可以上传 jsp 脚本 getshell，心想来大单了，提交之后，每天上了看看有没有审核，想着怎么也有几千块吧，终于有一天审核通过，给了 3 分，大概 30 块，审核理由是内部已知，边缘资产，然后给了 3 分安慰一下。

3、其他的印象不深了。

如何解决这个矛盾

主要矛盾是对于漏洞审核标准的认识和理解不同，如果之前做过白帽子同学去做审核，在漏洞审核时候，对于白帽子提交的漏洞会更加慎重，更加尊重白帽子的劳动成果，尽量争取奖励。

做过审核的白帽子，在漏洞评级完之后，也比较容易接受这个结果，毕竟自己做审核的时候，也是这么做的，内部已知，危害有限，边缘系统，这都是在审核标准中明确的。

所以两个角色如果能够换位思考，也许能做到相互理解，白帽子提交漏洞是为了获得一些赏金，属于先做贡献，然后获得酬劳，但是这个酬劳不是白帽子来定价，是服务方定价，为了减少支出，当然价格越低越好，这是毋庸置疑的。

所以白帽子是弱势群体，但是审核同学，也许会有一天，你也会给其他平台提交漏洞，如果获得同等的待遇，你是否可以接受，将心比心，能给白帽子多争取些福利就多争取一些，同是一个行业的，就不要互相压榨了。

关于白帽子和审核的对立问题，你怎么看？作为白帽子遇到过哪些让你不爽的审核，作为审核遇到过哪些胡搅蛮缠的白帽子？欢迎留言。

原文始发于微信公众号（信安之路）：聊聊白帽子与审核的对立面