网站安全漏洞赏金计划的范围制定与漏洞评级标准

启动漏洞赏金计划最怕的不是没人挖洞，而是被无效报告淹没。很多企业刚上线SRC（安全响应中心）或私有赏金项目时，第一周就会收到大量“缺少HTTP安全头”、“SPF记录缺失”、“弱密码策略”这类低危甚至无意义的报告。这背后只有一个原因：范围没划清楚，评级标准没定明白。白帽子不是敌人，但人性天然会倾向于用最低成本换取最高奖金。如果你不把边界和规则说死，就别怪别人钻空子。

所以制定范围的第一步，不是写文档，而是做资产盘点。你得先搞清楚自己有哪些东西暴露在公网上，否则范围写得再漂亮也是纸上谈兵。资产盘点的颗粒度要细到子域名、API端点、后台管理入口、移动端API、第三方集成组件。很多团队只把主站域名写进范围，结果白帽子通过某个被遗忘的测试子域名打穿内网，最后扯皮说不在范围内。这种案例太多了。资产盘点完成后，按业务重要性和数据敏感度给资产打标签，核心业务系统、存放用户隐私数据的系统、涉及支付或认证的系统，这些必须划入最高优先级范围。

第一种是域名/IP白名单模式。这是最基础的，直接列出允许测试的域名、IP段、APP包名。但光列域名不够，必须注明是否包含子域名、是否包含第三方服务商托管的页面。很多电商网站的商品详情页其实是外包团队开发的，域名可能挂在主站下，但服务器不在企业手里，这种如果不排除，白帽子去测了就是违规，企业还可能被第三方追责。所以范围清单里要明确写出“包含*.example.com，但不包含vendor.example.com”这类声明。

第二种是功能模块限定模式。比如只允许测试用户注册登录流程、支付流程、个人资料修改功能，其他功能模块即使发现漏洞也不予认可。这种模式适合初期试运行，能有效控制风险面，但缺点是可能漏掉模块间组合产生的逻辑漏洞。如果采用这种模式，建议在规则里加一句：若在限定模块测试中发现了可能影响其他模块的漏洞，需立即停止并报告，由安全团队评估是否允许继续深入。

第三种是漏洞类型限定模式。直接声明本次赏金计划只接收SQL注入、远程命令执行、任意文件上传、越权访问这几类高危漏洞，XSS只收存储型，反射型和DOM型不收。这种模式的好处是过滤掉大量低质报告，坏处是可能打击白帽子的积极性。如果你选择了这种模式，一定要在文档里把每种漏洞类型的定义写清楚，最好配上示例，否则关于“什么是越权”就能吵上三天。

第四种是混合模式，也是目前主流互联网公司最常用的。核心资产全放开，非核心资产只收高危漏洞，测试环境和沙箱环境明确标注不收，第三方组件和外包项目单独列出特殊规则。混合模式的关键在于分层分级，不同资产对应不同的漏洞类型和评级标准，这个我们后面细说。

一份能用的范围文档至少包含七个部分。第一是授权声明，明确告知白帽子在遵守规则的前提下，企业不会追究法律责任，这句话必须有法务审核过的准确措辞。第二是资产清单，用表格列出域名、IP、APP、API端点，每项标注是否在范围内、是否有特殊限制。第三是禁止事项，包括但不限于禁止社会工程学攻击、禁止DDoS测试、禁止在测试中使用自动化扫描器对生产环境造成过大负载、禁止窃取或篡改真实用户数据、禁止在漏洞修复前公开披露细节。第四是测试账户提供方式，如果需要登录后的功能测试，企业应该提供专用测试账号，而不是让白帽子自己注册，因为注册行为本身可能触发风控规则。

第五是漏洞提交要求，规定报告必须包含漏洞描述、复现步骤、影响范围、利用代码或截图，缺少任何一项都可以直接驳回。第六是沟通渠道和响应时间承诺，比如工作日24小时内确认收到报告，72小时内给出初步评级。第七是法律适用和保密条款。这七部分缺一不可，我见过太多赏金计划因为缺少禁止事项条款，导致白帽子用自动化工具把服务器扫崩了，最后双方对簿公堂。

评级标准是整个赏金计划的核心，直接决定白帽子的投入意愿和企业的成本控制。目前业内没有统一标准，但有一套被广泛参考的框架：基于CVSS（通用漏洞评分系统）做本地化适配。CVSS 3.1的评分维度包括攻击向量、攻击复杂度、权限要求、用户交互、影响范围、机密性影响、完整性影响、可用性影响。但直接照搬CVSS会有问题，因为CVSS是通用标准，不关心你的业务上下文。一个CVSS 9.8的漏洞如果出现在一个只展示静态页面的边缘服务器上，实际业务影响可能还不如主站的一个越权漏洞。

所以正确的做法是：以CVSS为基础骨架，叠加业务影响权重。具体操作上，先把漏洞分为三个层级。严重漏洞定义为无需用户交互即可远程利用、能直接获取服务器权限或核心数据库访问权限、影响范围覆盖大量用户。典型代表是未授权RCE、SQL注入导致数据库拖库、任意文件上传getshell、核心业务的未授权访问。这类漏洞的赏金应该设在最高档，通常是基础赏金的5到10倍。

高危漏洞定义为需要一定条件才能利用，但利用成功后能获取敏感数据或重要功能权限。比如需要登录后的越权访问其他用户数据、存储型XSS能窃取管理员Cookie、SSRF能打穿内网关键服务、支付流程中的金额篡改。高危和严重的分界线在于利用难度和影响范围，这个分界线必须在文档里用具体案例说明，否则每次评级都会变成拉锯战。

