The Hypocrisy of Open Source: An Update

🖥️ Open source was supposed to be a beacon of innovation and collaboration. Today, it’s also one of our largest unacknowledged security risks.

Back in February 2024, I shared a post on LinkedIn about the risks I was seeing in the world of open-source software—and it resonated with a lot of people. This blog entry is an expanded update to that original post, with added thoughts and lessons learned since then.

I might not have had “Information Security” officially in my title until recently, but I’ve always been passionate about securing the environments I support. Over the years, I’ve seen the good, the bad, and the downright terrifying. And nothing better captures that range of experience than the current state of open-source software in enterprise environments.

---

🌐 What is Open Source, Really?

Open-source software is often romanticized. It’s a beautiful concept:

“Open-source software is code that is designed to be publicly accessible—anyone can see, modify, and distribute the code as they see fit.”
— Red Hat

The idea aligns perfectly with the spirit of the open web—knowledge and tools shared for the greater good.

But as with most great ideas, reality complicates the dream:

• Companies take open-source code, make minor “proprietary” tweaks, and sell it as a commercial product.
• Others embed open-source components in their applications and fail to give credit to the original creators.
• And the worst offenders? They never maintain the software they’ve shipped—leaving their customers unknowingly exposed.

---

🚨 Log4J: The Security Wake-Up Call

The Log4J vulnerability was a seismic event in cybersecurity. But the real lesson wasn’t just about a single CVE—it was about how organizations responded.

When Log4J 2.x vulnerabilities hit in 2021, I saw three types of responses:

1. Denial: “We don’t think we use Log4J.”
2. Excuses: “We can’t patch, but our Java version keeps us safe.”
3. False confidence: “We’re using Log4J 1.x, so we’re fine.”

Here’s why #3 is terrifying:

• Log4J 1.x went End-of-Life (EOL) in August 2015.
• EOL software receives no security patches and no official vulnerability reporting.
• Running it in production is like leaving your front door open with a sign that says “We trust nobody will come in.”

To put that timeline into perspective:

• Windows XP and Windows Server 2003 went EOL in July 2015.
• Log4J 1.x went EOL just one month later.

Would you run Windows XP in production today? Of course not.
So why is it considered acceptable to run EOL software libraries in mission-critical applications?

---

🛑 End-of-Life = End of Safety

From a vulnerability management perspective, the equation is simple:

EOL Software = Inherently Vulnerable

It doesn’t matter if a specific CVE isn’t attached to it. Without patches, you’re operating blind:

• Vulnerabilities may exist but never be reported.
• Exploits can quietly circulate in the wild.
• Attackers know exactly which abandoned software to target.

When our team scanned our environment for Log4J, the results were shocking:

• Numerous vendors shipped applications with Log4J 1.x.
• Some vendors refused to patch, saying 1.x wasn’t part of CVE-2021-45105.
• One vendor’s “fix” was to downgrade from 2.x to 1.x and release that as a patch.

Think about that: a security patch that reintroduced unsupported software into production.

---

🤔 The True Hypocrisy of Open Source

Here’s where the hypocrisy becomes crystal clear:

• Vendors will refuse to run Windows XP or Server 2003 because they are EOL.
• But the same vendors ship applications built on Log4J 1.x, which has been EOL for nearly a decade.

When pressed, their reasoning is always:

“That OS is unsupported and unsafe.”

Exactly. So why does that logic not apply to the software components inside your product?

This double standard puts customers in a lose-lose situation:

• You can’t patch it yourself because it’s buried in the vendor’s code.
• The vendor won’t fix it because “no CVE exists.”

Meanwhile, attackers don’t care about excuses—they care about entry points.

---

💡 Moving Forward

I ended my original post with a call for change, and I feel even more strongly today:

• Vendors must own their dependencies. If you ship a product, you inherit the responsibility for every library you embed.
• Security teams must scan for EOL software, not just known CVEs.
• Customers must hold vendors accountable. If a component is EOL, demand a roadmap for removal.

Open source is powerful, but freedom without responsibility creates risk. Until the industry embraces that reality, we will keep reliving the same cycle:

1. Vulnerability discovered.
2. Industry scrambles.
3. Vendors shrug and point fingers.

It’s time for that cycle to break.