1. 项目概述：为什么新手提交CNVD总被驳回？

如果你刚接触网络安全，费了九牛二虎之力挖到一个自认为很严重的漏洞，兴冲冲地整理报告提交到国家信息安全漏洞共享平台（CNVD），结果等来的却是一封“不予收录”或“信息不全”的驳回邮件，那种感觉肯定很挫败。我刚开始提交时也踩过无数坑，被驳回的报告攒了一抽屉。后来和平台审核的老师、圈内一些资深白帽子交流多了，才慢慢摸清了门道。这根本不是技术能力的问题，而是一套需要学习的“规则”和“沟通艺术”。

CNVD作为国家级的漏洞信息汇集和处置枢纽，它的核心目标是协调和督促相关厂商修复可能影响广泛的网络安全漏洞，维护公共互联网安全。因此，它的审核逻辑和你在漏洞盒子、补天这类商业众测平台上的体验完全不同。它不是比赛，不是炫技，更不是“交作业”。审核老师每天要面对海量提交，其中大部分是无效或低质量的报告。他们的工作是在最短时间内，筛选出那些真实存在、危害明确、影响范围可评估、且描述清晰便于分发的漏洞。你的报告，就是与他们高效沟通的唯一工具。

这篇指南，就是把我这些年踩过的坑、总结的经验，以及几个真实的驳回案例掰开揉碎了讲给你听。目标很明确：帮你理解CNVD的“游戏规则”，掌握从漏洞验证、报告撰写到成功提交的完整“正确姿势”，大幅提升首次提交的成功率。我们不止讲“怎么做”，更重点剖析“为什么这么做”以及“不这么做会怎样”。

2. 核心原则：理解CNVD的审核视角与流程

在动手写报告之前，我们必须先换位思考，站在CNVD审核人员的角度，理解他们最关心什么。这决定了你报告的所有细节。

2.1 审核的核心关注点：四要素缺一不可

一份能被CNVD快速收录并进入处置流程的报告，必须同时满足以下四个核心要素：

1. 真实性（Authenticity）：漏洞必须真实存在。这是底线。任何臆测、无法稳定复现或基于错误环境配置的“漏洞”都会被直接驳回。审核人员会尝试复现，如果复现失败，报告基本就结束了。
2. 危害性（Impact）：漏洞必须能造成实际的安全影响。一个需要复杂前置条件、只能获取无关紧要信息的“漏洞”，其处置优先级会非常低。CNVD更关注可导致数据泄露、权限提升、系统控制、拒绝服务等直接危害的漏洞。
3. 可验证性（Verifiability）：你提供的证据必须能让第三方（审核人员）独立、快速地进行验证。模糊的描述、缺失的关键步骤、打码过度的截图，都会增加验证成本，导致报告被搁置或退回补充。
4. 可处置性（Actionability）：报告必须包含足够的信息，让CNVD能够定位到具体的责任厂商（或产品），并推动修复。一个找不到归属的“幽灵”漏洞，即使再严重，平台也难以处理。

2.2 内部处理流程与你的报告定位

简单了解下CNVD收到你报告后的内部流转，能让你更清楚报告在每个阶段需要提供什么：

1. 初审：由值班人员快速筛查。检查格式是否规范、内容是否完整、漏洞类型是否属于平台收录范围（CNVD有明确的收录范围指南）。大部分因“信息不全”、“格式错误”被驳回的报告，都倒在了这一关。你的报告如果在这里被卡住，甚至不会进入技术审核环节。
2. 技术审核：由技术人员进行复现和评估。他们会搭建环境或在线验证你描述的漏洞。此时，报告步骤的清晰度、证据的充分性至关重要。如果复现失败，会给出“无法复现”的结论。
3. 影响评估与定级：根据验证结果，结合漏洞利用难度、攻击路径复杂度、危害程度等因素，参考CVSS等标准进行风险评级（高、中、低）。
4. 厂商分发与协调：根据你提供的厂商信息，CNVD会尝试联系厂商并发送漏洞通告。如果厂商信息错误或缺失，这一步就无法进行。
5. 归档与发布：漏洞处置（修复或确认）完成后，会根据情况公开漏洞信息。

你的报告，本质上是一份技术证据链和沟通文书。它需要说服初审人员“值得看”，帮助技术人员“快速验”，协助分发人员“找对人”。

2.3 新手最容易忽略的“潜规则”

