CNVD漏洞提交实战指南：从SRC到国家级平台的全流程解析

1. 项目概述从SRC到CNVD的实战路径如果你在安全圈混过一阵子或者刚入门漏洞挖掘肯定对“SRC”和“CNVD”这两个词不陌生。SRC也就是安全应急响应中心通常是企业自己设立的用来接收白帽子提交的自家产品漏洞然后发奖金、发证书。而CNVD全称国家信息安全漏洞共享平台它的层级和性质就完全不同了。简单来说你可以把SRC看作是“企业级”的漏洞收集和处理窗口而CNVD则是“国家级”的漏洞信息汇集、分析和发布的枢纽。很多刚入行的朋友会有一个误区觉得挖到了漏洞往CNVD一提交就完事了或者反过来觉得CNVD的流程太“官方”、太复杂不如刷SRC来得直接痛快。其实这两者并非互斥而是一种相辅相成、可以打“组合拳”的关系。我个人的体会是一个高质量、影响范围广的漏洞其价值完全可以通过“SRCCNVD”的双轨路径得到最大化。比如你发现了一个某流行开源框架的远程代码执行漏洞这个框架被成千上万家单位使用。你除了可以向该框架所属公司的SRC如果有的话报告更应该向CNVD提交。因为CNVD的通报机制能更快速、更权威地触达所有使用该框架的政企单位推动他们进行修复从而真正消除安全隐患这其中的社会价值远非单个厂商的奖金可比。同时一份被CNVD收录的漏洞证明在求职、晋升、评职称时其含金量也是业界广泛认可的。所以搞清楚CNVD的漏洞提交流程绝不是为了“刷证书”而是每一位负责任的安全研究者都应该掌握的、将技术能力转化为实际安全价值的关键技能。接下来我就结合自己多次提交的经验把CNVD漏洞提交这件事从前期准备到报告撰写再到提交后的各种状态给你彻底讲明白。2. CNVD漏洞提交全流程拆解与核心思路2.1 流程全景与阶段划分CNVD的漏洞提交远不止是在网站上填个表单那么简单。它是一个从漏洞验证、信息整理、报告撰写到持续跟踪的完整项目。我们可以把这个流程清晰地划分为四个主要阶段前期准备与漏洞验证、报告撰写与信息整理、平台提交与材料上传、以及提交后状态跟踪与沟通。每个阶段都有其核心目标和容易踩坑的地方。整个流程的核心思路是严谨、客观、可复现。CNVD作为国家级平台对漏洞报告的质量要求非常高。你的报告必须像一个严谨的科学实验记录让审核人员能够根据你的描述独立、完整地复现出漏洞。任何模糊、夸张或无法验证的描述都可能导致报告被驳回或降级处理。因此你的所有工作都应围绕“如何让一个完全陌生的人能照着你的步骤把漏洞原样挖出来”这个目标展开。2.2 前期准备比挖掘更重要的环节很多人挖到漏洞后兴奋不已立刻就去提交往往在第一步就卡住了。前期准备不足是导致提交失败最常见的原因。2.2.1 漏洞的深度验证与影响面评估首先你需要对漏洞本身进行二次甚至三次验证。这不仅仅是确认漏洞存在更要明确漏洞触发条件是否需要登录需要什么权限是否依赖特定的配置或环境漏洞稳定复现率是不是每次都能成功有没有什么随机因素我建议至少在不同时间、清理浏览器缓存后复现3次以上。漏洞的真实危害这个漏洞到底能做什么是信息泄露能泄露什么数据、权限提升能从什么角色提升到什么角色、还是代码执行能执行任意命令吗。切忌夸大危害。一个反射型XSS硬说成能“完全控制服务器”只会让审核人员觉得你不专业。影响范围评估这是CNVD非常看重的一点。你需要初步评估这个漏洞的影响面。对于具体产品/组件明确受影响的准确版本号。是某个版本独有还是某个版本范围如V1.0.0至V1.2.0通过官网更新日志、GitHub的Release记录等渠道去核实。对于通用型漏洞比如某个框架的漏洞你需要通过搜索引擎、GitHub搜索等方式粗略估算可能使用该框架的网站或系统数量。可以使用特定的语法如inurl:”/vendor/some-framework/”或“Powered by XXX Framework”来辅助判断。一个影响数千甚至数万系统的框架漏洞其评级和关注度会高很多。2.2.2 关键信息的收集与归档在开始写报告前请务必建立一个文件夹把以下材料准备好漏洞证明截图/录屏这是最重要的证据。截图要清晰包含浏览器地址栏显示完整URL、页面关键元素、以及漏洞触发的证明如弹窗、执行结果、数据包响应。对于复杂交互漏洞强烈建议使用屏幕录制软件如OBS、Bandicam录制一段短视频从正常访问到触发漏洞的全过程。网络数据包捕获使用Burp Suite、Fiddler或浏览器开发者工具抓取触发漏洞的关键HTTP/HTTPS请求和响应。将数据包保存为文件如.har格式或Burp的.xml并高亮标出触发漏洞的参数和恶意载荷。环境信息你测试时使用的浏览器及版本、操作系统、测试时间等。这有助于排除环境特异性问题。厂商信息尽可能找到受漏洞影响的产品或组件的官方名称、所属公司/组织、官网地址、联系方式通常可在官网“联系我们”或“安全公告”页面找到。注意在整个准备和测试过程中务必遵守法律法规和道德准则。仅对你拥有明确测试授权的资产如SRC公开的范围、或属于你自己搭建的测试环境进行漏洞验证。未经授权对他人系统进行渗透测试是违法行为。3. 漏洞报告撰写将技术细节转化为审核语言这是整个流程中最考验功力的一环。一份优秀的CNVD漏洞报告就像一篇结构清晰的学术报告。3.1 报告核心结构与写作要点CNVD的提交表单有固定字段但精髓在于你如何填写这些字段。我们可以提前在文档中草拟。3.1.1 漏洞标题标题要精准、客观。建议采用“【厂商/产品名称】【漏洞类型】漏洞”的格式。差示例“某系统存在严重漏洞”过于模糊。好示例“XXCMS V5.1 后台SQL注入漏洞”、“Apache Spark UI 未授权访问导致命令执行漏洞”。3.1.2 漏洞类型从CNVD提供的列表如SQL注入、跨站脚本、权限绕过、信息泄露、命令执行等中准确选择。如果不确定可以选择“其他”并在描述中说明。3.1.3 厂商及产品信息尽可能填写准确。如果厂商是“个人开发者”或开源项目可以填写项目名称和托管地址如GitHub链接。3.1.4 漏洞描述重中之重这是报告的核心建议分为以下几个段落来写背景介绍用一两句话说明受影响的产品/组件是什么其主要用途是什么。漏洞详情清晰描述漏洞存在的功能点或接口。例如“在XX系统的用户管理模块编辑用户信息时对user_id参数未进行有效过滤。”漏洞原理简要说明漏洞的技术原理。例如“该参数直接拼接进入SQL查询语句导致攻击者可以构造恶意输入改变原SQL语句的逻辑从而执行任意数据库操作。”漏洞证明这部分要极其详细。不要只说“可以弹窗”。你需要提供请求详情提供完整的HTTP请求Method, URL, Headers, Body。对于GET请求给出完整URL对于POST请求给出请求体。恶意载荷你具体输入的、触发漏洞的Payload是什么。响应详情服务器返回的响应是什么关键部分即可如包含数据库错误信息、执行结果等。复现步骤用编号列表的形式一步一步写清楚从登录如果需要到触发漏洞的完整操作。例如“1. 访问http://target.com/login使用账号admin/123456登录。2. 进入‘用户管理’-‘编辑用户’。3. 在用户ID输入框中将值改为1 AND 11。4. 提交后观察页面返回结果...”影响版本明确写出“经测试XXX产品 V1.0.0 至 V1.2.0 版本受此漏洞影响”。如果只知道某个版本存在就写“XXX产品 V1.1.0 版本存在该漏洞”。3.1.5 漏洞危害客观描述漏洞可能造成的后果如“导致攻击者无需密码即可登录任意用户账户”、“可获取数据库中的所有用户敏感信息”、“可在服务器上执行任意系统命令导致服务器被完全控制”。同样要避免夸大。3.1.6 修复建议给出具体、可操作的修复方案。这体现了你的专业性和建设性。通用建议如“对用户输入进行严格的过滤和参数化查询”、“对访问该接口的请求进行有效的身份验证和授权检查”。具体建议如果能定位到代码行可以更具体如“建议将query()函数改为使用预编译语句Prepared Statement”。临时缓解措施如果暂时无法修复可以建议临时方案如“在Web应用防火墙WAF中添加相应规则拦截恶意请求”。3.2 附件材料的准备技巧附件是报告的有力支撑。截图将关键步骤的截图登录界面、漏洞触发点、执行结果按顺序编号如图1-登录界面.png图2-注入点.png。可以在图片上用画图工具添加箭头、方框等标注。数据包文件将Burp Suite保存的请求/响应数据推荐保存整个会话为.xml或单个请求为.req文件作为附件。确保数据包中包含你的攻击Payload。录屏视频如果漏洞触发过程复杂录屏是最佳选择。视频应简短建议1-3分钟清晰展示从开始到漏洞触发的全过程。可以配上简单的文字说明或语音解说。输出为通用格式如MP4。漏洞利用代码如果漏洞有公开的Exp或你编写了利用脚本可以附上。但务必谨慎确保代码不会对他人系统造成损害最好只是证明性的概念代码PoC。实操心得写报告时想象你的读者是一个技术不错但对该系统一无所知的安全工程师。你的描述能否让他搭建起一个类似的环境然后完美复现漏洞所有模棱两可的地方都是被退回的隐患。我习惯在写完报告后让自己“冷却”半天再以审核者的视角重读一遍往往能发现不少可以优化和明确的地方。4. 平台提交实操与表单填写详解准备好报告和材料后就可以登录CNVD平台进行提交了。4.1 访问与登录通过搜索引擎找到“国家信息安全漏洞共享平台”官网。你需要注册一个账号。注册信息请如实填写特别是邮箱和手机号这将是后续官方与你联系的主要渠道。4.2 漏洞提交表单逐项解析登录后找到“漏洞提交”或类似的入口。表单字段可能随时间微调但核心内容不变。漏洞标题将你之前拟好的标题粘贴进去。漏洞类型从下拉菜单中准确选择。CVE编号如果该漏洞已有CVE编号例如你在其他平台先提交了可以填写。如果没有留空即可CNVD会自行分配CNVD-ID。涉及厂商填写公司或组织全称。如果是开源项目填写项目名。产品名称填写具体的软件、硬件或系统名称。版本号务必填写你验证过的、受影响的准确版本号。漏洞描述将你在文档中精心撰写的“漏洞描述”部分完整粘贴进来。注意格式清晰可以使用换行和列表。漏洞危害粘贴“漏洞危害”部分。修复方案粘贴“修复建议”部分。参考链接可以附上产品官网、开源项目地址、或相关技术文章链接。附件上传这是关键步骤。将你准备好的截图、数据包文件、视频等逐一上传。建议对附件进行简要命名说明如“漏洞复现步骤截图.zip”、“Burp数据包.xml”、“漏洞复现录屏.mp4”。发现者信息填写你的个人信息平台账号关联的。这里通常涉及漏洞归属。如果你是代表团队或公司提交需要明确。个人提交则归属个人。公开程度一般选择“申请CNVD编号暂不公开”。待CNVD审核收录并协调厂商修复后会根据情况公开细节。4.3 提交后的确认与初次审核点击提交后你会收到一个提交成功的提示并且通常会在“我的提交”或类似页面看到一个漏洞列表其中包含你刚提交的记录状态可能是“待审核”、“审核中”等。这里有一个非常重要的点也是很多新手困惑的地方提交成功不等于被收录。提交成功仅仅意味着你的报告已经进入CNVD的待处理队列。接下来会进入人工审核阶段。5. 提交后状态跟踪、沟通与常见问题提交只是开始等待和沟通同样重要。5.1 漏洞生命周期与状态解读你的漏洞报告在CNVD平台通常会经历以下几个状态理解这些状态的含义至关重要状态含义你应该做什么待审核/审核中报告已进入队列等待审核人员处理。耐心等待。此时无需任何操作除非审核人员通过邮件或站内信联系你要求补充材料。已驳回审核未通过。仔细阅读驳回理由这是提升自己的关键。理由可能是“漏洞无法复现”、“信息不全”、“漏洞危害过低”、“重复提交”等。根据理由补充材料、完善报告或重新测试后可以修改报告再次提交。已收录已分配CNVD-ID恭喜漏洞被确认并正式收录。在平台或通过邮件查收你的CNVD编号格式如CNVD-YYYY-XXXXX。这个编号是你的成果凭证。已公开漏洞细节在CNVD官网公开。通常是在厂商发布补丁或一定时间后。你可以分享这个公开链接。协调中CNVD正在联系相关厂商处理漏洞。耐心等待。有时CNVD可能会联系你向厂商提供更多技术细节以协助修复。5.2 为什么提交成功后查不到编号这是被问得最多的问题。原因通常有以下几种仍在审核队列从提交到审核完成可能需要数天到数周时间取决于当前漏洞提交量和漏洞的复杂性。请耐心等待。审核未通过漏洞因各种原因未被收录状态可能是“已驳回”。你需要登录平台查看具体状态和驳回意见。信息填写有误例如邮箱填错导致收不到通知。请确保注册邮箱正确并检查垃圾邮件箱。漏洞重复你发现的漏洞已经被其他人提交并通过审核。CNVD对于重复漏洞通常只会收录最早提交且信息完整的报告。排查建议首先登录CNVD平台在个人中心查看提交记录的状态。如果状态是“已收录”但没收到邮件可以检查平台页面是否显示了CNVD-ID。如果状态长时间如超过一个月卡在“审核中”可以尝试通过平台提供的官方联系邮箱非紧急情况下礼貌地咨询进度附上你的提交编号。5.3 与审核人员的有效沟通在审核过程中审核人员可能会通过邮件与你联系要求补充信息或澄清某些技术细节。这时你的沟通方式直接影响效率。及时响应尽快回复邮件。清晰具体针对对方的问题提供额外的截图、数据包或更详细的复现步骤。避免使用“可能”、“大概”等模糊词汇。保持礼貌和专业沟通的目的是共同确认漏洞推动问题解决。5.4 从SRC到CNVD的联动策略如前所述SRC和CNVD可以联动。一个理想的流程是发现漏洞在属于某企业SRC范围的资产上发现漏洞。优先提交SRC首先按照该SRC的规则提交漏洞。这能确保你获得厂商的快速响应和可能的奖励。评估漏洞性质如果该漏洞属于通用型组件漏洞例如该企业使用的某个开源框架的漏洞其影响范围远超该企业本身。提交CNVD在SRC报告提交后或同时需阅读SRC规则有些SRC要求独家报告期向CNVD提交该通用型组件的漏洞。在报告中可以说明该漏洞已在某厂商SRC报告并提供了CNVD-ID如果已分配或SRC报告编号作为参考。 这样做既遵守了与厂商的约定又能通过国家级平台将漏洞影响告知更广泛的群体最大化安全价值。6. 提升漏洞报告质量的进阶技巧与心得最后分享一些能让你的CNVD漏洞报告脱颖而出、提高收录率和评级的心得。6.1 漏洞的“深度”与“广度”深度挖掘不要满足于一个简单的注入点。尝试进行深入利用比如通过SQL注入获取管理员密码哈希、通过文件上传漏洞写入Webshell并获取服务器权限。一个能证明“深度危害”的漏洞评级会更高。广度验证如果一个漏洞存在于某个产品的多个功能点或者某个框架的多个模块中在报告中应逐一列出这证明了漏洞的普遍性而非个案。6.2 提供高质量的修复方案不要只说“请厂商修复”。如果你有能力可以提供补丁代码对于开源项目可以直接在报告中附上修复后的代码diff片段。分析根本原因指出是输入验证缺失、身份验证逻辑错误还是其他设计缺陷。提供多种修复方案给出立即缓解的临时方案和彻底修复的长期方案。6.3 文档与证据的组织艺术将你的报告和附件视为一个完整的“证据包”。建立一个清晰的目录结构漏洞报告_XX产品SQL注入_YYYYMMDD/ ├── 漏洞报告_详细版.docx ├── 附件/ │ ├── 01_复现步骤截图/ │ ├── 02_BurpSuite数据包.xml │ ├── 03_漏洞复现录屏.mp4 │ └── 04_概念验证代码(PoC).py └── 参考链接.txt在提交时可以将截图打包为ZIP其他文件单独上传。清晰的命名能让审核人员快速找到所需信息。6.4 保持耐心与持续学习漏洞提交和审核是一个需要耐心的过程。即使被驳回也要把驳回意见当作宝贵的学习材料。分析为什么被拒是技术描述问题还是漏洞本身价值不足持续关注CNVD已公开的漏洞报告学习他人优秀的报告写法。同时不断提升自己的漏洞挖掘技术从黑盒测试到代码审计白盒从Web漏洞到移动端、IoT设备漏洞拓宽自己的技术视野。当你能够稳定地挖掘中高危漏洞并能撰写出清晰、专业、证据充分的报告时CNVD提交对你来说就不再是一个神秘的流程而是一个将你的技术能力转化为公认成果的标准化出口。这条路没有捷径唯有多挖、多写、多总结。