Open cooperation
Open source: best friend or worst enemy?
Developed with the idea of open collaboration in sectors such as education, e-commerce, healthcare and production, open source software (OSS) has become an integral part of software development. OSS also ensures the digital networking of production components such as systems, warehouses and logistics in modern industrial production. However, its easy accessibility also provides a target for cyber criminals.
Nowadays, successful software has to offer more functions than ever before. Therefore, development teams are using more and more libraries that are available as commercial products or open source software. The teams that build libraries in turn use other libraries. This creates major dependencies - not only within a company's software, but also among all the players who integrate these libraries into their software. This in turn offers hackers a large attack surface. Successful hacks can cause major damage to companies - and in the worst case even threaten their existence. Those responsible must therefore plan important security measures and ensure that they are implemented.
The challenge here is that around 90% of an application consists of software libraries. These are usually available as open source software, are free of charge and publicly accessible. They are networked with each other and build on each other. This results in many complex dependencies - and security vulnerabilities in just one of these libraries jeopardize the entire software. This means that not just one company is affected, but potentially many.
Using such public libraries in software development is therefore a fine line. On the one hand, they are important for creating a customer experience with numerous possibilities, but on the other hand they harbor security risks in the architecture. IT security must maintain an overview of the increasingly complex networks of libraries. This is extremely difficult, as companies often do not even know which libraries are used within their software supply chain.
This mixture plays into the hands of hackers, who can use even the smallest programming error as a point of attack. Cyber criminals no longer even have to look for vulnerabilities themselves: Catalogs such as the Common Vulnerabilities and Exposures (CVE) system publicly collect known vulnerabilities. This usually only happens after the gaps have been closed. However, teams that have used an affected library often receive this information late or are unable to switch to a new version of this library quickly enough. Attackers therefore have an easy game in this time window.
One prominent example is the Log4Shell vulnerability in Java: Log4j is a library written in Java that logs events such as logins. It had a security vulnerability that hackers exploited to infiltrate malware into systems. This allowed them to copy, transfer and retrieve data without authorization. Business giants such as Amazon, Apple and Twitter were among those affected by the vulnerability.
Using open source software safely
Such cases have far-reaching consequences - as corresponding media reports have repeatedly made clear for years. The issue is currently becoming more explosive due to growing customer demands. This is accompanied by ever faster software development and increasing networking of software supply chains. In the USA, the topic described has already been discussed in many ways and has led to a White House requirement that lists of all libraries involved in software supplied to the government must be kept, a so-called Software Bill of Materials (SBOM). With such a large number of libraries involved, it is essential to maintain an overview in order to identify and eliminate security risks as quickly as possible.
There are no corresponding regulations in Germany as yet. However, DAX companies are becoming increasingly aware of the need to use technology responsibly. Automotive manufacturers in particular are having their software supply chain audited more and more frequently. However, the specific procedure is often still unclear.
Preventive measures
Software is not finished with its development; dangers also lurk in the further course of its life cycle. Functions must be regularly expanded and errors rectified. In this process, the libraries are automatically reintegrated and any security gaps that have become known in the meantime are closed. However, it is also important to check for available updates, especially for applications without regular changes, such as admin interfaces. After all, even applications that were originally secure are not secure forever - and this awareness must reach all relevant stakeholders.
In most cases, automated security checks are carried out in the area of libraries. At the same time, it is advisable to use monitoring tools that scan software and the libraries used in it and draw attention to security gaps. The gaps become visible because a comparison is made with databases such as the CVE mentioned above: If a new vulnerability is announced via the CVE, it can be immediately and automatically compared with the list of libraries used in your own software. The risk of a vulnerability - and its consequences - can be automatically reduced in this way, especially if there are many different libraries. Other tools also test the code you have written yourself and recognize patterns that are considered insecure. In this way, programming errors are automatically detected - according to a GitHub report, these are the most common cause of security vulnerabilities within the software supply chain.
Actively shaping the turnaround
More and more companies are developing concerns about the data security of licensed systems from the major American providers. They do not want to become dependent on individual providers, but want to have more control over their own data. This is why open source solutions are becoming increasingly popular - including in industrial production. Although end-to-end digital networking in smart factories makes some production steps more effective and transparent, extensive networking leads to a higher risk of attack and more people being affected. External factors, such as wars, changes in dispatchers due to delivery difficulties and much more, must also be taken into account as a risk factor.
The topic of OSS will continue to gain relevance in the context of responsible use of technology over the next few years. It will be exciting to see which other tools and practices will become established in this context. Companies that test, evaluate and collaborate at an early stage will actively shape this trend reversal and achieve success.
Erik Dörnenburg, Head of Tech at Thoughtworks Germany










