By blind luck, we were fortunate to find no risky components in our software. However, it occurred to us that it was a risky and unnecessarily time consuming process, even though we were not doing anything that was not common practice. Every commercial software being developed has open-source in it which is not being carefully monitored. This is a big gap in the market, and to bridge that gap, we started WhiteSource in 2011. Around that notion of providing better control over what open-source goes into the proprietary software, the company started with all the normal startup issues. We started in an incubator, moved to product market pitch sales, and continued growing gradually from bootstrap to being self-sustained. During 2016, market dynamics had shifted, and the rise of awareness to security and vulnerability took off. We started getting a lot of demand, more than we could handle. At that point in 2017, we identified that the opportunity, and started a funding round. It was led by 83North, which is a very prominent Israeli venture capital with a strong presence in the Silicon Valley, and Microsoft also joined as a strategic investor. Since then, we have continued to grow and today, with over 100 employees and 500 customers, we have a large presence in the US; we have offices in New York City and Boston, mostly doing sales in North America, and an engineering and product development team which is located here in Israel.
What’s unique about WhiteSource?
Our product was the first ever to provide continuous, automated control and monitoring of all open-source components consumed by software engineers and embedded as part of their commercial software. It’s very easy to deploy and is a lightweight agent. You can integrate it within minutes into your existing pipeline. We support all development environments and servers, so it’s virtually minutes before you can start seeing reports and results about the open-source components that you are using, and which are vulnerable. We have extensive coverage of over 200 programming languages, frameworks and environments, which is the broadest available in the market today. We divide the world into programming languages that distribute open-source in binary format and sort format, and we cover both types extensively and accurately. We have a very accurate system. We can identify all open-source files that go into your commercial software and match the vulnerable files. Both are not trivial tasks, and we have developed an automated system to do the matching and improve that process to make our system very accurate. When we say you have a vulnerability, you definitely do have a vulnerability because: We are in the process of launching our third generation software composition analysis, a market of open-source monitoring and management. It has the ability to identify in your proprietary code where and how you make calls to open-source components, and then identify the calls in your proprietary code that end up causing vulnerable open-source. That enables you to prioritize the vulnerabilities that you want to handle first based on whether or not the vulnerable components have a real, direct impact on your product. We tell you exactly which vulnerable open-source components have relevant impact on your software. We call this Effective Usage Analysis. We analyze the parts of the open-source that are affecting your code, and then help to trace them down to the line of code, making it easier to work around the open-source vulnerability. It will be released in September and has been running in beta for two months and getting fantastic feedback; it’s the next big step in this area.
What is the problem with open source security as opposed to proprietary code?
Open source is not more vulnerable, it’s vulnerable in a different way. When you write mistakes your own code that lead to a vulnerability, you are the only one who knows about it. They normally don’t make it public. You have control over your code, and you can fix it directly and be in charge of it. On the open-source side, almost always the vulnerability will be publicly known before you know about it, and you certainly won’t be able to solve it yourself. You have to rely on the open-source community to rollout the fixes and patches, and implement them in the way they instruct you. These are two different types of vulnerabilities that require different toolsets. Open source vulnerabilities are much more prominent and get more attention from hackers because they can learn about them from publically available external sources and try to exploit them.
How do you see the future of Open source?
Today, open-source is already the majority of calls in commercial applications, and only a minority share is proprietary code. In the next few years software engineering teams will use tools to control the use of open-source before writing a line of code, the same way that they do now for proprietary code. They will have various servers and systems in place. In five years, the same level of control and attention given to proprietary code will be given to open-source code.
