SBOM: The recipe for more secure software

You are building a house from bricks supplied by dozens of different suppliers without knowing their quality or origin. Bold? That is exactly how software is often created today, and security incidents begin precisely where oversight ends. Today, we'll look at why SBOM (software bill of materials) is key to the stability and security of your digital construction.

A single vulnerability. That's sometimes all it takes to open the door to your company network for attackers. We saw this at the end of 2021, when a critical zero-day vulnerability called Log4Shell was discovered, allowing arbitrary code to be executed on an affected server. It was discovered in one of the most widely used Java libraries in the world: Log4j.

When the IT world came to a standstill because of one library

Log4j is, as the name suggests, an open-source logging tool from the Apache Software Foundation. This library had one “smart” feature: instead of passively storing the text it received for logging, it attempted to actively analyse it. If the text looked like a special command (specifically a JNDI lookup), the library executed it. The intention was good, of course, but as they say, the road to hell is paved with good intentions. All an attacker had to do was use any text field in a web application, insert the magic string

and Log4j would immediately connect to the attacker's server, download the malicious code, and execute it.

On the CVSS (Common Vulnerability Scoring System) scale, Log4Shell received a score of 10.0 out of 10.0 – the highest possible score. This means that exploiting the vulnerability was so trivial that even a beginner could do it, no authentication to the server was required, and it even allowed complete control over the target. Many security experts considered and still consider this vulnerability to be the most critical and serious vulnerability ever. Exploiting it was so easy that the first reports of it came from the Minecraft gaming community. Attackers wrote a malicious string into the game chat, and when the server log recorded it, it was compromised. Within a few hours, cybercriminals were already trying to exploit the vulnerability.

The problem wasn't the vulnerability itself, but its invisibility. Log4j was everywhere. Research conducted by Wiz and EY showed that 93% of cloud enterprise environments were vulnerable to Log4shell, and ten days after the vulnerability was disclosed, only 45% of vulnerable workloads had been patched on average. Every security director in every IT company in the world turned to their team and asked a single question: "Are we using Log4j?" But few could answer. Often, it was a matter of transitive dependencies—the code used library X, which used library Y to function, and that library used a vulnerable version of Log4j for logging. Security teams spent days and weeks desperately scanning servers and manually searching source codes to see if there was a ticking time bomb somewhere deep within their systems. I'm not trying to say that this revealed that software in general was vulnerable. We knew that. What we didn't know was that companies often have no idea what their software is built from.

A hero named SBOM

An Open Source Security and Risk Analysis (OSSRA) conducted by Synopsis in 2024 revealed that 96% of commercial software projects contain open-source components. More significantly, open-source code accounted for an average of 77% of the total source code in the projects analysed. In other words, almost all software uses third-party libraries, which often outweigh the software's own code. Therefore, when a panicked security director asks whether library X is present in our software, it is good to be prepared. A list of software components, for which we use the English abbreviation SBOM, can help us out in this situation.

SBOM is a bit like the list of ingredients on food packaging. When you buy a cookie, you can see that it contains flour, sugar, and eggs. But more importantly, it also tells you that it contains traces of peanuts. If you have a fatal peanut allergy, this is the most important information on the entire package for you.

Log4Shell was a massive peanut allergy for the software world. Companies that had an up-to-date SBOM at their disposal had a huge advantage. Instead of panicking and manually searching, all they had to do was ask one simple question: "Which of our products contain log4j-core version lower than 2.15.0?" Within minutes, if not faster, they had a clear list of systems that needed to be fixed urgently. Others spent Advent searching through code.

What exactly is an SBOM?

Formally speaking, an SBOM is a structured, machine-readable list of all components, libraries, and modules contained in each software product.

It is important to note that this is a data file, most often of the JSON type, in a standardized format, typically SPDX or CycloneDX, which can be automatically read and analysed by security tools (e.g., OWASP Dependency-Track). It follows, therefore, that SBOMs are not generated manually. Automated tools are used for this purpose, such as Syft, Tern, CycloneDX, and others.

Generating an SBOM should be an automatic part of your CI/CD process. Every time you build a new version, a new SBOM is generated, which can also be uploaded directly from the pipeline to a security tool.

The importance of SBOM is growing

You may think that this is just another annoying bureaucratic requirement. However, SBOM addresses three key areas of modern software development.

1. Vulnerability Management

   As Log4Shell showed, speed is everything. When a new critical vulnerability (CVE) is announced, you're racing against attackers. SBOM gives you instant visibility and changes your response time from days/weeks to minutes. It allows you to proactively identify risks before they are exploited.

2. License Management

   Even open source isn't free without rules. Every library has a license. Some licenses may require you to publish your own source code when you use them in your product. Using such a library without the knowledge of your legal department can lead to expensive lawsuits or loss of intellectual property. SBOM brings complete order to this.

3. Transparency and legislation

   Whether we like it or not, the market is changing and demands are growing. After a wave of major attacks, the most significant of which (apart from Log4Shell) was the supply-chain aimed at SolarWinds in 2020, customers and regulators no longer want to believe promises. They want proof.

• USA (Executive Order 14028): Following the SolarWinds attack, the US government issued an executive order requiring all software sold to federal agencies to be accompanied by an SBOM. And since the US government is one of the largest customers in the world, this move essentially forces the entire market to start addressing SBOMs.
• EU (Cyber Resilience Act): This new European regulation, which came into force in December 2024 and will take full effect on December 11, 2027, targets software and hardware manufacturers directly. Essentially, it says that if you want to sell your product with digital elements on the EU market, you must prove that it is secure. A key part of this proof is the obligation to create SBOMs, provide them, and actively report vulnerabilities.
• Czech Republic (NIS2/ZoKB): As of November 1, an amended Cyber Security Act is in force in the Czech Republic, reflecting the NIS2 directive, which primarily targets operators of critical services (banks, hospitals, energy). It directly requires them to manage the risks of their supply chain, which in practice means that these large entities must now actively investigate how secure the software they purchase is.

In short, regulatory pressure is emerging and growing, forcing companies to create and distribute SBOMs. We are rapidly moving from the category of "competitive advantage" to the category of "mandatory equipment" and a condition for market entry.

SBOM is just the first step

Having an SBOM is great. It's a bit like having a warehouse inventory list. But that list alone won't tell you that one of the items on shelf 46A has just caught fire.

Creating an SBOM is just the first step. The second, more challenging step is to have processes in place for its active management and monitoring. We also help our customers with this. It is not enough to generate an SBOM once. It must be part of the entire development lifecycle. It must be automatically analysed and constantly compared with global vulnerability and license databases. At Edhouse, we help companies not only know what their software is built from, but also ensure that it is secure, license-compliant, and ready for the future.