随着AI加速开发推动安全公告披露速度不断提升，单纯依赖单一跟踪源可能导致已知漏洞在部署环境中完全未被检测。
自托管AI Agent项目OpenClaw发布数周后便成为GitHub星标最多的代码库，吸引了大量开发者社区和研究人员关注。但没人预料到，其快速增长很快成为全球漏洞跟踪体系的意外压力测试。
安全公告爆发式增长
2月下旬，该项目开始以开源项目罕见的速度发布安全公告，迅速暴露出两大主流漏洞识别系统间的结构性割裂。在爆红的三周内，OpenClaw已发布200多份GitHub安全公告（GHSA）。该项目安全公告页面目前列出255项披露，多数涉及命令执行控制、授权检查、允许列表实施和插件边界问题。这些披露的速度远超传统CVE分配流程的处理能力，导致大量公告缺乏对应的CVE编号。
Socket.dev分析师指出，OpenClaw公告的快速积累直接暴露了漏洞披露领域长期存在的碎片化问题，这早在AI驱动开发重塑开源世界之前就已存在。单个项目如此大规模的披露，使得GHSA与CVE跟踪体系间的鸿沟比以往更加明显。
CVE分配机制遭遇挑战
当VulnCheck在CVE项目工作组提交针对170个缺少CVE编号的OpenClaw公告发起"DIBS"请求时，事态进一步升级。DIBS是CVE编号机构间使用的非正式协调信号，表明某组织拟评估漏洞并可能分配CVE编号。VulnCheck研究副总裁Caitlin Condon表示，此举旨在确保漏洞被武器化前获得CVE覆盖。
但MITRE的TL-Root予以反驳，指出DIBS设计初衷是标记符合特定标准的单个漏洞，而非将整个项目批量归类。该请求最终被关闭。
OpenClaw曾用名Clawdbot和Moltbot的命名历史，进一步加剧了其在多数数据库和公告系统中的索引复杂性。代表用户跨外部服务执行命令的自动化平台往往暴露大量攻击面，当研究人员对此类工具展开系统性审查时，披露数量可能快速增长。
GHSA与CVE体系的分化加剧
GitHub安全公告为维护者提供了更简捷的路径：研究人员报告问题后，维护者可直接发布，无需外部协调。而申请CVE编号需通过CVE编号机构、格式化元数据并等待分配，因此许多项目现在默认仅使用GHSA，完全跳过CVE申请。
这对安全团队构成实际盲区，因为包括漏洞扫描器、补丁管理系统、SBOM工具和合规框架在内的大多数企业工具都围绕CVE标识构建，这意味着仅以GHSA披露的漏洞对这些系统完全不可见。
加州大学欧文分校2024年调查发现，GitHub公告数据库存有超过21.3万条未审核公告，每日审核量不足6条，按此速度需95年才能完成清理。巴西弗鲁米嫩塞联邦大学2026年研究分析逾28.8万条GHSA后发现，仅8%经过GitHub正式审核，未审核公告不会触发Dependabot警报，下游项目可能永远不知其依赖存在漏洞包。
应对建议
RogoLabs安全工程师Jerry Gamblin构建了专用跟踪器，每小时交叉比对GitHub公告数据库与CVE项目的cvelistV5代码库中的OpenClaw公告，包含修复版本数据以避免漏洞状态混淆。Anchore安全副总裁Josh Bressers指出，许多组织仍会忽视没有CVE编号的漏洞，这种割裂构成运营风险。
依赖AI驱动和自动化平台的安全团队在审查风险暴露时，应交叉比对GHSA和CVE数据库。随着AI加速开发使公告披露速度持续提升，仅依赖单一跟踪源可能导致已知漏洞在部署环境中完全未被检测。
