文章总结： 文档讲述了开源AI代理OpenClaw短时间内发布超200个GitHub安全通告但多数无CVE编号的事件，暴露了GHSA与CVE双轨体系的割裂。VulnCheck的批量DIBS请求被MITRE拒绝，引发社区对漏洞标识符必要性的讨论。数据显示GitHub安全通告数据库积压超21万条，企业工具对无CVE漏洞可见性差。专家认为应重新思考去中心化的漏洞跟踪方式，AI加速发展使现有体系面临更大挑战。 综合评分： 84 文章分类： 漏洞预警,安全建设,威胁情报,漏洞分析,安全大事件

OpenClaw发布海量安全通告，暴露GHSA与CVE体系之间的裂痕

幻泉之洲

2026年3月11日 14:15 北京

开源AI代理OpenClaw几周内发布了超过200个GitHub安全通告，但大多数没有CVE编号，这让整个漏洞生态系统的协调和可见性问题暴露无遗。

OpenClaw，这个几周内就从上线冲到GitHub星标榜首的自托管AI代理，在二月底成了CVE生态系统的意外“压力测试器”。在爆火的三周里，项目发布了超过200个GitHub安全通告，但其中只有一小部分获得了对应的CVE编号。

这件事是在漏洞情报公司VulnCheck的一次“占位”请求后引发关注的。他们在CVE项目研究员工作组里，为170个没有CVE编号的OpenClaw通告提了个“DIBS”请求。他们表示，几个客户和安全社区的成员都在问这些问题的CVE分配情况。

VulnCheck的研究副总裁Caitlin Condon说：“为了回应客户对这类问题的兴趣，我们正在研究围绕OpenClaw一系列漏洞开发能力的可能性，并且希望在它们被武器化之前能有CVE编号。”

DIBS争议与机制失效

“DIBS”是在CVE编号机构之间使用的一种非正式协调信号。当一个CNA对某个漏洞调用DIBS，意味着该组织打算评估这个问题并可能分配CVE编号。

VulnCheck这次是想把这种机制用在一大批OpenClaw通告上。他们列出了一个170个尚未获得CVE编号的通告清单。

MITRE的TL-Root反驳了这个请求，表示“DIBS是关于识别符合5.3.1标准的漏洞。从一个供应商那里收到很多GHSAs，并不意味着可以把DIBS重新用于给供应商分类，而不是给漏洞‘加标签’。”

这事儿后来被关闭了，VulnCheck也承认，大规模的DIBS请求可能确实不合适。不过单个通告的CVE分配，或许还能通过其他途径实现。

自动化平台的安全宿命

与此同时，OpenClaw作为一个可以在多重服务和环境中执行任务的平台，用户量增长飞快。它吸引了大批开发者，也被安全研究员盯上了。

仓库的安全通告页面现在列出了255条披露。很多都涉及命令执行控制、授权检查、白名单执行或插件边界的问题。

与外部服务交互、代表用户运行命令的自动化平台，天然就会暴露出大量安全攻击面。一旦研究员开始系统性审查，报告问题的数量就会激增。OpenClaw的通告潮，正好把近些年漏洞披露领域的一个明显转变置于聚光灯下——这个转变在生成式AI重塑开源生态之前就开始了。

GHSA与CVE的双轨困境

对维护者来说，GHSA几乎没有阻力。研究员报告，维护者发布，不需要外部协调。申请CVE则意味着要找CNA、整理元数据、然后等待。现在很多项目都默认只用GHSA，CVE以后再说，或者干脆不要了。

问题在于，大多数企业安全工具，比如漏洞扫描器、SBOM工具、补丁管理系统和合规框架，都是围绕CVE构建的。一个仅披露为GHSA的漏洞，对这些工具来说可能完全是“隐形”的。

这两套系统已经越来越明显地并行运作了。一些漏洞同时获得两个编号，另一些则只以GHSA形式出现。

通告数量与下游可见性之间的差距是巨大的。加州大学尔湾分校2024年的一项调查发现，截至当年4月，GitHub安全通告数据库里有超过21.3万个未审查的通告，而且每天审查的不到6个。按照这个速度，研究员估计得花95年才能清空队列。未审查的通告不会触发Dependabot警报，这意味着下游项目可能永远不会被告知它们依赖了有漏洞的包。

