Log4Shell: if you do not know your dependencies, you do not know your attack surface
The Log4Shell vulnerability showed that most companies have no idea which libraries are running inside their systems.
In early December 2021 a vulnerability was disclosed in Log4j - a widely used logging library in Java applications. The vulnerability was named Log4Shell and received the maximum severity rating. It allowed an attacker to execute arbitrary code on a vulnerable system simply by sending a specially crafted string.
The technical details are interesting to specialists. For managers what matters is something else: the reaction of most companies to this news was identical - "do we have Log4j?"
And that was a question many companies could not answer.
Why a simple question is so hard to answer
Log4j is a library. It is not installed separately and is not visible in interfaces. It comes bundled inside other products and frameworks as a dependency. An application uses a framework, the framework uses Log4j - and the fact that Log4j is present inside may be unknown to anyone except the developers who wrote that application.
The difficulty is that modern software products are built on tens or hundreds of open-source libraries. This is normal and economically sensible - there is no need to reinvent the wheel every time. But it means that a company's attack surface includes not only what it wrote itself, but everything that entered its systems through dependencies.
What SBOM is and why people are talking about it
SBOM - Software Bill of Materials - is a list of software components. By analogy with the list of ingredients on a food label: exactly what is in this product.
Before Log4Shell the concept of SBOM existed mainly in narrow circles of security specialists and in regulated industries. After Log4Shell it entered the agenda even for companies far from professional cybersecurity. Because without understanding what their systems are made of, they cannot answer the question "did this vulnerability affect us?"
The US presidential executive order in May 2021 had already included SBOM requirements for software supplied to federal agencies. Log4Shell accelerated that conversation.
What this means for an ordinary company
I am not urging anyone to immediately build a complete registry of all dependencies in all systems. That is a large effort, and for many companies it is excessive.
But a few things make sense to do.
Understand who is responsible for responding to critical vulnerabilities. Not "the IT department in general", but a specific person who receives information about a vulnerability and coordinates investigation and remediation.
Have an inventory of key systems. Not necessarily detailed down to library level. But an understanding of: which systems are business-critical, who maintains them, and how to reach them in an incident.
Agree with commercial software vendors. If the company uses bought or custom-built software - the question "how quickly do you notify about vulnerabilities, and how quickly do you release patches?" should be in the contract or at minimum in the correspondence.
Do not defer updates. Many critical vulnerabilities have a patch at the time of disclosure. Companies that update dependencies regularly are exposed for a short window. Companies that have not updated for years carry risks they may not know about.
What remains after the noise
Log4Shell will cool as a topic within a few months. Other vulnerabilities will appear. The principle does not change: every library in use, every open-source component, is part of the attack surface. Not knowing about it does not mean being safe. It means not knowing about your own risk.
Software security is not only what your team wrote. It is everything your team's work stands on top of.