以下审核策略仅适用于58集团相关产品和对内对外业务系统、可威胁到58集团产品和业务相关的情报。
针对于第三方组件或产品通用漏洞：
如果提交相关基础组件且对集团业务产生实际影响的Nday漏洞，提交的漏洞已公开且时间超过半年，若集团内部已知晓该漏洞则忽略，如果平台不知晓该漏洞且未修复漏洞，则按照漏洞实际影响进行评分
如果提交相关基础组件的0day漏洞，且给出了可利用证明，平台将按照实际报告证明细节按照漏洞情报进行收录，平台建议您向软件官方以及国家相关漏洞平台报告
若同一组件导致的多个业务问题，平台确认第一个提交报告者，比如同一个二方或三方SDK导致的多个APP漏洞
第三方组件或产品漏洞只给第一个提交者计算贡献，不同版本的同一处漏洞视为相同漏洞。
正常建议每份报告提交单个漏洞，如果为漏洞组合利用则需要打包提交。其余情况，相同报告中存在多个漏洞时按照评分奖励最高的漏洞进行处理
关于密码泄露平台原则上只收录业务后台系统，测试系统，必须提供密码来源方式，同一系统的多个密码泄露问题算作同一漏洞。如提交大量用户密码泄露，根据实际报告以及影响情况按照情报评判
由某个漏洞产生的多个影响，按原漏洞评定权值，影响程度视具体危害评定。如：核心业务后台密码泄露导致大量用户简历信息泄露，后台查看用户简历为正常功能，漏洞权重会定为后台密码泄露（6）而非敏感信息泄露（8），但实际的影响为严重影响（18），评分约为230（严重）。
如未单独声明，对于同一系统如果短时间内被提交多个同类型漏洞，例如：刚上线的业务多处类似接口存在SQL注入，则按照漏洞类型分别对最先提交的2个漏洞正常收录和评分，随后对该系统业务所有该类型进行排查，规定最大期限为一个月，从漏洞确认开始算起直至修复完成，期间漏洞状态为修复中，此时同类型漏洞被提交按忽略处理，完成修复后漏洞状态变为修复完成，若依旧存在该类型漏洞，则可继续正常提交给分，此类型不属于同源。
为避免争议，建议白帽子在不违反公告规定的情况下尽量证明漏洞危害。如有涉及到违反规定的危险操作（如：命令执行），我们会主动协助白帽子完成验证（即使白帽子在报告中未明确提出），最终我们会根据实际危害上调影响范围权重；如有遗漏，白帽子也可在评论区进行补充。
漏洞报告中未提供成功案例，只是说明理论可行的，漏洞无效；仅提供漏洞利用结果，未提供漏洞POC的，漏洞无效
如出现多个白帽子提交相同漏洞的情况，平台将给提交时间最早且报告内容真是有效的漏洞提交者奖励，其余将按照漏洞重复忽略处理
白帽子如果主动要求忽略漏洞重新提交，可能在下次提交前会有其他人提交该漏洞，需要自行承担重复风险。
如果您或其他白帽子通过新的报告提交了某个已修复漏洞的绕过方式，该报告会被定为同源漏洞，无实际漏洞等级，会按照原漏洞奖励的75%给分。
同一个漏洞源产生的多个漏洞或修复一个漏洞其他也都会被自动修复时，只收录第一个漏洞，包括但不限于同一个 JS 引起 的多个安全漏洞、同一个发布系统引起的多个页面的安全漏洞、框架导致的整站的安全漏洞、泛域名解析产生的多个安全漏洞等。
因任何原因忽略的报告统一显示为误报。
无论漏洞报告是同源还是忽略，审核人员都会在漏洞评论处给出token，方便对相似漏洞进行溯源、归类。
人为自行制造安全威胁或安全事件情报的不计分，涉及到58集团的所有漏洞和情报在58集团主动公开前公开给除58集团授权的任何人，均不计分，同时58集团将保留采取进一步法律行动的权利
同一漏洞或情报首位报告者计算奖励，其他报告者不计，由于情报的时效性，报告已知或已失效的情报不计分。
如未特殊声明，已公开的漏洞或情报不记贡献，存在刷洞嫌疑的不进行奖励。