企业官网建设流程全解析

1. 项目概述：从SRC到CNVD的实战路径

如果你在安全圈混过一阵子，或者刚入门漏洞挖掘，肯定对“SRC”和“CNVD”这两个词不陌生。SRC，也就是安全应急响应中心，通常是企业自己设立的，用来接收白帽子提交的自家产品漏洞，然后发奖金、发证书。而CNVD，全称国家信息安全漏洞共享平台，它的层级和性质就完全不同了。简单来说，你可以把SRC看作是“企业级”的漏洞收集和处理窗口，而CNVD则是“国家级”的漏洞信息汇集、分析和发布的枢纽。很多刚入行的朋友会有一个误区，觉得挖到了漏洞，往CNVD一提交就完事了，或者反过来，觉得CNVD的流程太“官方”、太复杂，不如刷SRC来得直接痛快。其实，这两者并非互斥，而是一种相辅相成、可以打“组合拳”的关系。

我个人的体会是，一个高质量、影响范围广的漏洞，其价值完全可以通过“SRC+CNVD”的双轨路径得到最大化。比如，你发现了一个某流行开源框架的远程代码执行漏洞，这个框架被成千上万家单位使用。你除了可以向该框架所属公司的SRC（如果有的话）报告，更应该向CNVD提交。因为CNVD的通报机制能更快速、更权威地触达所有使用该框架的政企单位，推动他们进行修复，从而真正消除安全隐患，这其中的社会价值远非单个厂商的奖金可比。同时，一份被CNVD收录的漏洞证明，在求职、晋升、评职称时，其含金量也是业界广泛认可的。所以，搞清楚CNVD的漏洞提交流程，绝不是为了“刷证书”，而是每一位负责任的安全研究者都应该掌握的、将技术能力转化为实际安全价值的关键技能。接下来，我就结合自己多次提交的经验，把CNVD漏洞提交这件事，从前期准备到报告撰写，再到提交后的各种状态，给你彻底讲明白。

2. CNVD漏洞提交全流程拆解与核心思路

2.1 流程全景与阶段划分

CNVD的漏洞提交，远不止是在网站上填个表单那么简单。它是一个从漏洞验证、信息整理、报告撰写到持续跟踪的完整项目。我们可以把这个流程清晰地划分为四个主要阶段：前期准备与漏洞验证、报告撰写与信息整理、平台提交与材料上传、以及提交后状态跟踪与沟通。每个阶段都有其核心目标和容易踩坑的地方。

整个流程的核心思路是：严谨、客观、可复现。CNVD作为国家级平台，对漏洞报告的质量要求非常高。你的报告必须像一个严谨的科学实验记录，让审核人员能够根据你的描述，独立、完整地复现出漏洞。任何模糊、夸张或无法验证的描述，都可能导致报告被驳回或降级处理。因此，你的所有工作都应围绕“如何让一个完全陌生的人，能照着你的步骤把漏洞原样挖出来”这个目标展开。

2.2 前期准备：比挖掘更重要的环节

很多人挖到漏洞后兴奋不已，立刻就去提交，往往在第一步就卡住了。前期准备不足，是导致提交失败最常见的原因。

2.2.1 漏洞的深度验证与影响面评估

首先，你需要对漏洞本身进行二次甚至三次验证。这不仅仅是确认漏洞存在，更要明确：

1. 漏洞触发条件：是否需要登录？需要什么权限？是否依赖特定的配置或环境？
2. 漏洞稳定复现率：是不是每次都能成功？有没有什么随机因素？我建议至少在不同时间、清理浏览器缓存后，复现3次以上。
3. 漏洞的真实危害：这个漏洞到底能做什么？是信息泄露（能泄露什么数据？）、权限提升（能从什么角色提升到什么角色？）、还是代码执行（能执行任意命令吗？）。切忌夸大危害。一个反射型XSS硬说成能“完全控制服务器”，只会让审核人员觉得你不专业。
4. 影响范围评估：这是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 漏洞描述（重中之重）这是报告的核心，建议分为以下几个段落来写：

1. 背景介绍：用一两句话说明受影响的产品/组件是什么，其主要用途是什么。
2. 漏洞详情：清晰描述漏洞存在的功能点或接口。例如：“在XX系统的用户管理模块，编辑用户信息时，对user_id参数未进行有效过滤。”
3. 漏洞原理：简要说明漏洞的技术原理。例如：“该参数直接拼接进入SQL查询语句，导致攻击者可以构造恶意输入，改变原SQL语句的逻辑，从而执行任意数据库操作。”
4. 漏洞证明：这部分要极其详细。不要只说“可以弹窗”。你需要提供：
   • 请求详情：提供完整的HTTP请求（Method, URL, Headers, Body）。对于GET请求，给出完整URL；对于POST请求，给出请求体。
   • 恶意载荷：你具体输入的、触发漏洞的Payload是什么。
   • 响应详情：服务器返回的响应是什么（关键部分即可，如包含数据库错误信息、执行结果等）。
   • 复现步骤：用编号列表的形式，一步一步写清楚从登录（如果需要）到触发漏洞的完整操作。例如：“1. 访问http://target.com/login使用账号admin/123456登录。2. 进入‘用户管理’->‘编辑用户’。3. 在用户ID输入框中，将值改为1' AND '1'='1。4. 提交后，观察页面返回结果...”
