Risk reduction: 6 Qs about security vulnerabilities in open source software answered

November 27, 2014 Rami Sass

If you are building software, you are probably using open source components.

And if you are using open source components, they may contain security vulnerabilities. Just like any other software.

The good news is that WhiteSource research also shows that over 95% of the vulnerable open source components have newer versions! All you had to do is make sure you know about the vulnerabilities and apply the patches on time. WhiteSource makes this as easy as 1-2-3. Here are some great questions that were asked in our recent webinar (and our answers).

1. Who is taking the lead on making open source safer?

A: Open source software is developed, checked and used by an entire community. That in itself makes it potentially safer than commercially developed software which is developed, checked and managed by a single entity.

Recent events, such as the disclosure of the Heartbleed security vulnerability, have raised concerns about the ability of open source communities to continuously check and fix the software they develop. To address this concern, several of the world’s leading software companies have decided to allocate resources to improve the development and maintenance of open source components.

In addition, companies like WhiteSource are helping organizations to use open source responsibly, tending to both licensing and security issues. As our study shows, this makes for better and safer software.

2. How is it possible to stay informed about changes, updates, bug corrections or newer versions of all the different components?

Information about security vulnerabilities, bugs, patches and new versions is published in online repositories.

However, since you probably have 100s of open source components in your code, it is almost impossible to check these repositories manually on a continuous basis for all of your components. WhiteSource does it for you: we create a list of all of the open source components in your software, and update you when new vulnerabilities and versions are announced.

3. How can we bridge the gap where different OSS may be called different names? This occurs even in NVD or other ‘official’ sources of security vulnerability.

That is indeed a challenge and WhiteSource decided to face this challenge - we developed an automated system that cross-matches vulnerabilities with specific components using clues in both vulnerability data and component data.

4. What is the difference between security code scanners and your offering?

There are several key differences:

• Code scanners look at the in-house developed code, and are less applicable to open source components.

• Code scanners look for suspicious patterns and report them. As there are many of those, the result is a long list of warnings, of which some are false.

• WhiteSource reports on vulnerabilities that were discovered in the end product. This also means that WhiteSource does not generate false warnings.

• WhiteSource alerts on actual vulnerabilities that are known to be exploitable whereas scanners alert on potential vulnerabilities that may not be exploitable.

5. Analyzing dependencies to measure the “net” effect of vulnerabilities is important. How it’s being done in your solution.

When WhiteSource analyses open source components, it also checks whether these components rely on dependencies. It then analyses the dependencies too. The result is a full inventory of open source components and their dependencies, including the vulnerabilities found in any of them.

6. What sources does WhiteSource use to determine if and when Open Source projects and their components have vulnerabilities. For example, do you scan the code yourself, or simply wait for vulnerabilities to be reported to OSVDB or US-CERT? Do you use other sources?

WhiteSource does not scan the code. WhiteSource recognizes the open source components in the software, including their dependencies. It then continuously checks various online repositories for vulnerability announcements and fixes.

We believe that for an engineering organization with software containing hundreds of open source components, this is the only practical way to keep track of all the vulnerabilities and know about them on time.

Previous Article
Engineering Executive – the Gifts you Should Get for Yourself
Engineering Executive – the Gifts you Should Get for Yourself

It’s the holiday season and the shopping has begun. We suggest being proactive about it and getting yoursel...

Next Article
Infographics: why open source is great if you use it right
Infographics: why open source is great if you use it right

As a result of the attention Heartbleed and Shellshock received, many in the software industry questioned t...