Unless you live on a remote island with no Internet connection, you’ve certainly heard about the Log4j issues that affected so many applications and internet services over the last 10 days. The coincidental discovery of this critical bug in the context of Minecraft console messages (typing a message on the Minecraft game client could let someone execute code on a Minecraft server) due to the use of an extremely popular Java logging library called Log4j, caused every single IT company and every company using software applications to check if the issue was affecting the company’s software, hosted services, internal web sites, and any other use case scenario.

The list of affected software applications (there is one here, for example) is fairly impressive, because despite having lost some of the hype and marketing push, Java is and remains one of the world’s most popular languages, and the JVM one of the most popular runtime execution environments.

RAD Studio Native Code and No Java Dependency

Now, what does this mean for Embarcadero in general and RAD Studio in particular? Directly, not much. Software built in Delphi or C++Builder doesn’t use or rely in any way on Java (with the exception of Android applications) and therefore doesn’t use Log4j. More in general, Delphi and C++Builder create natively compiled applications, which are less subject to execution environment problems (here I’m referring to Java, .NET or JavaScript execution environments). However in this case the issue was not in the execution environment, but in a popular library, and RAD Studio developers use add-on components and third party libraries, like any other developer community does.

Let me clarify once more: A web server or web service built in Delphi or C++Builder (or C++ in general) is not affected by the Log4j issue. The same is true, of course, for web applications built in ASP.NET, Python, or PHP. The issue is specific to software written in Java – and there is a lot of Java software out there, as linked above.

Getting back to Delphi and C++Builder, having compiled code helps with security, but it is not sufficient. It is also important to only choose libraries and components you can fully trust (at a minimum, requiring the source code to be included). Moreover, it is also important for a developer to write code with a specific focus on security. As was mentioned last week, copy-and-paste coding (while not directly responsible for the Log4j issue) is a coding style on the flip side of writing secure applications.

Contributing Back to Open Source

There is also another key issue that the Log4j problems made obvious: there are multi-million dollar projects managed by large corporations that rely on open source projects with no funding, managed by developers in their spare time (outside their regular jobs). The idea that you can use open-source to save costs without contributing back any time, resources, or money to the projects you leverage is becoming a huge problem in the industry.

This is also true of the Delphi and C++Builder ecosystem: Embarcadero has started funding and donating to a few open source libraries, but we should do more. We also encourage all business applications that significantly leverage open-source Delphi libraries and tools to contribute back to them – including through security assessments!

How many open-source projects do you use for your professional applications and when is the last time you donated to any of them?

Security is Multi-Faceted

Security is a continuum requiring multiple angles and each of the items below can help:

• Natively compiled applications
• No dependency on a runtime execution environment
• Use of vetted and trusted third party libraries and components
• Committing to contribute back to open-source projects you leverage
• Security focus when writing code (no copy-and-paste coding)
• Tooling to verify an application source code
• Secure storage of source code (to avoid source code injection)
• Secure build environment (to avoid binary code injection)
• Application executable signing

While not comprehensive, and one with a bias towards compiled code (we really think it matters), we hope this list and the overall reaction to the Log4j incident can help you and your organization rethink security and add more value to the role of developers – who are the cornerstone of any secure development scenario.

Happy coding with your Log4j-free RAD Studio 😉