In mid December, an inconspicuous software package has suddenly been the talk of the town. If a Java logging framework even makes it onto the cover pages of the mainstream media, then something big must have happened. It did. The Log4Shell bug is indeed an extremely serious security vulnerability that affects countless software systems worldwide, and the extent of which will probably not be known for a few months.
As so often these days, social media was quick to pour mockery and hate on this widely used logging framework and its developers who “implement software far from any quality controls”. We at Cloudflight consider such statements to be completely inappropriate and make it clear: without open-source software, numerous companies, especially in the IT industry, would not be able to exist – Cloudflight included. Open-source components such as the Spring Framework, Micronaut or various projects from the Apache Software Foundation – even the OpenJDK itself – are a central component of numerous software development projects.
According to Snyk, 6 out of 10 developers in the Java environment are using the Open-Source Spring Framework for their main applications.
Very often, these libraries are maintained and further developed by dedicated developers who sacrifice a lot of time for this and are not being paid. The rest of the world (including us) can use these packages free of charge, integrate them into their customer projects, and ultimately earn money with them. Even though companies like Pivotal have developed their own business models around their frameworks – the entire Spring ecosystem is and remains free for everyone to use.
For this, one can and should say “thank you” – especially during the Christmas season.
Nevertheless, one should be aware that even widely used open-source software is not free of bugs and is not protected against vulnerabilities. The Log4Shell bug is such a very big vulnerability that should not be minimized. From the outside, the origin of such a bug is often not comprehensible, but if you have been working in software development yourself for 15 years, you know how quickly something like this can happen.
In turn, the fact that this package is open-source software, helped that the vulnerability was being discovered and published in the first place, and that a fix was available very quickly. The developers of Log4J also deserve thanks for this.
Now all users of Log4J must update this library very quickly, and the Cybersecurity & Infrastructure Security Agency (CISA) has also made a guide available for this. However, this poses a great challenge for many software users, as it is often not easy to find out whether the affected library is included, especially in the case of third-party products that one did not develop himself. CISA therefore argues for the establishment of a “Software Bill of Materials” (SBOM), a parts list which should include all supplied parts for every software delivered, like in electronics.
At Cloudflight, we have exactly this SBOM since several years. Every software component that is developed in our Managed Build Pipeline ends up in a common database, the DependencyTracker, including all dependencies. This self-developed software allowed us to identify all customer projects using Log4J at the push of a button on the morning of 10 December, shortly after the security breach became known. Fortunately, the list was empty, since we usually rely on Spring Boot for our Java applications, and Logback is used here as the default logging implementation. Only a few minutes after the vulnerability became known, we were able to rule out an attack vector in more than 100 customer projects and give green light. That was luck, and if Logback, for example, had also been affected in that way, we would have had to react differently, but we would also have had complete transparency in that case. What remained were self-contained third-party products such as ElasticSearch, for which the possibility of an attack was comparatively low, but for which we also quickly installed updates. Log entries from several production systems showed that attempts were made very quickly from the outside to exploit this vulnerability. However, we – and thus also the customer projects we support – were protected.
Within 3 days, the number of attack vectors recorded increased to over 800,000 according to CPR.
By the way, we use the DependencyTracker not only to track down third-party packages with security vulnerabilities, but also to ensure that the licenses of all used libraries allow them to be used in commercial projects.
The open-source community has given us a lot, and that’s why we at Cloudflight decided back in autumn that we wanted to give something back to the community, and there will be updates here in the new year. For those that can’t wait, you may browse through our Github-Account already.
Until then, we wish you all a Merry Christmas and especially to all those out there who improve the open-source world with their efforts, a few peaceful days and once again a big thank you!