在这场核弹级漏洞的全球响应中，谁对协同补救工作的帮助最大呢？答案是两个推特标签： #log4j 和 #log4shell。

虽然Apache软件基金会的Log4j开发者和安全团队做出了不错的努力，但像其它传统的Apache方式一样，开发者和安全团队更新了代码，给了CVE序号，发布到网站上，并把拷贝以邮件发给Apache www-announce和oss-security。这就完了，之后Apache对此事件没有慎重的跟踪和回复，把后果留给了全球社区承担。

Apache软件基金会以这种方式运作的原因很简单：Apache软件基金会在2019年的预算是2.26百万美元，我怀疑这个数字在最近两年没有多少增长。换句话说，作为现代数字技术世界基石的软件基金会的运营费用比一些大公司的咖啡饮料预算还少。Apache软件基金会每年处理大约140-150个有CVE ID的漏洞，根本不可能把大量预算用于安全（基本上100%由志愿者负责）。

来源: https://www.apache.org/

我们说CVE-2021-44228的发布像一颗核弹爆炸并不夸张。在推特上，12月9日-10日关于CVE-2021-44228的帖子数以千计，阅读这些帖子是烦人的事，最终我在按住滚动键几分钟后放弃了浏览。但12月9日早晨有这么一条推特消息：

来源：https://twitter.com/sirifu4k1/status/1468951859381...

这条推特虽然缺乏关键的上下文，但包含的信息足以用来实现对漏洞的利用。

不过，除非你搜索中文关键词阅读中文推特消息或阅读每个Github链接，否则你根本看不到事情的严重性。但任何人点击上述链接并阅读issue #608，就可以迅速意识到事情的糟糕程度（也许不是这样，反正Appache软件基金会没把这条信息当回事）。晚上，我们第一次看到了LunaSec 的消息。

来源：https://twitter.com/_r_netsec/status/1469120458083...

除了一些旧消息外，我们意识到Minecraft社区早在数天之前就遭受到了这个漏洞的利用。

临时补救方法也被提及（这意味着利用的细节已经披露），事件发生之前在一个聊天服务器上游戏迷们一直讨论对这个漏洞的利用：

我认为好消息是这次的利用似乎没有像“太阳风(Soloarwind)”那样普及。上述消息出来时都已过时，log4j项目在被公开前就已获得上报，只是发现者不清楚这是安全问题还是非安全问题（事实上，我不得不说这是最近十年来最严重的漏洞）：

来源：https://github.com/apache/logging-log4j2/pull/608

安全问题的通报渠道已经发生了变化，开源社区更是如此。我在20年前用的邮箱目录oss-security, full-disclosure, bugtrag 等都已消亡或不再活跃（只有一些厂商推送信息而没有真正的讨论），对这次的漏洞和之前类似的漏洞（同样Apache的CVE-2021-41773 和 CVE-2021-42013），全球信息安全与信息技术社区的主要交流渠道是：

1.Twitter (hashtags)

2.GitHub (for scanners, exploit code, workarounds, etc.) advertised via twitter

3.Reddit (specifically r/netsec and r/sysadmin)

4.HackerNew

CVE 漏洞数据库的条目除了最初的通知外（实际上已经晚了）基本不起什么作用，并且缺乏临时补救方法（workarounds）数据（事实上，漏洞数据库中曾有一条但被悄悄移除，但几天之后又重新出现），缺乏热补丁，缺乏扫描工具和检测工具，除了几个厂商建议链接外缺乏能采取行动的任何东西。CVE-2021-44228恰好包含了一条关于我对于本议题的推特消息链接：https://www.cve.org/CVERecord?id=CVE-2021-44228

这条推特消息谈及全球安全数据库 GlobalSecurityDatabase 条目 (GSD-2021-1002352) ，其中包括所有细节:

来源：https://twitter.com/kurtseifried/status/1469345530...

所以我们要做什么？不能仅仅让运维团队监视你使用的所有聊天、推特、Github、Reddit、Hackernews等软件，事实已经证明全职安全团队及各个公司都不可能持续地这样做。获取CVE数据源或商业威胁情报源仅仅是一个好的开端，但你会看到这种方式很慢并缺乏关键信息（比如AWS建议用户使用的热补丁）。

基本上，问题存在的原因是我们有众多的供应商而且要面对众多的客户企业，并使用不同的沟通渠道（因此你必须针对很多不同的渠道监控不同的网站）。如果存在一个系统既能收集所有的数据，又能作为一个中心发布数据并且可以通过该系统阅读数据会怎么样呢？CVE数据库本来是想这样做的，但它停滞不前，数据的数量（每年1万6-1万8条）及数据的更新方面都有问题，CVE-2021-44228曾在48小时内没有任何更新，描述没有改变，受影响的产品没有提及（不论是文字还是机器码）。这次危机中更有趣的是存在多个CVE-2021-44228漏洞产品/服务清单和临时补丁，这些信息公布在不同的网站和GitHub，赢家只有那些及时接受社区反馈并迅速作出反应的发布者。例如，比较美国CISA list （更新很慢）与荷兰NCSC-NL。

CISA repo有6个完成的和13个未完成的请求，而NCSC-NL则有317个完成的和29个未完成的，随着时间推移，CISA做了更多工作，与此同时荷兰又增加了更多类的数据（如入侵指标，缓解，渗透工具，扫描工具等）。

我认为这是推特#log4j和#log4shell成为赢家的原因，你不能阻止大家参与。如果提供的内容比较好，人们会点击喜欢或转发，这样会引起更多关注（比如长长的回复，通过一小段推特消息吸引最多的眼球）。相比而言，CVE等传统的系统要求所有的信息都必须在一个地方提交、审阅和批准（周末还不工作）。人们想获取及时的安全危机信息要去哪里就不言而喻了。

但这样下去不是办法，我们把私有的威胁情报源建筑在推特、聊天服务、社区论坛之上。对所有的安全缺陷，这样做的数据量太大，信噪比太低，也没有足够的安全分析师处理“可能重要”的洪水般的信息。我们也试尝着与CVE合作（很高兴地告诉大家，CVE使用的JSON数据格式就是我发明的），并让他们把数据迁移到GitHub，可惜之后又停滞了。 事实上，MITRE建议移除GitHub数据，尽管他们已经用了4年之久但还仍称之为“CVE 自动化工作组Git试点”。

GSD全球安全数据库（Global Security Database）是云安全联盟的一个新项目，目的是解决当前漏洞识别空间中的差距问题。GSD与其它所有漏洞库的最大区别在于它允许社区协作，允许通过多个数据源整合数据，并为各种用户（技术人员、管理人员或媒体等）提供机读数据和人类可读数据。总之，社区为CVE-2021-44228做的所有努力，不论是分级分类、修补，或是编写扫描器等，都必须集中在一个可以找的到的地方，使任何人都可以贡献并帮助他人。

作者：Kurt Seifried, Chief Blockchain Officer, CSA