If you're scrambling this week to install patches after the discovery of the GHOST vulnerability affecting Linux systems, you're not alone. The fact that we've been down this road before doesn't make it any less frustrating. It wasn't that long ago that the news broke about Shellshock. And not long before that, Heartbleed.
Being in reactive mode because of serious emerging software security threats might seem like the new normal but you don't have to accept that. You can do more than just react. What if your organization could make software security pre-emptive, heading off many vulnerabilities before any damage is done
By focusing on what I like to call "open source hygiene," you can do just that more on this shortly. But first, let's examine why GHOST is making software security experts so nervous.
GHOST in the Linux machine
The GHOST vulnerability in the Linux GNU C Library (glibc 2.2) is a gaping one. Version 2.2 is native to a range of standard Linux distributions, especially ones built on Debian Wheezy, but also on Red Hat platform versions. This system population includes a wide variety of embedded systems along with servers and desktops.
The affected API, "gethostbyname()," is an integral part of the POSIX standard, which is the definition of UNIX-type systems, including Linux. This API is part of the core functionality of Linux. The glibc library is the primary library used by all types of programs running on Linux to interact with the kernel and to perform core input/output operations. Put another way, everything runs through glibc it's like Grand Central Station.
Perhaps most worrisome is the fact that the exploit can be triggered remotely through benign actions such as processing email. And unlike bash, which was central to the Shellshock threat, glibc is a reasonably well-curated library. So the issue with GHOST is not that there haven't been enough eyes on the code. In fact, it's constantly being updated and tested. Rather, the issue is that not all of those eyes are sufficiently security-savvy.
Taking charge of open source security
Even with many eyes on the code, software vulnerabilities like GHOST and its predecessors are inevitable. IT organizations are stretched thin, trying to do more with less and deliver innovative applications faster than ever. Choosing open source components as part of the development process helps them achieve these goals. What's more, participating in and contributing to open source communities is a critical part of how forward-thinking IT organizations innovate.
So how can software development organizations balance open source software security concerns with the drive to keep innovating at an ever-faster pace
The answer lies in open source hygiene. By implementing automated solutions for managing open source code throughout the development process and across the supply chain, organizations gain a critical advantage in heading off security threats. This means code is automatically vetted against vulnerability databases such as the OSVDB and NVDB, assuring that only the most up-to-date versions of those components are chosen.
In the case of GHOST, this approach would have yielded one of several outcomes:
- Earlier flagging of glibc version 2.2 or earlier, with a call to upgrade development and deployed versions to version 2.3.
- Current flagging of the library, based on OSVDB/NVDB bulletins, to check for deprecated versions to and confirm that the correct patches had been applied to version 2.3.
In other words, you won't have to waste time searching for open source components in your code base you'll know exactly where they are and how they're being used. This gives you an actionable roadmap to quick remediation.
With open source hygiene, your organization can sort through and deal with the ongoing security threats, because unsafe open source code is highlighted, and remediation paths identified, at the beginning of the development process rather than when the process is already underway.
The smartest software development organizations today are integrating open source hygiene into their software development lifecycle so security is no longer about remediation, but about being pre-emptive and proactive. With this approach, the software lifecycle becomes much more manageable.