5. 影响版本：明确写出“经测试，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. 截图：将关键步骤的截图（登录界面、漏洞触发点、执行结果）按顺序编号，如图1-登录界面.png，图2-注入点.png。可以在图片上用画图工具添加箭头、方框等标注。
2. 数据包文件：将Burp Suite保存的请求/响应数据（推荐保存整个会话为.xml或单个请求为.req文件）作为附件。确保数据包中包含你的攻击Payload。
3. 录屏视频：如果漏洞触发过程复杂，录屏是最佳选择。视频应简短（建议1-3分钟），清晰展示从开始到漏洞触发的全过程。可以配上简单的文字说明或语音解说。输出为通用格式如MP4。
4. 漏洞利用代码：如果漏洞有公开的Exp或你编写了利用脚本，可以附上。但务必谨慎，确保代码不会对他人系统造成损害，最好只是证明性的概念代码（PoC）。

实操心得：写报告时，想象你的读者是一个技术不错但对该系统一无所知的安全工程师。你的描述能否让他搭建起一个类似的环境，然后完美复现漏洞？所有模棱两可的地方，都是被退回的隐患。我习惯在写完报告后，让自己“冷却”半天，再以审核者的视角重读一遍，往往能发现不少可以优化和明确的地方。

4. 平台提交实操与表单填写详解

准备好报告和材料后，就可以登录CNVD平台进行提交了。

4.1 访问与登录

通过搜索引擎找到“国家信息安全漏洞共享平台”官网。你需要注册一个账号。注册信息请如实填写，特别是邮箱和手机号，这将是后续官方与你联系的主要渠道。

4.2 漏洞提交表单逐项解析

登录后，找到“漏洞提交”或类似的入口。表单字段可能随时间微调，但核心内容不变。

1. 漏洞标题：将你之前拟好的标题粘贴进去。
2. 漏洞类型：从下拉菜单中准确选择。
3. CVE编号：如果该漏洞已有CVE编号（例如你在其他平台先提交了），可以填写。如果没有，留空即可，CNVD会自行分配CNVD-ID。
4. 涉及厂商：填写公司或组织全称。如果是开源项目，填写项目名。
5. 产品名称：填写具体的软件、硬件或系统名称。
6. 版本号：务必填写你验证过的、受影响的准确版本号。
7. 漏洞描述：将你在文档中精心撰写的“漏洞描述”部分完整粘贴进来。注意格式清晰，可以使用换行和列表。
8. 漏洞危害：粘贴“漏洞危害”部分。
9. 修复方案：粘贴“修复建议”部分。
10. 参考链接：可以附上产品官网、开源项目地址、或相关技术文章链接。
11. 附件上传：这是关键步骤。将你准备好的截图、数据包文件、视频等逐一上传。建议对附件进行简要命名说明，如“漏洞复现步骤截图.zip”、“Burp数据包.xml”、“漏洞复现录屏.mp4”。
12. 发现者信息：填写你的个人信息（平台账号关联的）。这里通常涉及漏洞归属。如果你是代表团队或公司提交，需要明确。个人提交则归属个人。
13. 公开程度：一般选择“申请CNVD编号，暂不公开”。待CNVD审核收录并协调厂商修复后，会根据情况公开细节。

4.3 提交后的确认与初次审核

点击提交后，你会收到一个提交成功的提示，并且通常会在“我的提交”或类似页面看到一个漏洞列表，其中包含你刚提交的记录，状态可能是“待审核”、“审核中”等。

这里有一个非常重要的点，也是很多新手困惑的地方：提交成功，不等于被收录。提交成功仅仅意味着你的报告已经进入CNVD的待处理队列。接下来会进入人工审核阶段。

5. 提交后状态跟踪、沟通与常见问题

提交只是开始，等待和沟通同样重要。

5.1 漏洞生命周期与状态解读

你的漏洞报告在CNVD平台通常会经历以下几个状态，理解这些状态的含义至关重要：

5.2 为什么提交成功后查不到编号？

这是被问得最多的问题。原因通常有以下几种：

1. 仍在审核队列：从提交到审核完成，可能需要数天到数周时间，取决于当前漏洞提交量和漏洞的复杂性。请耐心等待。
2. 审核未通过：漏洞因各种原因未被收录，状态可能是“已驳回”。你需要登录平台查看具体状态和驳回意见。
3. 信息填写有误：例如邮箱填错，导致收不到通知。请确保注册邮箱正确，并检查垃圾邮件箱。
4. 漏洞重复：你发现的漏洞已经被其他人提交并通过审核。CNVD对于重复漏洞，通常只会收录最早提交且信息完整的报告。

排查建议：首先登录CNVD平台，在个人中心查看提交记录的状态。如果状态是“已收录”但没收到邮件，可以检查平台页面是否显示了CNVD-ID。如果状态长时间（如超过一个月）卡在“审核中”，可以尝试通过平台提供的官方联系邮箱（非紧急情况下）礼貌地咨询进度，附上你的提交编号。

5.3 与审核人员的有效沟通

在审核过程中，审核人员可能会通过邮件与你联系，要求补充信息或澄清某些技术细节。这时，你的沟通方式直接影响效率。

• 及时响应：尽快回复邮件。
• 清晰具体：针对对方的问题，提供额外的截图、数据包或更详细的复现步骤。避免使用“可能”、“大概”等模糊词汇。
• 保持礼貌和专业：沟通的目的是共同确认漏洞，推动问题解决。

5.4 从SRC到CNVD的联动策略

如前所述，SRC和CNVD可以联动。一个理想的流程是：

1. 发现漏洞：在属于某企业SRC范围的资产上发现漏洞。
2. 优先提交SRC：首先按照该SRC的规则提交漏洞。这能确保你获得厂商的快速响应和可能的奖励。
3. 评估漏洞性质：如果该漏洞属于通用型组件漏洞（例如该企业使用的某个开源框架的漏洞），其影响范围远超该企业本身。
4. 提交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提交对你来说就不再是一个神秘的流程，而是一个将你的技术能力转化为公认成果的标准化出口。这条路没有捷径，唯有多挖、多写、多总结。