谁该为log4j的漏洞负责？

张国锋 译

SOFTWARE RESEARCH AND THE INDUSTRY

Research publications and comments on the software industry, open source, and inner source

Open Source Expanded (IEEE Computer Column) – Software Research and the Industry (dirkriehle.com)

https://dirkriehle.com/2021/12/15/who-to-blame-for-the-log4j-vulnerability/

谁该为log4j的漏洞负责？

到目前为止，没有人。

不是那些快速而专业地做出反应的开源开发者，也不是那些在一两天内就处理好风险的公司。

然而，最终，我们将不得不责备（或抱怨）那些因为没有及时清除漏洞而受到危害的公司。

现在，为什么该公司不修复这个漏洞呢？因为他们根本就不知道漏洞的存在。这有点不可思议。因为他们至今还没有一个安全的开源组件清单。下面给大家举一个例子来说明这个问题。

下图显示了我的研究小组所开发的一个开源应用程序的开源组件。每个黑盒子都是一个开源组件，有的较大，有的很小，甚至小于log4j的大小。我们只对处于顶部的组件（绿色部分）进行编程。其他的都是别人的开源代码。我的员工还选择了黄色边界的开源组件来做其他的工作。使用黄色边界的组件，我们称之谓直接依赖。使用其它组件，我们称之谓间接依赖，即那些紫色边界的开源组件。下图总共大约有140个组件，而我们对其中一个进行编程。这也是多数公司的正常操作。

一个小项目的开源组件图

你看到那个蓝色边框的小盒子了吗？那就是发生安全事故的地方。在我们的例子中，它是slf4j-api组件，它隐藏了应用程序所使用的具体日志设施。在这张图中，我们甚至不能看到是否使用了log4j或logback或其他日志。因为，它被隐藏在一些配置参数中。

现代企业开发中引用了大量开源组件，其中绝大部分都是间接引用。有时，那怕是你正在使用的组件，在代码中也发现不了安全漏洞，因为它隐藏在配置参数中。开源组件很庞大，也很复杂，需要花精力去审核和监控。

公司是否需要审查和监控他们所使用的每一个开源组件？当然需要。要做到这一点肯定不容易，可喜的是相关工具已经有了很大的进步。公司或许更愿意将资源花在新功能开发上，而不是采用开源代码。但采用开源代码是最先进的生产协作方式，所有公司都没法回避。

如果真出了问题，应该责备的不是log4j的开发者，而是那些落后的公司。因为，他们没有安全的流程来解决这一问题。