<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=420236&amp;fmt=gif">

Equifax, open source, and glass houses

Donald Fischer
by Donald Fischer
on February 13, 2018

Equifax is back in the news, with the latest reports indicating that hackers acquired not only names, social security numbers, birth dates, and addresses, but also tax IDs, emails, and driver’s license information for over 140 million consumers.

Perhaps it’s a good moment to reflect before casting too many stones.

What actually happened at Equifax? How sure are you that your organization isn’t vulnerable to similar incidents? And if you’re not sure, what are your options, anyway?

Open source is now mandatory

Like almost every organization building software today, Equifax makes use of third-party open source components. There’s absolutely nothing wrong with that—in fact, it would be just about impossible to create modern online experiences without using open source components (anyone still have a copy of Microsoft FrontPage lying around?).

Those open source software components, like all software, are susceptible to security vulnerabilities. Government-sponsored projects like Common Vulnerabilities and Exposures (CVE®) compile lists of common identifiers for publicly-known cyber security vulnerabilities, including those in open source software.

It’s been widely reported that the Equifax attack took advantage of a vulnerability in a software component that is part of the open source Apache Struts project, specifically CVE-2017-5638.  

In the case of Equifax, the issue wasn’t that the vulnerability was unknown:

Equifax has confirmed that attackers entered its system in mid-May through a web-application vulnerability that had a patch available in March. In other words, the credit-reporting giant had more than two months to take precautions that would have defended the personal data of 143 million people from being exposed. It didn't.” - Wired Magazine, “Equifax Has No Excuse”, September 2017

With great power comes great responsibility

With the issue known, the challenge at Equifax was to ensure that all impacted versions of the Struts package were quickly patched.  And without appropriate process and tools in place, that was not going to be easy:

Patching the security hole was labor intensive and difficult, in part because it involved downloading an updated version of Struts and then using it to rebuild all apps that used older, buggy Struts versions. Some websites may depend on dozens or even hundreds of such apps, which may be scattered across dozens of servers on multiple continents. Once rebuilt, the apps must be extensively tested before going into production to ensure they don't break key functions on the site.” - Ars Technica, "Failure to patch two-month-old bug led to massive Equifax breach", September 2017

Now, ask yourself—honestly—whether your organization can reliably do better?

Could you identify all versions of an open source component impacted by a new security vulnerability, across your entire IT infrastructure? How long would it take?

With no vendor standing behind most open source projects, who’s on the hook to provide a fix for an obscure open source component that’s suddenly exposed to a newfound vulnerability, anyway?

On a more basic level, do you even have a comprehensive list of the third-party open source components that are used in software created by your organization?

With the increasing granularity of open source packages, the number of third-party open source dependencies in a single application can easily run into the hundreds of packages. Unless you’re bringing a repeatable process and technology to this fight, the future looks bleak.

Screen Shot 2018-02-12 at 12.42.24 PM.png

Let’s tackle this challenge together

While it may seem convenient and even fun to point fingers at Equifax—especially when their executives reportedly attempt to throw individual IT staff members under the bus while floating down on their golden parachutes—securing modern software is a challenge for every organization.

At Tidelift, we think the solution has multiple elements:

  • Good data: A robust set of facts about open source software and its interconnections. For us, this starts with Libraries.io, our project that has become the largest index of open source components in the world.
  • Good process: Automated tools and repeatable methods that leverage this dataset and provide insights that are immediately actionable in your own organization.
  • Good friends: A new way to responsibly partner with the community of open source creators and maintainers who make your infrastructure possible in the first place. Creating a rising tide that lifts all ships.

If you’re interested in what we’re up to, follow us on Twitter and sign up for updates. We’ll be sharing more soon.

2018 open source survey results