Security vulnerabilities in code
Operating system software, application software or firmware in an embedded system are elementary components of any digital infrastructure. However, increasing acceleration and deadline pressure in digitization projects often lead to a neglect of imperative information security aspects. The development requirements for software are usually function-centric and emphasize constructive aspects, so that the destructive view of potential security vulnerabilities is mostly diametrically opposed to the actual development goals: many programmers simply also lack a structured and sharpened view of cybersecurity.
Under these conditions, development teams have a hard time continuously reviewing and consistently securing the coding of their software, as evidenced by the many vulnerabilities that the non-profit MITRE Corporation publishes each year in its CVE (Common Vulnerabilities and Exposures) list. The regular security patches of even well-known software manufacturers are an indicator of the Sisyphean task of closing security-relevant bugs, let alone identifying them before they are even launched on the market.
Open source code - a special case
When coding self-developed software, programmers like to resort to open source libraries and modules. The practical advantages are obvious: If you don't have to reinvent the wheel over and over again, you benefit from this technology boost, speedy development, lower development costs, more transparency through open source code, and higher interoperability through open standards and interfaces.
It is also often said that code from open source offers a high degree of security because the code has been validated by many users and the swarm intelligence of the open source community enables fast and efficient bug fixing.
In practice, this trust must now be evaluated in a differentiated and critical manner. The most serious example is the zero-day security vulnerability Log4Shell in the widely used logging library Log4J for Java applications, which was discovered in November 2021. You may have heard about the red alert level issued by the German Federal Office for Information Security (BSI) for Log4Shell. The Log4J library, distributed as a reliably functioning quasi-standard via the Apache Foundation, has established itself in many systems since 2013 - including well-known web services such as Amazon AWS.
The complexity of these well-developed and also maintained libraries implicitly provides powerful functionalities of which an importing developer is often unaware in his own combined new development, but which can be exploited by attackers.
Another insecurity factor of open source components are so-called supply chain attacks, i.e., intended built-in vulnerabilities by malicious actors who pose as part of the open source community and assist in code development. Such a vulnerability is an extremely efficient way for hackers to attack a large number of downstream user organizations. No wonder, then, that this attack vector is growing rapidly: a Sonatype study diagnosed a 650% increase when comparing 2020 and 2021.