• 时效性不是唯一标准：很多人以为只有最新的、0day漏洞才能提交。事实上，CNVD也收录大量已公开但未修复的Nday漏洞，特别是那些影响范围广、但厂商响应慢的。关键在于，你需要证明该漏洞在目标系统上依然存在且未修复。
• “忽略”与“驳回”的区别：对于明显无效、重复或恶意的提交，平台可能直接“忽略”而不给反馈。你能收到驳回邮件，说明你的报告至少进入了审核流程，只是存在某些可改进的问题。这是好事！
• 沟通渠道是单向的，但报告是双向的：提交后，你通常无法与审核人员直接沟通。因此，报告必须一次性做到“自包含”和“抗质疑”，预判审核人员可能产生的所有疑问，并在报告中提前解答。

3. 报告撰写实战：从漏洞验证到报告成文

现在，我们进入实操环节。假设你已经发现了一个疑似SQL注入的漏洞点。

3.1 漏洞深度验证：超越POC

发现漏洞点只是开始，深度验证决定了漏洞的“价值”。

1. 稳定复现：确保在任何时候、任何网络条件下，按照你的步骤都能触发漏洞。记录下完整的HTTP请求（包括所有Header、Cookie、Post数据）。使用Burp Suite的Repeater模块多次测试是个好习惯。
2. 危害证明：不要只满足于一个报错页面或一个简单的sleep(5)延时。尝试证明其实际危害：
   • SQL注入：尝试获取数据库名(database())、用户名(user())、表名、数据。使用UNION SELECT查询系统表（如information_schema）是经典手法。注意：绝对不要执行DROP TABLE,DELETE等破坏性语句！你的目的是证明漏洞存在，而非造成实际损害。
   • 文件上传：不仅要上传webshell，更要证明能解析执行。同时，要测试绕过黑名单、白名单、内容检查等各种防护机制的可能性。
   • 信息泄露：泄露的是普通数据，还是敏感的用户个人信息、后台凭证、源代码、配置文件？
3. 影响范围评估：
   • 横向影响：这个漏洞点是否存在于网站的其他功能模块？使用爬虫工具（如Burp Spider或gospider）配合主动扫描，寻找同类参数。
   • 纵向影响：是否可以通过此漏洞点，结合其他低危漏洞，形成更具威胁的攻击链（例如，信息泄露+弱口令导致后台沦陷）？在报告中可以提及这种可能性，但主要证明当前漏洞的直接危害。
4. 证据固化：对每一步操作进行截图或录屏。截图要包含浏览器地址栏、请求响应内容。关键请求和响应，建议直接粘贴原始数据到报告里。使用curl或Burp的Copy as curl command功能，可以生成完美的可复现命令。

实操心得：验证时，我习惯单独创建一个文档，像写实验记录一样，按时间顺序记录每一个操作、每一次请求和响应、每一个猜想和验证结果。这个记录文档最后会直接成为报告草稿的核心部分，确保逻辑连贯，无一遗漏。

3.2 报告结构与逐项精解

CNVD有官方模板，但模板是骨架，我们需要填充血肉。以下是我根据经验优化的一个详细结构：

1. 漏洞标题

• 要求：清晰、准确、包含关键要素。
• 格式建议：[厂商/产品名]存在[漏洞类型]漏洞（可简述危害）
• 坏例子：“某网站存在漏洞”、“发现一个SQL注入”。
• 好例子：“XX市政务服务平台统一登录模块存在SQL注入漏洞，可导致大量公民个人信息泄露”。
• 为什么：审核人员第一眼就看到漏洞的主体和核心问题，便于分类和初步评估。

2. 漏洞厂商/所属单位

• 要求：尽可能准确。如果是网站，填写其主办单位（可通过工信部ICP备案查询）。如果是产品，填写开发公司。
• 技巧：使用whois查询域名注册信息，结合网站“关于我们”、“备案信息”等页面综合判断。如果实在无法确定，可写“未知”，但会大大降低处置性。

3. 漏洞类型

• 要求：从CNVD给定的分类中选择最准确的一项。如“SQL注入”、“跨站脚本”、“权限绕过”、“信息泄露”、“命令执行”等。
• 注意：不要自己发明类型。如果感觉介于两者之间，选择危害更大的那个，并在描述中说明。

4. 漏洞等级

• 要求：根据CVSS标准或自己的经验进行初步评估（高、中、低）。CNVD最终会自己定级，但你给出的评估能体现你对漏洞的理解。
• 建议：保守一点。如果一个漏洞需要复杂的前置条件（如已登录后台、需要特定角色），即使能getshell，也可能只评为“中”。将评估理由在描述中简要说明。

5. 漏洞描述（核心部分）

