我的私信里出现频率最高的问题，基本是这几类：新手想进网络安全行业，不知道从哪下手；会一点基础技术，但不知道“漏洞提交平台”到底怎么玩；还有人注册了好几个平台，提交了几份报告都石沉大海，慢慢就放弃了。这篇文章我想把这件事从头到尾讲透：先搞清楚SRC是什么、为什么这几年大家都开始关注它，再把这几年我整理过的25个漏洞提交平台按类别盘一遍，然后讲透平台规则、新手实操路径、常见坑和长期成长方法。无论你是零基础，还是已经提交过几份报告但没过审的人，这一篇都能帮你在脑子里建立一张完整的地图。先说一句最重要的：所有正规漏洞提交平台都是“邀请制”的安全测试，你只能测平台明确授权的资产，测试数据也要在授权范围内使用。这不是口号，是红线。越过这条线，轻则封号，重则可能会被追究法律责任。后面我会反复强调这一点。1. 为什么这几年“漏洞提交平台”越来越值得关注1.1 SRC是怎么运作的SRC是Security Response Center的缩写，中文叫安全应急响应中心。它是企业对外开设的一个正式窗口，用来接收外部安全研究者提交的漏洞报告。企业在这套机制里公开自家业务范围内允许测试的域名、App、小程序等资产，说明清楚哪些能测、哪些不能测，然后等安全研究者来测试，提交漏洞后企业会定级、审核、修复，并给提交者发奖金、积分或荣誉。我以前跟朋友打过一个比方：没有SRC的时候，发现漏洞的人像一个闯空门的，哪怕是好心提醒主人锁坏了，也有说不清的麻烦；有了SRC，你变成了主人请来的安保巡检员，拿着地图在允许的区域内检查门锁。同样是干一件事，身份和边界完全不同。这也是SRC近些年越来越受关注的核心原因。对于企业来说，与其等漏洞被恶意利用或被拐弯抹角地卖到黑市，不如主动开门，花可控的成本把风险暴露在阳光下。对于安全研究者来说，SRC提供了一条合法、可持续、有回报的通道。1.2 白帽、平台、企业三方共赢很多新人容易把漏洞提交平台想象成“奖金池”，好像只要提交就一定有赏金。实际上的逻辑不是这样的，它更像是一个三方协作的机制。企业在里面获得的是安全加固——漏洞被发现、被修复，损失被避免；漏洞平台获得的是生态和声誉，提交者和企业都在它的体系里沉淀；而以白帽身份参与的个人，获得的除了现金和积分，更重要的是实战场景、丰富的验证案例和在行业里的可信记录。这份“可信记录”越往后你越会发现它值钱。很多做安全的人并不是靠某个漏洞报告里的那几百块奖金发家的，而是靠持续提交高质量报告，让企业方从看到名字就信任，到慢慢建立长期合作。这个积累本身，就是你在行业里的资产。1.3 什么样的人适合进场说实话，谁都可以进场，但能稳住的人通常有几种基础。最基础的是对HTTP协议有直观理解，知道请求和响应是怎么回事；其次是喜欢琢磨“业务逻辑”，不只是背漏洞类型；再就是有耐心去读平台的规则和报告模板，不急着上手就扫。如果你还在上学，或者正在做运维、后端研发、测试相关工作，又或者你对网络安全的攻防原理感兴趣但一直缺一个合法练手的地方，那么SRC非常合适。它不像CTF比赛那么偏解题，也不像护网行动门槛那么高，它是一个可以直接把能力和真实业务结合起来练的场所。2. 25个漏洞提交平台分类盘点：选平台就是在选资产很多新手第一个问题就是“我该去哪个平台”。我的建议一直是：不要漫无目的地注册，你先要想清楚自己想测什么类型的资产。平台只是入口，资产才是你真正面对的对象。下面我把这25个平台拆成三类来看，每一类适合的人群和玩法都不同。2.1 国家级/行业级漏洞库：做的是社会层面的贡献这一组的共同点是：它们不完全按企业SRC那种“测某个App某个域名”的方式运作，更多是接收通用软件漏洞、系统漏洞，库里的数据会上报给国家相关机构做预警和通报。提交这类漏洞往往没有企业SRC那么高的现金回报，但它对行业的意义更大，有些漏洞还能拿到原创漏洞证明之类的认可。平台名称定位适合人群说明CNVD（国家信息安全漏洞共享平台）国内通用漏洞收集与通报偏二进制、通用软件研究的人对通用软件漏洞、开源组件漏洞比较友好CNNVD（国家信息安全漏洞库）漏洞信息汇总与查询所有人主要偏向漏洞披露后的收录与查询CNCERT（国家互联网应急中心）网络安全事件监测与协调关注事件型漏洞的人更多是应急协调视角，和主动挖SRC略有不同这个类别里，我最建议关注的是CNVD。如果你在某套开源系统、某个开源组件里发现一个前人没提交过的高质量漏洞，走这里的价值比丢给某个企业SRC更合适，因为它影响的不只是一家企业，而是整个在用这套组件的行业。2.2 头部互联网企业SRC：新人入门的核心训练场下面这些平台是互联网行业里相对活跃、规则相对成熟、资产规模也比较大的企业SRC。它们的共同特点是：资产种类全，有网站、App、小程序、业务接口，定级标准相对透明，奖励机制也比较完善。平台名称开放资产适合人群观察点腾讯安全应急响应中心（TSRC）腾讯系产品综合型选手资产多、报告要求规范阿里巴巴安全应急响应中心（ASRC）阿里系产品综合型选手对电商、云场景理解要求高字节跳动安全中心字节系产品综合型选手成长快，业务复杂百度安全应急响应中心（BSRC）百度系产品搜索、AI方向爱好者对逻辑漏洞有较高关注京东安全应急响应中心（JSRC）京东系产品电商场景爱好者交易链路、售后逻辑比较典型美团安全应急响应中心美团系产品本地生活场景爱好者业务链路复杂，适合练逻辑思维网易安全中心网易系产品游戏、社区方向爱好者游戏场景值得单独研究360安全应急响应中心360系产品综合型选手安全工具用户基数大快手安全应急响应中心快手系产品短视频场景爱好者对风控场景有独特要求滴滴安全应急响应中心滴滴系产品出行场景爱好者地图、订单链路较复杂小米安全中心小米系产品IoT、手机系统方向爱好者涉及智能硬件，很有意思蚂蚁安全响应中心蚂蚁系产品金融、支付场景爱好者对数据安全极其敏感哔哩哔哩安全应急响应中心哔哩哔哩系产品社区生态爱好者年轻业务，规则迭代快携程安全应急响应中心携程系产品在线旅游场景爱好者交易链和客服链复杂拼多多安全应急响应中心拼多多系产品电商场景爱好者风控链路严格小红书安全应急响应中心小红书系产品内容社区方向爱好者对内容安全要求高不要一上来就看“哪个平台钱多”，对你个人来说更容易出成果的平台才是好平台。比如你长期用某个App、熟悉它的业务流程，就从这个App背后的SRC开始。越熟悉业务，越容易发现真正有价值的逻辑问题。2.3 运营商与终端厂商SRC：资产硬核，竞争压力相对小第三类以运营商和设备厂商为主。它们的资产大多是基础通信网络、终端设备、软硬件结合的场景，对Web安全的知识要求略低一点，但对协议、业务系统理解的要求更高。很多人因为不熟悉这类资产而忽略这些平台，反而让这里的竞争压力比头部互联网SRC小一些。平台名称定位适合人群说明华为安全应急响应中心设备、云、软件生态对通信、云场景感兴趣的人覆盖设备端，硬核方向中国移动安全应急响应中心运营商业务系统偏基础设施方向的人资产体量很大中国电信安全应急响应中心运营商业务系统偏基础设施方向的人地域分支多，场景丰富中国联通安全应急响应中心运营商业务系统偏基础设施方向的人适合长期主义选手如果你对运营商或终端设备的业务不太熟，可以先花时间看看它们的公开文档和App，再决定要不要投入。资产硬核的地方往往出不了太多报告，但每一份有效报告的质量都会很高，对一个新人建立信心也有帮助。2.4 选平台的三个判断维度我在实战中做过总结，选平台主要看三点。第一是资产复杂度。资产简单的小SRC容易出结果，尤其是逻辑漏洞；资产复杂的大厂SRC对新人反而容易碰壁。第二是规则透明度，认真看平台上有没有明确的定级标准、测试范围表、常见QA，规则写得清楚的地方更容易积累经验。第三是响应速度，提交后几天能收到反馈，审核是否专业，这些问题决定了你能坚持多久。3. 动手之前，先把平台的“游戏规则”读透3.1 授权范围（Scope）决定你能碰什么每个平台都会公布自己的测试范围，通常是一份列表，写清楚哪些域名、哪些App、哪些小程序是被授权的，也会明确哪些是绝对不能碰的，比如第三方支付渠道、合作方系统、没有授权的子公司站点等等。授权范围这个东西，是新手最需要放慢速度读的部分。我见过不止一个新人，花力气打下一个厂商的漏洞，结果连奖励都没拿到，因为目标根本不在授权范围内，或者属于第三方提供的公共组件。还有更严重的情况，测试过程影响到了线上真实用户数据，被平台直接封号。这里的教训就一句话：动手之前先看地图，别拿自己账号去试错。3.2 漏洞定级与奖励逻辑不同平台的具体名目和金额不一样，但定级逻辑的核心其实是相通的。通常分严重、高危、中危、低危四档，越能直接影响用户数据、资金安全、核心业务可用性，级别越高。比如一个能直接读取任意用户信息的漏洞，通常就是严重或高危；一个只会给自己账号带来无效权限的问题，可能只是低危。理解定级逻辑，你就明白为什么同样是漏洞，有些报告价值很高，有些却只算积分。建议你去看每个平台公示的定级标准，那等于是一份告诉你“什么值钱”的说明书。3.3 一份合格漏洞报告的最低要求我在审核侧了解到的反馈是，很多报告根本没到“漏洞真假”这一步，就倒在“表达不清楚”上了。报告至少要包含：漏洞类型、漏洞地址、详细复现步骤、请求和响应关键数据、修复建议，这个顺序不能乱。复现步骤尤其重要，你不仅要写“我做了什么”，还要写清楚每一步操作后的现象。审核员不是你，没法知道你脑子里想的路径。把报告当成一份沟通文档来写，而不是给自己看的工作记录，这一点能大幅提高你的通过率。4. 零基础到第一个有效漏洞的实操路径4.1 先建好合法练习环境我强烈建议零基础的朋友先在一个完全自建的环境里把基础动作练熟，而不是直接往真实SRC上冲。你可以用虚拟机，也可以用自己的电脑装一个本地靶场，比如DVWA、Pikachu这类开源漏洞练习环境，再有条件的话可以搭一套包含前端、后端和简单数据库的Web应用。这些环境的意义不是让你背答案，而是让你在没负担的情况下反复体验漏洞产生的原理。比如一个搜索框为什么会导致数据库查询异常，一个找回密码的逻辑为什么能越权，你亲手改参数、看响应、对比正常和异常行为，比看任何文章都有效。4.2 从信息收集开始，不急着打点很多人一上来就想找一个“能直接打进后台”的漏洞，这个方向从一开始就偏了。正规SRC测试的起点是信息收集，但这里的信息收集不是去攻击别人，而是理解目标资产：哪些子域名存在，这是个什么业务系统，用的是哪类框架，登录与核心流程分布在什么路径上。把这些信息梳理清楚，整理成一张自己能看懂的资产表格，然后从中找出边缘资产。很多时候，安全防护最薄弱的地方不是核心主站，而是被人遗忘的管理后台、旧版本系统、临时上线的活动页面。研究这些边缘资产的好处是：即使没有漏洞，你也能从中学到大量的真实业务结构。4.3 把你的测试过程写成可复现的报告哪怕你只是在自建靶场上发现了一个问题，也建议你严格按照真实平台报告模板去写：先描述这是什么漏洞，再写触发前提，然后按步骤复现，一台手机或一台电脑跟着你的步骤能完全走一遍，最后给出危害评级和修复建议。这份能力是通用的，等你后面去真实平台提交时，会发现这套写作习惯直接决定了审核效率。我还见过一种情况，同一个漏洞，一个提交者只写了“存在XSS”，另一个提交者附上了完整的前置条件、触发路径和影响面分析，后者的评分明显更高。这不是玄学，是沟通能力在起作用。5. 新手最容易踩的坑和我的解法5.1 撞洞（duplicate）到底怎么避免撞洞是指你辛辛苦苦挖出来的漏洞，别人已经先提交了，平台会标记为重复，通常不计赏金。这是SRC里最打击新人热情的一件事，但它是没办法完全消除的。我的做法是：动手之前先看平台已收录报告里有没有相关提示，有些平台会公开已确认漏洞类型；测试时从小范围、低频次的请求开始，先证明存在性，再深入放大影响；如果发现一个疑似很严重的问题，先查它是否有公开的先例或补丁记录。磨刀不误砍柴工，这一步不能省。5.2 别把“测试”做成“攻击”认真划清这条线，比任何技术都重要。你测试的目标是证明“漏洞存在”和“可能造成什么影响”，而不是真的去获取别人的数据、修改业务数据、把系统打不可用。比如发现一个越权漏洞，正道做法是构造两个你能控制的账号，证明数据能跨账号访问边界即可，不要拿真实用户数据去验证。发现一个可能批量拉取数据的接口，就在最小范围内用一条请求证明接口行为异常就够了。平台要的是证据，不是破坏演示。5.3 沟通不是求人，是专业协作提交报告后，可能会遇到平台要求补充材料的情况，甚至遇到你觉得定级偏低的时候。这时候不要急着抱怨，先判断对方的问题是否合理。如果合理，配合补充证据链；如果觉得不合理，整理好对比案例、行业公开标准，有理有据地说明。我在这个行业里看到太多人因为语气问题吃暗亏。安全圈子说大不大，审核员和提交者的关系应该是长期协作关系，不是你争我抢的对抗关系。你越专业、越配合，后面的合作机会越多。6. 从“提交漏洞”到“持续沉淀”的几个习惯6.1 每一份报告都是复盘样本我记账式复盘过自己提交的每一份报告，包括通过的、被打回的、标重复的。有没有效先不说，只看一个维度：这一次我在哪一步浪费了最多时间？信息收集阶段、漏洞确认阶段还是报告写作阶段？几次复盘之后，你就会非常清楚自己的问题分布。有人总是花太多时间在没希望的资产上，迟迟不出报告；有人技术判断没问题但报告写得像流水账，审核看不懂。这些问题自己很难发现，但复盘会让它们暴露得明明白白。6.2 长期价值的核心是知识库零散总结和体系化知识库之间隔着一条肉眼可见的鸿沟。一个成熟的SRC研究者，通常都会有一个属于自己的知识库：按漏洞类型分类，按业务场景分类，记录触发条件、验证方法、漏洞代码特征和修复建议。有了这个库，你面对新目标时的第一反应不是“怎么打个洞”，而是“它的业务和哪些历史案例相似，可能在哪里出现问题”。这种判断力才是从“挖到一个漏洞”走向“持续挖到漏洞”的分水岭。6.3 保持边界感才能走远最后一点，也是我觉得对新人最重要的一点：永远不要把技术能力变成风险。每一次测试之前都问自己一句，当前操作在不在授权范围？会不会影响真实用户？对目标的伤害是不是超出了“验证存在”所需的程度？我见过不少很有天赋的研究者，技术能力很强，但因为没有边界感，账号没了，甚至给自己惹上了更大的麻烦。技术是一把工具，规则才是那双手。在SRC这个场子里，所有有价值的能力都建立在合规和信任之上，这一点在你刚开始的时候想清楚，胜过一切技巧。最后再分享一个小习惯：我每次注册一个新的漏洞提交平台，第一件事不是看公告区，而是先把它的“常见问题”和“定级标准”从头到尾读一遍，把关键条目复制进自己的文档里。这一步只要花20分钟，后面能帮你省掉至少五个因规则不清而浪费的测试周末。挖洞这条路没有捷径，你能比别人走得稳，往往不靠天赋，靠的是把基础规则当成信仰一样的执行力。
我的私信里出现频率最高的问题，基本是这几类：新手想进网络安全行业，不知道从哪下手；会一点基础技术，但不知道“漏洞提交平台”到底怎么玩；还有人注册了好几个平台，提交了几份报告都石沉大海，慢慢就放弃了。这篇文章我想把这件事从头到尾讲透：先搞清楚SRC是什么、为什么这几年大家都开始关注它，再把这几年我整理过的25个漏洞提交平台按类别盘一遍，然后讲透平台规则、新手实操路径、常见坑和长期成长方法。无论你是零基础，还是已经提交过几份报告但没过审的人，这一篇都能帮你在脑子里建立一张完整的地图。先说一句最重要的：所有正规漏洞提交平台都是“邀请制”的安全测试，你只能测平台明确授权的资产，测试数据也要在授权范围内使用。这不是口号，是红线。越过这条线，轻则封号，重则可能会被追究法律责任。后面我会反复强调这一点。1. 为什么这几年“漏洞提交平台”越来越值得关注1.1 SRC是怎么运作的SRC是Security Response Center的缩写，中文叫安全应急响应中心。它是企业对外开设的一个正式窗口，用来接收外部安全研究者提交的漏洞报告。企业在这套机制里公开自家业务范围内允许测试的域名、App、小程序等资产，说明清楚哪些能测、哪些不能测，然后等安全研究者来测试，提交漏洞后企业会定级、审核、修复，并给提交者发奖金、积分或荣誉。我以前跟朋友打过一个比方：没有SRC的时候，发现漏洞的人像一个闯空门的，哪怕是好心提醒主人锁坏了，也有说不清的麻烦；有了SRC，你变成了主人请来的安保巡检员，拿着地图在允许的区域内检查门锁。同样是干一件事，身份和边界完全不同。这也是SRC近些年越来越受关注的核心原因。对于企业来说，与其等漏洞被恶意利用或被拐弯抹角地卖到黑市，不如主动开门，花可控的成本把风险暴露在阳光下。对于安全研究者来说，SRC提供了一条合法、可持续、有回报的通道。1.2 白帽、平台、企业三方共赢很多新人容易把漏洞提交平台想象成“奖金池”，好像只要提交就一定有赏金。实际上的逻辑不是这样的，它更像是一个三方协作的机制。企业在里面获得的是安全加固——漏洞被发现、被修复，损失被避免；漏洞平台获得的是生态和声誉，提交者和企业都在它的体系里沉淀；而以白帽身份参与的个人，获得的除了现金和积分，更重要的是实战场景、丰富的验证案例和在行业里的可信记录。这份“可信记录”越往后你越会发现它值钱。很多做安全的人并不是靠某个漏洞报告里的那几百块奖金发家的，而是靠持续提交高质量报告，让企业方从看到名字就信任，到慢慢建立长期合作。这个积累本身，就是你在行业里的资产。1.3 什么样的人适合进场说实话，谁都可以进场，但能稳住的人通常有几种基础。最基础的是对HTTP协议有直观理解，知道请求和响应是怎么回事；其次是喜欢琢磨“业务逻辑”，不只是背漏洞类型；再就是有耐心去读平台的规则和报告模板，不急着上手就扫。如果你还在上学，或者正在做运维、后端研发、测试相关工作，又或者你对网络安全的攻防原理感兴趣但一直缺一个合法练手的地方，那么SRC非常合适。它不像CTF比赛那么偏解题，也不像护网行动门槛那么高，它是一个可以直接把能力和真实业务结合起来练的场所。2. 25个漏洞提交平台分类盘点：选平台就是在选资产很多新手第一个问题就是“我该去哪个平台”。我的建议一直是：不要漫无目的地注册，你先要想清楚自己想测什么类型的资产。平台只是入口，资产才是你真正面对的对象。下面我把这25个平台拆成三类来看，每一类适合的人群和玩法都不同。2.1 国家级/行业级漏洞库：做的是社会层面的贡献这一组的共同点是：它们不完全按企业SRC那种“测某个App某个域名”的方式运作，更多是接收通用软件漏洞、系统漏洞，库里的数据会上报给国家相关机构做预警和通报。提交这类漏洞往往没有企业SRC那么高的现金回报，但它对行业的意义更大，有些漏洞还能拿到原创漏洞证明之类的认可。平台名称定位适合人群说明CNVD（国家信息安全漏洞共享平台）国内通用漏洞收集与通报偏二进制、通用软件研究的人对通用软件漏洞、开源组件漏洞比较友好CNNVD（国家信息安全漏洞库）漏洞信息汇总与查询所有人主要偏向漏洞披露后的收录与查询CNCERT（国家互联网应急中心）网络安全事件监测与协调关注事件型漏洞的人更多是应急协调视角，和主动挖SRC略有不同这个类别里，我最建议关注的是CNVD。如果你在某套开源系统、某个开源组件里发现一个前人没提交过的高质量漏洞，走这里的价值比丢给某个企业SRC更合适，因为它影响的不只是一家企业，而是整个在用这套组件的行业。2.2 头部互联网企业SRC：新人入门的核心训练场下面这些平台是互联网行业里相对活跃、规则相对成熟、资产规模也比较大的企业SRC。它们的共同特点是：资产种类全，有网站、App、小程序、业务接口，定级标准相对透明，奖励机制也比较完善。平台名称开放资产适合人群观察点腾讯安全应急响应中心（TSRC）腾讯系产品综合型选手资产多、报告要求规范阿里巴巴安全应急响应中心（ASRC）阿里系产品综合型选手对电商、云场景理解要求高字节跳动安全中心字节系产品综合型选手成长快，业务复杂百度安全应急响应中心（BSRC）百度系产品搜索、AI方向爱好者对逻辑漏洞有较高关注京东安全应急响应中心（JSRC）京东系产品电商场景爱好者交易链路、售后逻辑比较典型美团安全应急响应中心美团系产品本地生活场景爱好者业务链路复杂，适合练逻辑思维网易安全中心网易系产品游戏、社区方向爱好者游戏场景值得单独研究360安全应急响应中心360系产品综合型选手安全工具用户基数大快手安全应急响应中心快手系产品短视频场景爱好者对风控场景有独特要求滴滴安全应急响应中心滴滴系产品出行场景爱好者地图、订单链路较复杂小米安全中心小米系产品IoT、手机系统方向爱好者涉及智能硬件，很有意思蚂蚁安全响应中心蚂蚁系产品金融、支付场景爱好者对数据安全极其敏感哔哩哔哩安全应急响应中心哔哩哔哩系产品社区生态爱好者年轻业务，规则迭代快携程安全应急响应中心携程系产品在线旅游场景爱好者交易链和客服链复杂拼多多安全应急响应中心拼多多系产品电商场景爱好者风控链路严格小红书安全应急响应中心小红书系产品内容社区方向爱好者对内容安全要求高不要一上来就看“哪个平台钱多”，对你个人来说更容易出成果的平台才是好平台。比如你长期用某个App、熟悉它的业务流程，就从这个App背后的SRC开始。越熟悉业务，越容易发现真正有价值的逻辑问题。2.3 运营商与终端厂商SRC：资产硬核，竞争压力相对小第三类以运营商和设备厂商为主。它们的资产大多是基础通信网络、终端设备、软硬件结合的场景，对Web安全的知识要求略低一点，但对协议、业务系统理解的要求更高。很多人因为不熟悉这类资产而忽略这些平台，反而让这里的竞争压力比头部互联网SRC小一些。平台名称定位适合人群说明华为安全应急响应中心设备、云、软件生态对通信、云场景感兴趣的人覆盖设备端，硬核方向中国移动安全应急响应中心运营商业务系统偏基础设施方向的人资产体量很大中国电信安全应急响应中心运营商业务系统偏基础设施方向的人地域分支多，场景丰富中国联通安全应急响应中心运营商业务系统偏基础设施方向的人适合长期主义选手如果你对运营商或终端设备的业务不太熟，可以先花时间看看它们的公开文档和App，再决定要不要投入。资产硬核的地方往往出不了太多报告，但每一份有效报告的质量都会很高，对一个新人建立信心也有帮助。2.4 选平台的三个判断维度我在实战中做过总结，选平台主要看三点。第一是资产复杂度。资产简单的小SRC容易出结果，尤其是逻辑漏洞；资产复杂的大厂SRC对新人反而容易碰壁。第二是规则透明度，认真看平台上有没有明确的定级标准、测试范围表、常见QA，规则写得清楚的地方更容易积累经验。第三是响应速度，提交后几天能收到反馈，审核是否专业，这些问题决定了你能坚持多久。3. 动手之前，先把平台的“游戏规则”读透3.1 授权范围（Scope）决定你能碰什么每个平台都会公布自己的测试范围，通常是一份列表，写清楚哪些域名、哪些App、哪些小程序是被授权的，也会明确哪些是绝对不能碰的，比如第三方支付渠道、合作方系统、没有授权的子公司站点等等。授权范围这个东西，是新手最需要放慢速度读的部分。我见过不止一个新人，花力气打下一个厂商的漏洞，结果连奖励都没拿到，因为目标根本不在授权范围内，或者属于第三方提供的公共组件。还有更严重的情况，测试过程影响到了线上真实用户数据，被平台直接封号。这里的教训就一句话：动手之前先看地图，别拿自己账号去试错。3.2 漏洞定级与奖励逻辑不同平台的具体名目和金额不一样，但定级逻辑的核心其实是相通的。通常分严重、高危、中危、低危四档，越能直接影响用户数据、资金安全、核心业务可用性，级别越高。比如一个能直接读取任意用户信息的漏洞，通常就是严重或高危；一个只会给自己账号带来无效权限的问题，可能只是低危。理解定级逻辑，你就明白为什么同样是漏洞，有些报告价值很高，有些却只算积分。建议你去看每个平台公示的定级标准，那等于是一份告诉你“什么值钱”的说明书。3.3 一份合格漏洞报告的最低要求我在审核侧了解到的反馈是，很多报告根本没到“漏洞真假”这一步，就倒在“表达不清楚”上了。报告至少要包含：漏洞类型、漏洞地址、详细复现步骤、请求和响应关键数据、修复建议，这个顺序不能乱。复现步骤尤其重要，你不仅要写“我做了什么”，还要写清楚每一步操作后的现象。审核员不是你，没法知道你脑子里想的路径。把报告当成一份沟通文档来写，而不是给自己看的工作记录，这一点能大幅提高你的通过率。4. 零基础到第一个有效漏洞的实操路径4.1 先建好合法练习环境我强烈建议零基础的朋友先在一个完全自建的环境里把基础动作练熟，而不是直接往真实SRC上冲。你可以用虚拟机，也可以用自己的电脑装一个本地靶场，比如DVWA、Pikachu这类开源漏洞练习环境，再有条件的话可以搭一套包含前端、后端和简单数据库的Web应用。这些环境的意义不是让你背答案，而是让你在没负担的情况下反复体验漏洞产生的原理。比如一个搜索框为什么会导致数据库查询异常，一个找回密码的逻辑为什么能越权，你亲手改参数、看响应、对比正常和异常行为，比看任何文章都有效。4.2 从信息收集开始，不急着打点很多人一上来就想找一个“能直接打进后台”的漏洞，这个方向从一开始就偏了。正规SRC测试的起点是信息收集，但这里的信息收集不是去攻击别人，而是理解目标资产：哪些子域名存在，这是个什么业务系统，用的是哪类框架，登录与核心流程分布在什么路径上。把这些信息梳理清楚，整理成一张自己能看懂的资产表格，然后从中找出边缘资产。很多时候，安全防护最薄弱的地方不是核心主站，而是被人遗忘的管理后台、旧版本系统、临时上线的活动页面。研究这些边缘资产的好处是：即使没有漏洞，你也能从中学到大量的真实业务结构。4.3 把你的测试过程写成可复现的报告哪怕你只是在自建靶场上发现了一个问题，也建议你严格按照真实平台报告模板去写：先描述这是什么漏洞，再写触发前提，然后按步骤复现，一台手机或一台电脑跟着你的步骤能完全走一遍，最后给出危害评级和修复建议。这份能力是通用的，等你后面去真实平台提交时，会发现这套写作习惯直接决定了审核效率。我还见过一种情况，同一个漏洞，一个提交者只写了“存在XSS”，另一个提交者附上了完整的前置条件、触发路径和影响面分析，后者的评分明显更高。这不是玄学，是沟通能力在起作用。5. 新手最容易踩的坑和我的解法5.1 撞洞（duplicate）到底怎么避免撞洞是指你辛辛苦苦挖出来的漏洞，别人已经先提交了，平台会标记为重复，通常不计赏金。这是SRC里最打击新人热情的一件事，但它是没办法完全消除的。我的做法是：动手之前先看平台已收录报告里有没有相关提示，有些平台会公开已确认漏洞类型；测试时从小范围、低频次的请求开始，先证明存在性，再深入放大影响；如果发现一个疑似很严重的问题，先查它是否有公开的先例或补丁记录。磨刀不误砍柴工，这一步不能省。5.2 别把“测试”做成“攻击”认真划清这条线，比任何技术都重要。你测试的目标是证明“漏洞存在”和“可能造成什么影响”，而不是真的去获取别人的数据、修改业务数据、把系统打不可用。比如发现一个越权漏洞，正道做法是构造两个你能控制的账号，证明数据能跨账号访问边界即可，不要拿真实用户数据去验证。发现一个可能批量拉取数据的接口，就在最小范围内用一条请求证明接口行为异常就够了。平台要的是证据，不是破坏演示。5.3 沟通不是求人，是专业协作提交报告后，可能会遇到平台要求补充材料的情况，甚至遇到你觉得定级偏低的时候。这时候不要急着抱怨，先判断对方的问题是否合理。如果合理，配合补充证据链；如果觉得不合理，整理好对比案例、行业公开标准，有理有据地说明。我在这个行业里看到太多人因为语气问题吃暗亏。安全圈子说大不大，审核员和提交者的关系应该是长期协作关系，不是你争我抢的对抗关系。你越专业、越配合，后面的合作机会越多。6. 从“提交漏洞”到“持续沉淀”的几个习惯6.1 每一份报告都是复盘样本我记账式复盘过自己提交的每一份报告，包括通过的、被打回的、标重复的。有没有效先不说，只看一个维度：这一次我在哪一步浪费了最多时间？信息收集阶段、漏洞确认阶段还是报告写作阶段？几次复盘之后，你就会非常清楚自己的问题分布。有人总是花太多时间在没希望的资产上，迟迟不出报告；有人技术判断没问题但报告写得像流水账，审核看不懂。这些问题自己很难发现，但复盘会让它们暴露得明明白白。6.2 长期价值的核心是知识库零散总结和体系化知识库之间隔着一条肉眼可见的鸿沟。一个成熟的SRC研究者，通常都会有一个属于自己的知识库：按漏洞类型分类，按业务场景分类，记录触发条件、验证方法、漏洞代码特征和修复建议。有了这个库，你面对新目标时的第一反应不是“怎么打个洞”，而是“它的业务和哪些历史案例相似，可能在哪里出现问题”。这种判断力才是从“挖到一个漏洞”走向“持续挖到漏洞”的分水岭。6.3 保持边界感才能走远最后一点，也是我觉得对新人最重要的一点：永远不要把技术能力变成风险。每一次测试之前都问自己一句，当前操作在不在授权范围？会不会影响真实用户？对目标的伤害是不是超出了“验证存在”所需的程度？我见过不少很有天赋的研究者，技术能力很强，但因为没有边界感，账号没了，甚至给自己惹上了更大的麻烦。技术是一把工具，规则才是那双手。在SRC这个场子里，所有有价值的能力都建立在合规和信任之上，这一点在你刚开始的时候想清楚，胜过一切技巧。最后再分享一个小习惯：我每次注册一个新的漏洞提交平台，第一件事不是看公告区，而是先把它的“常见问题”和“定级标准”从头到尾读一遍，把关键条目复制进自己的文档里。这一步只要花20分钟，后面能帮你省掉至少五个因规则不清而浪费的测试周末。挖洞这条路没有捷径，你能比别人走得稳，往往不靠天赋，靠的是把基础规则当成信仰一样的执行力。