Managing Open Source Vulnerabilities

Open source has come a long way.

Open source components are the building blocks of arguably every organization’s software. According to Stack Overflow’s 2018 developer survey results, nearly half of professional developers contribute to open source projects, and 40% listed contribution to open source software as part of their non-formal learning background. Recent GitHub research results showed that a whopping 72% of users said that they always seek out open source options when evaluating new tools.

As open source software continues to eat the world, industries and organizations across all sectors and verticals — from automotive to government, telecom, fintech, health services, and everything in between, continue to integrate open source into their platforms and products.

What’s the FOSS About?

Industry giants like Google, Facebook, and Microsoft have become enthusiastic supporters of the Free and Open Source Software (FOSS) ecosystem, contributing to the open source community, and open sourcing big chunks of their code, having realized years ago that sharing actually allows them to source the best developers around to poke and prod at their code and ultimately give it the most TLC they could hope for.

Open source components also provide organizations with popular, free, and customizable resources to help them create and support products within an aggressive time frame to an ever-demanding market.

So far, open source sounds like the magic puzzle piece that will make our most innovative products complete. But — there’s always a but.

Open Source Components: How Well Do you Really Know Them?

In our last webinar with Microsoft and Forrester, WhiteSource polled a group of nearly 200 R&D opinion leaders and influencers from a variety of tech organizations about their open source practices and concerns. The results we found raise quite a few questions about where tech leaders and managers are, in their attitudes towards open source adoption, their concerns about open source usage, and the processes put in place to manage open source usage in their organizations.

Over half of the participants said that security was their utmost concern when dealing with open source. However, when asked how many open source components were used in their products’ code, most guesstimated a much lower percentage than the 60%-80% that most analysts estimate compose the average application. Which begs the question: how much do development teams know about the open source components in their code?

Open Source Security First

Software executives’ awareness of the importance of prioritizing open source security is great news, and not surprising, considering the increasing amount and impact of data breaches over the past few years.

Open source vulnerabilities first came into the public spotlight four years ago with the notorious Heartbleed vulnerability, and in many ways, lessons are still being learned. The infamous, record-breaking Equifax data breach is still making headlines as more information continues to be released about the case.

Clearly, executives are interested in avoiding Equifax-like oversights, where they were hit through a component they did not even know they had. That’s why managing open source security is on everyone’s minds. However, many in the development ecosystem are still in the process of learning that open source security vulnerabilities are a very different creature than the proprietary security risks that they already know how to address.

Open Source vs. Proprietary Security Vulnerabilities

Traditionally, security risks in your organization’s proprietary code are most probably addressed by using SAST and DAST tools to detect potential issues that could be hidden within your code.

Open source components require a different set of tools to meet a different kind of need. Since the primary threat to open source components come from known vulnerabilities that have been made public rather than the dreaded 0-days, then the mission is less about analyzing the bits of code and is instead focused on identifying the components and matching them with vulnerabilities that were reported in various repositories or databases by the open source community.

What Happens to Known Vulnerabilities in the Open Source Bazaar

Many fine folks today invest their time and skills in analyzing and searching for security vulnerabilities in open source projects or researching fixes for them. These may be in-house security analysts, security research firms, or the increasingly popular bug bounty hunters.

When a security researcher discovers an issue, they first contact the project owner. This could be the software vendor or the project manager of an open source project. They might also notify the MITRE organization, a security advisory that will also vet the report, give it a unique ID, and add it to the CVE index.

The project of the vulnerable component is generally given a grace period of between 60-90 days to come up with a fix and make it public. Once a fix is found, or the grace period runs out, the full information regarding the vulnerability is released, usually along with a remediation path.

This information is then recorded in the National Vulnerability Database – or NVD, which will test the vulnerability to check how exploitable it is and come back with a vulnerability score within a few days.

Sound simple? It’s not.

Open source is a bazaar, and information about the vulnerability, as well as its fix, is not centralized in one database. Known vulnerabilities can also be found in various vulnerability databases, advisories and bug trackers — sometimes months before they are published in the NVD.

In addition, these platforms are not searchable by components or versions, so unless you know how a vulnerability was indexed, it’s extremely difficult to find in the database or advisory.

Unfortunately for us, hackers are also familiar with vulnerability databases and advisories. They know that all the information they need is ripe for the picking and that the popularity of many well established open source projects means that one vulnerability can help them hit many victims, and harvest lots cash for hackers.

That’s exactly what happened with Heartbleed, not to mention other familiar and not-as-cute-as-their-names vulnerabilities like StageFright, Ghost (GlibC), ShellShock, Poodle, and Quadrooter. All of them were known open source vulnerabilities discovered in components with tens of thousands of users.

If recent history has taught us anything, it’s that once an open source vulnerability is made public, there are hackers out there racing to reach victims who have been too slow to patch their open source components. Which means if we work in a development team, it’s our job to get to those vulnerabilities and remediate them first.

What’s an Open Source User To Do?

The challenges facing an organization that’s leveraging open source, are clear: it’s extremely difficult for a team to manually track their open source usage and components. The sheer scale won’t allow for it. Even if you do know the code inventory in your product, you still need to follow the updates on open source security, and the information, both on vulnerabilities and on their fixes, isn’t published in one centralized location, rather it is spread throughout the open source bazaar. To top it all off, response time is critical, as information is released to all.

Time for some good news.

The open source community is doing a great job of researching, detecting & fixing vulnerabilities, increasingly backed by resources from some of the big guns like Google and IBM. And the collaborative ethic at the heart of the open source community ensures that once they’re discovered, fixes are published swiftly.

Since open source management has become a priority, there are automated Software Composition Analysis (SCA) tools that can automatically and continuously track your project’s open source components, meaning you no longer have to spend restless nights wondering whether there’s an open source component in your build that is begging for a fix.

An automated SCA tool will do the tedious component tracking for you, alerting you or an admin when a vulnerable component is found, or even breaking the build to ensure a project’s safety, and providing actionable remediation for those pesky vulnerable components.

How to Win at Open Source Security

Like in life, the first step is admitting you have a problem. You know that your team is using open source components, and that means your projects most probably contain vulnerabilities and bugs.

Working with open source components requires its own set of policies and practices. Once you have those in place, open source management can easily be integrated into your development processes.

The DevOps approach has upped the automation game for all of us, and dev teams are learning to track and address issues from the earliest stages of the product lifecycle. Viva la Shift Left revolution!

This approach has proved itself extremely efficient in the open source management game. It requires you to automate your open source tracking from the very beginning of your product’s development lifecycle, using automatic and continuous tools to address open source vulnerabilities head-on.

Moving forward, if you want to start implementing best practices for open source security, follow these three steps: remediate, track, repeat. This will allow you to harness the power of open source without losing hold of the reins.