KaiwuDB PSIRT
KaiwuDB PSIRT(Product Security Incident Response Team)是 KaiwuDB 产品安全事件响应团队,负责接收、处理和披露 KaiwuDB 数据库产品及解决方案相关的安全漏洞,是 KaiwuDB 披露漏洞信息的官方出口。
KaiwuDB PSIRT 的职责主要包括:
- - 制定公司安全事件管理策略及处理方案;
- - 分析系统软件提供商和专业安全厂商发布的漏洞及补丁;
- - 响应和处理客户、安全组织或个人公布的安全事件。
KaiwuDB 产品安全事件响应团队鼓励全球安全从业人员、业界组织主动提交 KaiwuDB 产品存在的安全漏洞。KaiwuDB PSIRT 遵循 ISO/IEC 30111(漏洞处理流程标准)和 ISO/IEC 29147(漏洞披露标准),结合 KaiwuDB 多模时序数据库的产品特性进行定制,确保漏洞从接收、验证、修复到披露的整个流程规范、透明、高效。
邮箱联系方式:security@kaiwudb.org.cn
1. 如何提交漏洞
KaiwuDB 产品安全事件响应团队鼓励全球安全从业人员、业界组织主动提交您发现的 KaiwuDB 产品的安全漏洞,帮助我们一起持续提升和完善 KaiwuDB 产品及服务的安全性。如您有发现我们的安全漏洞,欢迎您及时提交。
1.1提交途径
- -专用安全邮箱:security@kaiwudb.org.cn
- -客户技术支持:通过您的专属技术支持渠道提交,标注“安全漏洞”字样。
1.2响应时间承诺
我们将对收到的安全漏洞第一时间回复,通常情况下:
- -1 个工作日内收到邮件回复确认。
- -7 个工作日内收到漏洞验证结论。
- -漏洞处理过程中我们也会知会您最新处理进展。
1.3提交指引
为提高处理效率,请您遵循如下指引提供漏洞报告:
- -使用报告模板完整、准确填写漏洞信息。
- -邮件主题格式:【产品名称-漏洞简述】,例如:【KaiwuDB-SQL注入漏洞】。
- -确保提交的报告不涉及知识产权问题,不包含法律或宗教所禁止的内容。
1.4报告要求
为了便于验证和定位漏洞,漏洞报告宜包含该漏洞的详细说明和完整的验证代码。
报告描述要求
- -漏洞描述:描述问题类型(比如是登录绕过)、可能造成的影响。
- -影响对象:受影响的版本号,具体出问题的功能模块。
- -复现步骤:用文字或截图,按步骤说明运行环境,如何操作能重现问题。如果方便,附上视频会更清晰。
关于验证代码(POC)
如果您有可运行的验证代码,请一并提供,并注明编译环境(如用什么编译器、什么系统)。
1.5保密约定
在 KaiwuDB 产品安全事件响应团队主动公开之前,希望您承担对此漏洞信息保密的义务。同时,KaiwuDB 产品安全事件响应团队承诺在漏洞修复和发布安全公告之前,为客户保密漏洞相关的敏感信息。
非安全漏洞相关问题请您咨询全球技术支持。
2. PSIRT 核心流程
KaiwuDB PSIRT 流程分为六个阶段:漏洞接收 → 漏洞分析与分级 → 漏洞修复 → 漏洞验证 → 漏洞披露 → 漏洞跟踪与反馈。

