Secure your open source components automatically, continuously, and silently

In this podcast recorded at Black Hat USA 2018, Azi Cohen, General Manager at WhiteSource, talks about open source lifecycle management.

WhiteSource manages open source license compliance and security by integrating into your build process, no matter your programming languages, build tools, or development environments. It works automatically, continuously, and silently in the background, checking the security, licensing, and quality of your open source components against WhiteSource’s constantly-updated definitive database of open source repositories. You never need to halt development or expose your proprietary code.

Here’s a transcript of the podcast for your convenience.

My name Azi Cohen from WhiteSource. Today we will speak about open source lifecycle management which is what I’m doing for the past almost 10 years. Let me start with the explaining or giving a little bit of a background about WhiteSource and how we came out with the company.

Me and two of my partners, founders of WhiteSource, we were all partners in a different company that was acquired by a large American corporation. And guess what? Up till the last moment of the due diligence process, we were still clearing open source components that they kept on discovering in their own code. To be frank with you, we were sure that we are managing the open source component quite well. Well, that was something like 2007, 2008. It’s almost 10 years from now. Things were different, people didn’t use so much open source in their propriety code. We felt that there is something better that can be done. That’s how the whole idea about open source management started.

We started the company in Israel, we got some government grants, and we developed the product, and very quickly we started to go to the market and not surprisingly the first client that we had were small software houses, startup companies – 20, 50 sometimes a hundred developers – that were struggling exactly with the same idea, and were looking for a solution.

The only solution at that time that was available to them was what’s called code scanner. A solution that will go scan the code line by line and look for prints or fingerprints of open source. But those kinds of solutions have a lot of false positives, and when you start using more open source, you get too many false positives. Who’s going to handle that?

Also doing that at the end of the lifecycle of the development. Try finding a piece of open source so late in the cycle, it is very expensive. We decided we would like to go and do something else. We decided that we would like to shift left to make sure that open source will be discovered as early as possible. And that policy of do’s and don’ts, accept, don’t accept, would be applied at the moment that developers are selecting the open source.

Startups and small companies really like that, it saved them a lot of money. It helped them to develop very quickly, and we were doing quite well. We were growing very nicely. We did more business. Slowly the number of clients that we had grew up, we expanded the team, but then a big change came something like 18 months ago. I don’t know if that’s Equifax case or something else, but the awareness of the need to manage open source at the large enterprises became a mainstream issue as well. And since then we have seen a huge spike in sales, not only from small companies but to very large high-end companies. Fast forward, today we have more than 500 clients. We triple our revenues year over year, for years. We have huge clients like Microsoft that uses us across the board, SAP that uses us across the board, and of course smaller ones. We are still very friendly to small organizations.

Obviously as an innovator in this market, we are not seeking one set of technologies and that’s it. We keep on innovating, we keep on pushing, more cool stuff that can help the developers to achieve much more. A few examples: we have a tool called Web Advisor, a plug into the browser that helps the developers as they go out and seek for new open source components, to know upfront even before they selected it, if it will fit organizational policy, if it will be accepted once they push it in.

So, at that point they can know immediately if they should use it at all or not, even before wasting a second on trying to use it. It will also show them if someone else is using it already in the organization, the number of vulnerabilities that they have. So, we push all our knowledge into this decision point – the far left point that anyone can imagine.

Companies today have something like 60 or 80 percent of the code is consisting of open source. Obviously a lot of components means a lot of vulnerabilities. Nobody’s going to fix everything. And remember vulnerabilities keep on coming. You fix something today, two months later there might be a new one. Those people asked about what’s relevant, because if I’m using this piece of open source that there’s 10 vulnerabilities maybe I’m not using all the functions and therefore I’m exposed only to two or three of them. We created a new module called Effective Usage Analysis that does exactly that.

After you select a piece of code, bring it in, you can actually scan it with our Effective Usage Analysis model and find which are the vulnerabilities that are effective or relevant, and that will allow you to reduce it something by 70 to 80 percent, and be able to focus on specific ones that really matter.

Another feature that we’re doing right now and we just released is called the Vulnerability Checker. We have many clients that are in a very early stage, or prospects that don’t know yet if they need something like that. They don’t know how vulnerable their system is. We basically look at all our clients and check all the vulnerabilities, and find which are the ones that are most common, and also which are the ones that are being fixed very quickly. That means that there’s a high risk. So, those clients that I’m not sure whether they should stop, or when they should stop, or if they should stop, they can download this tool and just scan. Use it to scan quickly their own proprietary code and open source and find if one of those top five is there. Obviously if it’s there, maybe we need to do a bigger scan right now and check what else. So, it helps even the ones that are at the very early stage, don’t know yet if they should move on to maturity level and take up a software composition analysis like ours, or they should do it later.

If you want to know more about WhiteSource, I think that the best way is to go to our Web site whitesourcesoftware.com, we have an amazing library of content down there, that can be available to anyone, it can explain why, the how, what are the alternatives, what is the cost saving. People keep on downloading those all the time and we have fresh stuff coming in every day. Thank you very much.