近期的学术研究也表明这种不平衡依然存在。巴西弗鲁米嫩塞联邦大学研究员在2026年牵头的一项研究分析了超过28.8万个GitHub安全通告。他们发现只有大约8%被GitHub审查过，其余的只是数据库里未被审查的记录。

OpenClaw的通告潮，只是这个系统能多快积累披露的一个例子，它也催生了独立的跟踪努力。

独立追踪者的解决方案

安全工程师Jerry Gamblin直接用OpenClaw建了个“OpenClaw CVE和安全通告追踪器”，用来监控项目在多来源的通告，包括GitHub安全通告数据库、仓库级别的通告和CVE项目的cvelistV5仓库。

追踪器每小时更新一次，并将GHSA记录与CVE发布状态进行核对。它还包括了仓库安全页面上列出、但尚未出现在GitHub安全通告数据库里的那些通告。

项目也追踪命名变迁。OpenClaw之前用过Clawdbot和Moltbot的名字，这会影响漏洞在不同数据库中的索引方式。

在收到研究员反馈后，追踪器现在还包含了修复版本的数据——因为单独看通告数量，容易被误解为全是未修补的漏洞。

一场关于“是否还需要CVE”的辩论

被拒的DIBS请求很快在整个安全社区引起了注意。

Anchore的安全副总裁Josh Bressers觉得，MITRE这次有点程序过头了，毕竟有人主动愿意做这个工作。

“这感觉是那种过分迂腐就很蠢的情况，”Bressers在LinkedIn上写道，“简而言之就是，OpenClaw有很多漏洞被GitHub跟踪着，但就是拿不到CVE编号。”

另一些人则质疑，当通告已经存在于公开可访问的数据库中时，CVE是否还有必要。

CIRCL安全研究团队负责人Alexandre Dulaunoy认为，漏洞跟踪越来越依赖多源信息，而非单一的中心化标识符。

“也许我们应该彻底重新思考这件事，”他说，“当你已经有了GHSAs，为什么还需要CVE编号？这些信息已经有记录、可访问了。我们应该停止单一中心化源头的思维方式，或许该忘掉这个层级化模型了。”

“GHSAs是很好且有价值的信息源，如果另一个权威机构说不是这样，这真的很重要吗？如果所有信息源都被视为同等重要，都值得考虑呢？”

GARR-CERT的负责人Leonardo Lanzi在讨论中也表达了类似观点。“再一次，这是为了避免我们这些‘不同时代的年轻人’几十年来都知道的单点故障问题。同样的情况应该适用于漏洞归档……尽管看起来大家对DNS的问题似乎也还没搞清楚。”

Bressers同意，依赖CVE之外的标识符可能是漏洞披露的长期方向，但他也指出，很多组织依然对没有CVE的漏洞不屑一顾。

“我发现更成熟的漏洞响应项目会经常使用非CVE的标识符，”他说，“但不幸的是，我认为目前CVE依然重要。我看到很多团体直接忽略任何不是CVE的东西。这是个恼人的现实。”

加速未来与更多“OpenClaw时刻”

LinkedIn上的这场简短交锋，反映了当前生态系统的分裂。开发社区越来越依赖GHSA或特定生态系统的通告，而很多企业安全工具依然优先认CVE。

OpenClaw披露潮让我们提前看到了，随着AI驱动的开发继续加速代码的创建，漏洞报告、标识符分配和安全工具的互动可能会变成什么样。这个动态不是OpenClaw带来的，但它短时间内产生的大量通告，让这种割裂变得更加显眼。

随着AI代理平台的普及，它们肯定会受到更多审视。这个领域的项目正在以没人能预料到的方式，将自动化、集成和可扩展性进行创造性组合。这种架构本身就产生了很多值得审查的边界。当研究员开始更仔细地检查这些系统时，像OpenClaw这样的漏洞披露潮可能会变得更常见。老实说，整个安全追踪的老旧体系，在AI造物的速度面前，已经有点跟不上了。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《OpenClaw发布海量安全通告，暴露GHSA与CVE体系之间的裂痕》