第一阶段:漏洞接收
目标: 建立统一的漏洞接收渠道,确保所有安全漏洞报告被及时登记和确认。
接收渠道
- -专用安全邮箱:security@kaiwudb.org.cn
- -公开漏洞库监测(CVE/CNVD/CNNVD/NVD)。
- -内部安全测试与代码审计发现。
- -第三方安全机构通报。
接收处理步骤
- -登记建档:收到漏洞报告后 24 小时内,分配唯一漏洞编号,记录报告来源、时间、产品版本、漏洞描述等信息。
- -回执确认:向报告者发送确认回执,告知漏洞已受理及后续流程,建立沟通渠道。
- -信息补充:若报告信息不足(如缺少复现步骤、POC),主动与报告者沟通获取补充信息。
- -初筛过滤:排除非安全问题、重复漏洞、用户配置错误等不属于产品安全漏洞的报告。
第二阶段:漏洞分析与分级
目标: 确认漏洞真实性,评估漏洞影响范围与严重程度,制定修复优先级。
分析内容
- -漏洞验证:在测试环境中复现漏洞,确认漏洞真实存在。
- -根因分析:定位漏洞产生的根本原因(代码缺陷、设计缺陷、配置问题等)。
- -影响范围评估:确定受影响的产品版本、组件、部署模式。
- -严重程度评分:使用 CVSS 评分标准进行评分。
- -利用难度评估:评估漏洞被利用的技术门槛和前置条件。
- -业务影响分析:评估漏洞被利用后对客户业务的实际影响。
第三阶段:漏洞修复
目标: 开发安全补丁或提供缓解措施,从根本上消除安全漏洞。
修复策略
- -制定修复方案:由内核研发团队制定代码修复方案,PSIRT 审核方案的安全性和完整性。
- -紧急缓解措施:对于高危漏洞,在正式补丁发布前,先提供临时缓解方案(如配置变更、访问控制策略、功能关闭等)。
- -补丁开发:研发团队按修复方案进行代码修改,遵循安全编码规范。
- -多版本适配:针对所有受影响的支持版本分别开发补丁。
- -修复自检:开发完成后进行单元测试和漏洞复现验证。
第四阶段:漏洞验证
目标: 全面验证补丁的有效性、兼容性和安全性,确保修复不引入新问题。
第五阶段:漏洞披露
目标: 在补丁就绪后,通过适当渠道向受影响客户和公众披露漏洞信息,提供修复指引。
披露原则
- -负责任披露:在补丁或缓解措施可用后再公开漏洞细节。
- -分级披露:高危漏洞优先通知签约客户,通用漏洞统一发布安全公告。
- -信息充分:公告包含漏洞描述、影响版本、风险评估、修复方案、缓解措施。
- -漏洞来源:漏洞从邮件提交,或公开信息收集。
披露渠道
- -客户优先通知:对签约客户,在公告发布前 48 小时通过技术支持渠道提前通知。
- -官方安全公告:在官网 安全公告 页面发布正式安全通告。
第六阶段:漏洞跟踪与反馈
目标: 监控补丁部署情况,收集客户反馈,持续改进安全流程。
跟踪内容
- -补丁部署监控:跟踪客户补丁升级进度,识别未及时修复的高风险客户。
- -问题反馈收集:收集客户在补丁应用过程中遇到的问题。
- -漏洞利用监测:监测公开渠道是否出现漏洞利用代码或在野利用情报。
- -补丁更新:若发现补丁存在缺陷,及时发布修订版补丁。
- -根因复盘:高危漏洞修复完成后,组织复盘会议,分析漏洞产生根因,制定预防措施。
- -流程改进:将复盘结论转化为安全编码规范、测试用例、自动化检测规则。
3. 漏洞分级标准
采用 CVSS 评分体系,结合数据库业务影响特性进行分级。
4. 附录
4.1术语表
| 术语 | 全称 | 说明 |
|---|---|---|
| PSIRT | Product Security Incident Response Team | 产品安全事件响应团队 |
| CVE | Common Vulnerabilities and Exposures | 通用漏洞披露编号 |
| CVSS | Common Vulnerability Scoring System | 通用漏洞评分系统 |
| CVD | Coordinated Vulnerability Disclosure | 协同漏洞披露 |
| POC | Proof of Concept | 概念验证,用于验证漏洞存在的代码或程序 |
| Exploit | — | 漏洞利用程序,可实际利用漏洞执行攻击的代码或工具 |
4.2参考标准与框架
- -ISO/IEC 30111:2019 — 信息安全漏洞处理流程
- -ISO/IEC 29147:2018 — 漏洞披露
- -FIRST CVD Guidelines — 协同漏洞披露指南
- -《网络产品安全漏洞管理规定》— 工信部、网信办、公安部
- -CVSS 评分标准
4.3版本历史
| 版本 | 日期 | 变更说明 |
|---|---|---|
| V1.0 | 2026-08-10 | 初始版本发布 |