中危漏洞包括反射型XSS、CSRF、信息泄露但非核心数据、目录遍历、不涉及核心功能的越权。低危漏洞包括缺少安全头、版本信息泄露、弱口令但账户权限极低、SPF/DMARC配置问题。这里有一个容易踩坑的点：很多企业把“缺少HttpOnly标记”这种问题定为低危甚至忽略，但如果你的业务核心依赖Cookie做认证，而且存在其他漏洞能配合利用，这个低危就可能升级。所以评级标准里要加一条：相同漏洞在不同业务场景下评级可能不同，由安全团队根据实际影响综合判定。

评级不应该由一个人拍脑袋决定，需要建立一个三人小组机制。收到报告后，第一响应人做初步分类，判断是否在范围内、是否重复、是否已有类似报告。通过初筛的报告进入技术评估环节，由两名安全工程师独立评分，取平均值。如果两人评分差距超过一个等级，提交给安全负责人仲裁。整个流程要在72小时内完成，超时会影响白帽子的信任度。

评分时对照一张评级矩阵表，这张表横轴是漏洞类型，纵轴是资产等级。资产分三级：核心资产包括用户数据库、支付系统、认证服务、主站Web应用；重要资产包括内部管理系统、邮件服务器、文件存储服务；一般资产包括静态页面、博客、测试环境。同一个SQL注入漏洞，出现在核心资产上就是严重，出现在一般资产上可能只是高危或中危。这张矩阵表要公开给白帽子看，让他们自己心里有数，减少无效提交。

还有一个必须处理好的问题是漏洞链的评级。白帽子经常会把多个小漏洞串起来形成一个完整的攻击链，比如先利用信息泄露拿到用户名，再爆破弱口令登录，最后通过越权访问管理后台。这种漏洞链怎么评？原则是按最终影响评级，而不是把每个小漏洞单独评了再加起来。漏洞链证明了攻击路径的可行性，最终能打到什么程度就评什么级。但如果漏洞链中的某个环节需要极其苛刻的条件或者纯属理论上的可能性，就要酌情降级。

赏金定价是个敏感话题，定低了没人来，定高了预算扛不住。参考国内主流SRC的水平，严重漏洞赏金通常在5000到20000元人民币区间，高危在2000到5000元，中危在500到2000元，低危在100到500元。这只是大致范围，具体金额要根据企业体量和业务价值调整。初创公司可以把赏金设低一些，但要用其他方式弥补，比如公开致谢、赠送礼品、提供面试机会。大厂如果赏金低于行业平均水平，白帽子会用脚投票。

除了单次赏金，建议设置季度或年度额外奖励。比如季度内提交有效漏洞数量最多的前三名额外奖励，或者单个漏洞影响特别大的给予特别贡献奖。这种机制能吸引高水平白帽子持续关注你的项目。另外，对首次提交有效漏洞的新人给予新人奖励，能降低参与门槛，扩大白帽子池子。

实际运营中会遇到大量边界情况，必须提前制定处理规则。第一类是多个人提交了同一个漏洞，按提交时间先后决定归属，以安全团队收到邮件或平台提交记录的时间戳为准。第二类是漏洞在修复后又重新出现，这种情况应该视为新漏洞重新计算赏金，因为这说明修复流程有问题，白帽子帮你发现了流程漏洞，理应获得奖励。

第三类是白帽子在测试过程中不小心触发了某些操作，比如修改了其他用户的昵称、发送了测试请求导致短信费用增加。只要白帽子没有恶意行为，并且在报告中如实说明了情况，企业应该免责处理，不能以此为由克扣赏金或追究责任。这条写进规则里能极大提升白帽子的安全感。第四类是企业内部员工或外包人员提交漏洞怎么处理，通常做法是内部员工不参与赏金计划，但可以走内部的安全贡献奖励通道，避免利益冲突。

第五类是最棘手的：漏洞确实存在，但修复成本极高或者业务方不愿意修。比如某个遗留系统的架构问题导致无法彻底修复越权漏洞，只能通过WAF做临时防护。这种情况下，漏洞应该按原始影响正常评级和发放赏金，因为白帽子已经完成了他的工作。至于修不修、怎么修，是企业内部的风险管理决策，不能转嫁给白帽子。

赏金计划的规则不是一成不变的，业务在变、攻击手法在变、白帽子的关注点也在变。建议每季度回顾一次规则，根据实际运营数据调整范围和评级标准。比如发现最近三个月提交的漏洞中，某个类型的漏洞占比过高但实际影响有限，可以考虑在下个版本中降级或移出范围。反之，如果某个新上线的业务模块频繁被绕过，应该提升该模块的资产等级和对应漏洞的评级。

每次规则更新要发公告，标注版本号和生效日期，旧版本规则存档备查。已经提交但尚未完成评级的漏洞，按提交时的规则版本处理，避免规则变更影响白帽子的既得利益。版本管理做得好，白帽子才会觉得你这个项目是认真在运营的，不是心血来潮搞一下就荒废了。

最后说一个容易被忽视的细节：规则文档本身要放在一个固定的、容易找到的位置，URL不要经常变。很多白帽子会把你的规则页面加入书签，定期回来看有没有更新。如果你把规则藏在某个三级页面里，或者每次更新都换URL，等于在给白帽子设置不必要的障碍。最好的做法是专门建一个security.example.com的子域名，把所有安全相关的政策、PGP公钥、赏金计划规则、漏洞提交入口都集中放在这里，简洁清晰，一目了然。