Log4Shell Three Years On: The Vulnerability SMEs Are Still Ignoring
In December 2021, a single flaw in a widely used Java logging library called Log4j sent shockwaves through every corner of the technology industry. The vulnerability, quickly dubbed Log4Shell, was not exotic. It did not require a sophisticated nation-state actor to exploit. It required almost no technical skill at all. What made it catastrophic was something far simpler and far more uncomfortable: almost nobody knew they were running the affected code in the first place.
Within 72 hours of public disclosure, hundreds of millions of devices were reported as potentially exposed. Governments issued emergency directives. Enterprise security teams worked through the holiday period patching systems they did not know depended on Log4j. Ransomware groups and state-sponsored attackers began exploiting it within days.
That was three years ago. You might reasonably assume the lesson has been learned. It has not — at least not by the organisations that needed it most.
A 2023 analysis by Veracode found that 79 percent of organisations had not remediated known vulnerabilities in their open-source dependencies within the first month of disclosure. A separate study by Sonatype found that the average software application now contains 49 percent more open-source components than it did three years ago, with the number of known vulnerabilities in those components increasing at a parallel rate. Meanwhile, research consistently suggests that SMEs — companies with between 10 and 500 staff — tend to have lower rates of software composition analysis and weaker visibility into their own software supply chains, though precise figures vary by sector and geography.
Log4Shell was not a one-off. It was a preview. XZ Utils in early 2024 demonstrated that the threat had evolved: attackers are now willing to invest years infiltrating the open-source projects that sit invisibly inside production software. The question is not whether another Log4Shell-class event will happen. It is whether your business will be able to respond when it does.
For most SMEs, the honest answer right now is no.
What Is Dependency and Supply-Chain Watch and Why Does It Matter
Before addressing the fix, it helps to be precise about the problem.
Modern software is not built from scratch. Whether you are running a SaaS platform, an internal business application, or a customer-facing web service, your development team almost certainly relies on open-source libraries and third-party packages — components written by other developers and pulled into your codebase as dependencies. These libraries handle everything from authentication and encryption to PDF generation and date formatting. Without them, software development would be orders of magnitude slower and more expensive.
The problem is that dependencies have their own dependencies. A single application can contain hundreds of nested packages — many of which were written years ago, are maintained by a single unpaid volunteer, and have never been reviewed by your team. You did not choose them deliberately. They arrived as a side effect of choosing something else.
Dependency and Supply-Chain Watch is the systematic practice of maintaining continuous visibility into every open-source and third-party component running inside your software, tracking known vulnerabilities against those components in real time, and having a documented process to respond when a new flaw is disclosed. It sits at the intersection of software development, security operations, and risk management.
This matters for several interconnected reasons:
- Attack surface: Every unpatched dependency is a potential entry point. Attackers actively scan for applications running vulnerable component versions.
- Speed of exploitation: The gap between public disclosure and active exploitation has collapsed. In the Log4Shell case it was measured in hours. You cannot afford a manual, reactive process.
- Regulatory pressure: Frameworks including NIS2 in Europe, the UK Cyber Essentials Plus scheme, SOC 2, and emerging SEC guidance for US-listed companies all increasingly require organisations to demonstrate they have visibility and control over their software supply chains.
- Third-party and customer trust: Enterprise procurement teams and regulated-sector buyers are beginning to ask for Software Bills of Materials (SBOMs) as a condition of doing business.
Dependency and Supply-Chain Watch is not a luxury feature for well-resourced engineering teams. It is the baseline hygiene that determines whether your business remains operable after the next major open-source vulnerability is disclosed.
The Board-Level Reality: Why This Is a Business Continuity Failure, Not Just a Developer Problem
Here is where most conversations about dependency vulnerabilities go wrong. They stay in the engineering department. A developer raises the issue, a manager nods, nothing changes because there is no budget, no ownership, and no sense that the C-suite or board actually cares.
This framing is dangerous and inaccurate.
When an unpatched dependency allows a ransomware operator to encrypt your customer database, the consequence is not a developer's problem. It is a revenue problem, a regulatory problem, a reputational problem, and potentially a personal liability problem for the directors who signed off on risk management frameworks that did not account for software supply chain exposure.
Consider what a significant exploitation event actually means for an SME:
Operational shutdown: Many SMEs run on a handful of interconnected SaaS and internal applications. A successful attack via a vulnerable dependency can take all of them offline simultaneously. For businesses without mature incident response plans, recovery can take days or weeks.
Data breach liability: If the exploited dependency provided access to personal data — customer records, employee information, payment data — you are now in breach notification territory under GDPR, the UK Data Protection Act, state-level US laws, and equivalents across Australia, Canada, and beyond. Fines, mandatory notifications, and legal costs follow.
Contract and insurance consequences: Cyber insurance policies increasingly include clauses around patch management and known vulnerabilities. If your insurer can demonstrate that you were running software with a known, patchable flaw at the time of an incident, coverage may be voided or disputed. Customer contracts in regulated industries often include similar provisions.
Customer and investor confidence: For SaaS businesses in particular, a publicly disclosed security incident linked to a known, avoidable vulnerability is a serious reputational event. Enterprise customers do not forgive it easily.
The board-level question is straightforward: do we currently know, with reasonable confidence, what open-source components are running across our software environment, and do we have a process that would alert us and enable rapid response within hours of a new critical vulnerability being disclosed? If the answer is no, that is a material business continuity gap that belongs on the risk register alongside fire, flood, and key person dependency.
Making this visible at board level is not about alarming non-technical leaders. It is about ensuring that the resourcing, prioritisation, and process ownership required to close this gap actually exists.
How to Audit What Is Actually Running in Your Software Stack
The first step is understanding what you have. For most SMEs, this will be more complex than expected and less terrifying than feared once it is documented.
Step 1: Identify your software assets
List every application, service, and internal tool your business depends on. Separate these into three categories: software your team builds or customises, software you buy as a service from a third party, and infrastructure components you manage directly (servers, containerised workloads, CI/CD pipelines).
Step 2: Generate Software Bills of Materials
For software your team builds, generate an SBOM — a structured, machine-readable inventory of every component and dependency in your codebase. Tools that can help here include:
- Syft (open source, by Anchore): generates SBOMs from container images and filesystems
- CycloneDX or SPDX: open standards your developers can output from build pipelines
- GitHub Dependency Graph: built into GitHub, provides automatic dependency detection for supported ecosystems
- Snyk Open Source or FOSSA: commercial tools with free tiers that provide SBOM generation alongside vulnerability scanning
If your software is built by an external development agency or contractor, you are entitled to request an SBOM as part of your contract. If your contracts do not currently include this requirement, change that.
Step 3: Cross-reference against known vulnerability databases
Once you have an inventory, you need to compare it against continuously updated vulnerability intelligence. Key sources include:
- The National Vulnerability Database (NVD) maintained by NIST
- OSV (Open Source Vulnerabilities): a distributed database specifically covering open-source ecosystems
- GitHub Advisory Database: real-time advisories linked directly to dependency graphs
Automated tools — including Snyk, Dependabot, Renovate, and OWASP Dependency-Check — can perform this cross-referencing continuously as part of your development pipeline, alerting your team when a component in your stack has a newly disclosed CVE.
Step 4: Assess and prioritise
Not every vulnerability is equal. Use CVSS scores as a starting point, but layer in context: Is the vulnerable component directly reachable from the internet? Is there a known exploit in the wild? Is there an available patch? Prioritise critical and high-severity flaws in internet-facing components first, then work systematically through the remainder.
This audit need not be a six-month project. A focused effort over two to four weeks, using the free tools listed above, can give most SMEs their first meaningful picture of supply chain exposure.
Practical Dependency and Supply-Chain Watch for Teams Without Dedicated Security Staff
Not every SME has a DevSecOps engineer. Many do not have a security function at all. Dependency and Supply-Chain Watch is still achievable at a meaningful level with the right tooling, processes, and external support.
Automate what you can, immediately
If your code lives on GitHub, enable Dependabot today. It is free, requires no configuration expertise, and will automatically open pull requests to update vulnerable dependencies. GitLab has a built-in equivalent. This single step closes a large proportion of routine dependency risk with almost no ongoing effort.
For container-based workloads, integrate a container scanning step into your build pipeline. Tools like Trivy (open source) or Grype can scan container images for known vulnerabilities before they reach production.
Establish a lightweight vulnerability response process
You do not need a 40-page incident response playbook. You need a documented answer to these questions: Who receives vulnerability alerts? Who decides whether a finding is critical? What is the expected time to patch for critical, high, and medium severity findings? Who communicates to customers or regulators if exploitation occurs?
Write this down. Make sure the relevant people know it exists. Test it once every six months with a simulated disclosure scenario.
Use a managed or co-managed security service for continuous coverage
For SMEs without in-house security expertise, the most practical path to mature Dependency and Supply-Chain Watch is working with a managed security provider who can maintain continuous monitoring, triage alerts, and provide expert guidance on remediation priorities. This model — sometimes called continuous threat exposure management — gives you the coverage of a security function without the cost or complexity of building one internally.
When evaluating providers, ask specifically: Do they provide SBOM management and dependency tracking as part of their offering? Can they integrate with your existing development toolchain? Do they provide the human analysis layer to distinguish signal from noise in vulnerability alerts?
Build supply chain security into procurement
For software and SaaS tools you buy rather than build, your exposure depends on your vendors' security practices. Add supply chain security questions to your vendor assessment process: Do they generate and share SBOMs? Do they have a vulnerability disclosure policy? What is their average time to patch critical dependencies? For critical business applications, request evidence of their software composition analysis practices.
Train your developers, not just your security team
Most developers already care about security — they simply lack the framing. Short, practical training on dependency hygiene (avoiding abandoned libraries, preferring well-maintained packages with active communities, understanding transitive dependencies) reduces the rate at which new risk is introduced into your stack.
Compliance, Liability, and the Cost of Doing Nothing
The regulatory environment around software supply chain security is hardening quickly, and SMEs are not exempt.
NIS2 (EU): In force from October 2024, NIS2 extends supply chain security obligations to a significantly broader range of organisations, including many mid-sized businesses in sectors such as digital infrastructure, manufacturing, and services. Obligations include the ability to demonstrate control over software dependencies and third-party risk. Penalties for non-compliance can reach €10 million or two percent of global annual turnover.
UK Cyber Essentials and Cyber Essentials Plus: While not explicitly mandating SBOM practices, the patching controls required for certification assume you have visibility into what software is running across your estate. Dependency vulnerabilities in unmonitored components will fail an assessment.
SOC 2 (US and international): Trust Services Criteria related to change management and risk management increasingly require evidence of systematic vulnerability management across the software supply chain, including third-party components.
DORA (EU Financial Sector): Directly requires financial entities and their ICT providers to manage ICT third-party risk, including software dependency risk, as a core operational resilience obligation.
Beyond regulatory fines, the liability picture for directors is shifting. Personal liability exposure for executives who fail to maintain adequate cybersecurity governance — including supply chain risk management — is an active and developing area of legal discussion in the US, EU, and UK, though the precise legal landscape varies by jurisdiction.
The cost of doing nothing is not abstract. It is the cost of a ransomware recovery on top of GDPR fines on top of legal fees on top of lost contracts — all traceable to a vulnerable library that was three versions out of date and unknown to anyone in the organisation.
Log4Shell was the warning. The organisations that treated it as a one-time event to patch and forget are still exposed. The organisations that used it as a forcing function to build systematic Dependency and Supply-Chain Watch are measurably more resilient today.
The tools exist. Many of them are free. The process does not require a dedicated security team to get started. What it requires is a decision, made at the right level of the organisation, that software supply chain visibility is not optional.
If your business does not yet have that decision on record, now is a reasonable time to make it.