When developing applications today, most companies use third-party components, often open source. This saves time and resources, but it also creates challenges. If a component contains a security flaw or has a problematic license, it can affect the entire software.
An example is the well-known Log4J, a popular logging component used in thousands of applications. When the Log4Shell vulnerability was discovered in December 2021, it became a global crisis.
This vulnerability allowed attackers to run malicious code on systems using Log4J, and because the component was so widespread, thousands of companies and organizations were affected. Not least in terms of how much time and resources were spent on investigation.
This showed how important it is to know exactly which components are included in the software – something an SBOM could have facilitated.
Log4J is not the only example. Other known vulnerabilities in open source include:
-
Heartbleed (OpenSSL): A serious vulnerability that leaked sensitive information from servers using OpenSSL.
-
Apache Struts: A vulnerability that led to a major data breach at Equifax in 2017, where millions of consumers' data was exposed.
-
Spring4Shell: A critical vulnerability in Spring Framework that allowed attackers to run malicious code on servers.
These examples show how vulnerabilities in open source can have major consequences. With an SBOM, you can quickly identify if your software contains affected components and take action before it's too late.