• 结构：采用“总-分-总”结构。
  • 总述：一两句话概括漏洞是什么、在哪里、能造成什么影响。
  • 分述（技术细节）：
    • 漏洞位置：提供完整的URL。如果是POST请求，说明接口地址。
    • 触发参数：明确指出是哪个参数存在漏洞（如id,keyword）。
    • 请求详情：粘贴原始的HTTP请求数据包。这是最重要的证据！包括Method, Path, Headers, Body。可以使用Burp Suite的Copy as curl command，然后稍作整理（如脱敏自己的Token）。
    • 漏洞证明：展示漏洞触发的请求和异常响应。对于SQL注入，展示导致数据库报错的payload和响应；对于文件上传，展示上传成功和访问webshell的截图及响应；对于信息泄露，展示直接访问敏感文件或接口返回敏感数据的截图。
    • 利用过程：如果进行了进一步利用（如拖库），按步骤描述并附上证据。
  • 总结：再次强调漏洞的危害，并可简要说明修复建议（如参数过滤、使用预编译语句等）。

6. 漏洞证明（配合描述）

• 要求：将“漏洞描述”中的关键证据，以图片形式清晰呈现。图片上可以添加文字箭头标注重点。
• 技巧：一张图说明一个问题。例如：图1-存在漏洞的请求界面；图2-携带恶意payload的请求包；图3-数据库报错/命令执行成功的响应包；图4-获取到的敏感数据。
• 注意：所有截图必须完整，包含浏览器地址栏、请求响应内容。关键信息（如获取的真实敏感数据）需进行打码处理，但打码不能影响对漏洞事实的判断。

7. 修复方案

• 要求：给出具体、可操作的修复建议。
• 不要写：“加强过滤”、“提高安全意识”。
• 要写：
  • SQL注入：“建议对所有用户输入使用参数化查询（Prepared Statements）或使用ORM框架提供的方法，避免直接拼接SQL字符串。”
  • XSS：“建议对输出到HTML页面的用户数据，根据上下文使用HTML实体编码（如<转义为<）或合适的过滤库。”
  • 文件上传：“建议采用白名单机制校验文件扩展名和MIME类型；将上传文件存储在Web根目录之外；对图片文件进行重采样处理以破坏可能嵌入的恶意代码。”
• 价值：体现你的专业性，也能帮助厂商快速定位问题根源。

4. 真实驳回案例深度剖析

下面我们分析几个典型的驳回案例，看看问题出在哪里，以及如何修改。

4.1 案例一：因“信息不全”被驳回

• 驳回理由：“提交的漏洞信息不完整，无法进行验证。”
• 原报告问题：
  • 标题：“某教育平台存在漏洞”。
  • 描述：“在登录页面发现SQL注入，可以爆数据库。”
  • 证明：只有一张登录页面的截图，和一个写着1‘ and ‘1’=‘1的输入框。
• 问题根因：
  1. 主体缺失：“某教育平台”无法定位具体厂商。
  2. 位置模糊：“登录页面”是哪个具体的URL？是登录接口(/login)还是找回密码接口(/reset)?
  3. 证据链断裂：没有提供完整的HTTP请求包。审核人员不知道是哪个参数（username? password? captcha?）、以何种方式（GET/POST）提交的。那个payload截图，可能只是前端的输入框，根本没有发送到服务器。
  4. 危害未证明：“可以爆数据库”是声称，但没有提供任何爆出数据的证据（如union select出数据库版本、用户名的响应截图）。
• 修改方案：
  1. 明确主体：通过ICP备案查询，将标题改为“XX省教育资源公共服务平台存在SQL注入漏洞”。
  2. 精确定位：在描述中写明完整漏洞URL：https://xxx.edu.cn/api/user/login。
  3. 提供完整证据：
     • 提供原始的POST请求包（从Burp Suite复制），明确漏洞参数是loginName。

     POST /api/user/login HTTP/1.1 Host: xxx.edu.cn Content-Type: application/x-www-form-urlencoded ... loginName=admin&password=123456

     • 提供注入payload的请求包和数据库报错的响应包。

     POST /api/user/login HTTP/1.1 Host: xxx.edu.cn Content-Type: application/x-www-form-urlencoded ... loginName=admin' AND SLEEP(5)-- &password=123456

     • 提供利用union select获取数据库信息的请求与响应截图，证明危害。
  4. 结构化描述：按“总-分-总”结构重写描述，逻辑清晰。

4.2 案例二：因“无法复现”被驳回

• 驳回理由：“根据提供的信息，无法复现所述漏洞。”
• 原报告问题：
  • 报告了一个后台系统的“弱口令”漏洞，并给出了账号admin和密码admin123。
  • 提供了登录成功的截图。
