log4j: Disaster or success story?
The dust is slowly settling around log4j. As a reminder: In December, a serious security vulnerability was discovered in this open-source software package. Under the name Log4Shell, this vulnerability allowed attackers to execute arbitrary software code on computers using log4j. As log4j is a widely used framework for logging application messages, the consequences were serious.
This article is not about how log4j works or what the economic damage is. Instead, it is about the question of why log4j was so successful in the first place and what the incident means for open source.
Why was log4j so successful?
The effects of Log4Shell were so enormous because so many companies used the framework. First of all, that is a compliment for Open Sourceand not the opposite. After all, widespread use means that the software had a high benefit (and an attractive price-performance ratio).
However, it is interesting to note that many companies did not even know that they were affected. This is because few companies use log4j directly. Most companies use open source software or open source components in their projects. These in turn use open components. Even a simple application is often deeply nested.
The following image shows the dependencies of software components. A simple application (green) uses 11 open source components (orange). Several levels deeper, log4j appears (blue).
To answer the initial question: log4j was successful in (Java) software development because it was the best logging framework for many (and had the best price-performance ratio). Due to the success of software components, it was then integrated into almost every major development. Users were often unaware of this.
Bug or feature?
The ironic thing about log4j is that the vulnerability is not even based on a bug. Wired magazine quotes Free Wortley, who describes the vulnerability not as a "bug" but as "a design error of catastrophic proportions" is labeled.
The fundamental problem with the design of log4j is the ability to load executable code. Furthermore, the attacker can transfer data to the logging system via many channels, for example chat messages or URLs.
Who writes the requirements?
Many open source projects often arise from the personal needs of a developer. The requirements are written down accordingly, if they are written down at all. That's not really a bad thing. Requirements and documentation follow the moment a community develops. When it comes to prioritizing the implementation of requirements, everyone can pitch in. However, employees often tackle the tasks that they enjoy. Few developers voluntarily take on the important but boring tasks.
Who pays the developers?
In order for someone to carry out the important but boring tasks, this person usually has to be paid. However, only a few developers are paid directly for their work on open source. There are exceptions, for example in companies such as Canonical (Ubuntu) or Automattic (WordPress).
Many projects are also financed by research funds. The developers are then typically doctoral students or research assistants. However, in such cases, boring topics - such as security - are also neglected, as the main requirement is to support the research work.
In business, developers are often paid indirectly for their work on open source. The classic example is an employer who allows the employee to work on an open source project on the side. This happens especially when the project is also used in the company. However, even in such cases, companies rarely set requirements that go beyond the function.
Under such conditions, is it any wonder that the use of open source entails risks? After all, nothing comes for free.
TANSTAAFL - There ain't no such thing as a free lunch
Robert A. Heinlein
Conclusion: Risk management
Dirk Riehle has suggested in his bloghow the economy should deal with open source. The keyword: risk management. The use of any software - open source or not - involves risks. Understanding these is the task of the operators.
Interestingly, risk management in open source is already established in certain areas: Due diligence regarding the licenses used is common. Companies certainly understand the dangers of lawsuitsof which there were already many in the 2000s.
However, the increasing complexity of software and the importance of software today is increasing the urgency of risk management. A provider of isolated desktop software may still be able to muddle through. But the majority of modern software is networked. Every company should at least have an emergency plan in the drawer. And in many cases, a team that can quickly defuse crises.
Do not forget: Log4Shell was "only" in a computer game discovered.