• 问题根因：
  1. 环境特异性：这个弱口令可能是测试环境、本地搭建的仿站，或者是一个早已被修复但测试者本地浏览器缓存了旧会话的情况。审核人员访问公网正式系统时，密码已修改或账号不存在。
  2. 证据时效性：截图没有显示当前日期时间，无法证明漏洞在提交时依然存在。
  3. 缺乏旁证：弱口令漏洞有时需要结合其他信息（如该密码在GitHub泄露的代码中被发现）来佐证其普遍性，但报告未提供。
• 修改方案：
  1. 确认环境：提交前，使用无痕浏览器模式或不同的网络环境（如手机4G网络）重新测试，确保漏洞在公网可稳定访问。
  2. 强化证据：
     • 录屏代替截图，展示从打开浏览器、输入网址、输入弱口令到登录成功的完整过程。
     • 在录屏中，清晰展示浏览器地址栏的公网域名，以及系统时间。
     • 在登录后，访问几个只有登录后才能看到的功能页面（如用户列表、系统设置），以证明非缓存登录。
  3. 补充说明：如果该弱口令是默认口令或通过信息搜集获得，应在描述中说明来源（例如：“该CMS系统官方文档显示默认管理员账号密码为admin/admin123”），增加可信度。

4.3 案例三：因“漏洞已公开/已知”被驳回

• 驳回理由：“该漏洞为已公开漏洞。”
• 原报告问题：
  • 提交了一个针对某知名开源框架（如ThinkPHP, Struts2）特定版本的RCE漏洞。
  • 使用了互联网上公开的EXP工具一键利用成功。
• 问题根因：
  1. 缺乏原创性：CNVD旨在收录和处置新发现或未被广泛知晓的漏洞。对于已经发布CVE编号、安全公告遍地的Nday漏洞，除非你能证明其在目标系统上未被修复且影响重大，否则平台收录价值不高。
  2. 未做修复验证：没有检查目标系统使用的组件版本是否在受影响范围内，也没有验证补丁是否已部署。
• 修改方案：
  1. 前置调研：提交前，先搜索该漏洞的CVE编号、公开时间、影响版本。如果漏洞已公开超过3-6个月，且目标系统是重要单位，可以尝试提交，但侧重点要变。
  2. 转变报告重点：
     • 标题强调：“XX市智慧医院系统未修复已知Apache Struts2 S2-061漏洞，面临远程代码执行风险”。
     • 描述侧重：详细说明你是如何识别目标系统使用了存在漏洞的Struts2版本（如通过错误信息、特定URL特征）。提供证据证明该版本在受影响范围内。
     • 证明危害：虽然利用的是公开EXP，但你的报告重点应放在“证明该漏洞在此具体目标上依然可利用”以及“评估该目标的数据重要性（如医疗数据）”。
     • 强调紧迫性：在修复方案中，明确指出官方补丁链接，并说明未修复的风险。这样的报告，价值在于推动一个具体的重要单位去修复一个已知但被忽视的高危漏洞，CNVD可能会收录并协调处置。

5. 提交前终极检查清单与后续跟进

报告写好了，别急着点提交。按照这个清单逐项核对，能避免90%的格式性问题。

• [ ]完整性检查：
  • 标题是否清晰包含厂商和漏洞类型？
  • 厂商信息是否经过核实并准确填写？
  • 漏洞描述是否采用了“总-分-总”结构？
  • 是否提供了完整的、原始的HTTP请求数据包（关键！）？
  • 是否对每一步操作都提供了清晰的截图或录屏证据？
  • 修复建议是否具体、可操作？
• [ ]准确性检查：
  • 所有URL、参数名是否拼写正确？
  • 截图中的关键信息（如IP、敏感数据）是否已妥善打码？
  • 漏洞等级自评是否合理？
  • 是否在无痕窗口/新环境复现过，确保漏洞当前有效？
• [ ]合规性检查：
  • 报告内容是否仅限于证明漏洞存在，未包含任何破坏性操作（如删库、删文件）的描述或证据？
  • 是否未对目标系统进行超出验证必要范围的探测和攻击？
  • 获取的敏感样本数据是否已在报告中打码？

提交后，耐心等待即可。CNVD的处理周期从几天到几周不等，取决于漏洞严重性和当前提交量。如果被驳回，仔细阅读驳回理由，它是指引你修改报告的最重要线索。不要灰心，根据驳回理由针对性补充信息或修正问题后再次提交。每一次驳回和修改，都是对你技术表达和漏洞理解能力的提升。

最后，保持一颗平常心。提交CNVD是白帽子履行社会责任、提升技术能力的一种方式，但不是唯一方式。通过这个过程，锻炼自己严谨的技术验证能力、清晰的逻辑表达能力和换位思考的沟通能力，这些才是比一张收录证书更宝贵的财富。