Reflections Upon Reaching a 25K Milestone

This week I looked at the WhiteSource administrative dashboard and I saw that our customers now trust us with managing just over 25,000 projects. Wow! We’ve certainly come a long way since we started…

Since we started WhiteSource in 2011, we have broken through many milestones. We now:

  • Support hundreds of customers worldwide, through integrations with 20 different CI servers, build tools, repositories, and other development platforms
  • Track millions of open source projects, in 20 different languages, from tens of repositories
  • Contain close to 200,000 vulnerabilities within our database, and also offer options for their remediation.

Open source was originally intended to allow software developers to reach new highs faster by re-using code that others had perfected before them. But, in an effort to keep open source “open”, some popular open source licenses became very restrictive, (especially from the GPL family) regarding the conditions a user had to follow once a component with a particular license had been integrated into their software.

These demands collided with the objectives and business models of commercial software vendors, and worse, their lawyers, whose response made the life of developers that wanted to use open source a lot harder. Some of the most advanced software vendors even went as far as completely prohibiting the use of open source. Others just demanded that every release is thoroughly inspected for open source components that carried a restrictive license. However, this inspection process could often be long, resulting in unacceptable delays, and riddled with inaccuracies concerning license identification.

How It All Started

Back in 2011 when we started, the gold standard for managing open source components was to periodically scan the code of your software products, looking for “snippets” that resembled parts of known open source projects. This often resulted in thousands of alerts, 99.9% of which were false positives, which you then had to comb through until you could safely sign off your application to be released. Of course, companies were only doing this heavy lifting once in a blue moon, e.g., before a new release.

Can you imagine this happening now? Of course, this approach was only adopted by engineering teams at the largest companies, often because they were forced by their legal department against their will. Who else in their right mind would want to slow down their release cycle and subject their engineers to such a painful process? However, release delays caused by code-scanning was only half the story. This open source management method also meant organizations were unable to analyze components before they were integrated into their products, meaning they had to spend fortunes fixing/replacing integrated components with security vulnerabilities, quality issues, or restrictive licenses.

Oh, and then there were M&A cases. Lawyers again, but this time from the acquiring company, asking for an “open source scan” before the acquisition, as part of the technical due diligence process. And then the engineers at the company to be bought had to spend many sleepless nights going through their code, justifying every open source alert in the pages upon pages of reports. And ultimately, if their organization’s open source usage was found to be incompliant with the buyer’s open source policy, there was always a chance that the deal might fall through. This experience is actually how we, WhiteSource’s founders, came across this issue.

We sold our previous company (Google us to find which one), and were put through this brutal process, not to mention the fear of “what if the deal falls through because of rogue licenses…”. Having gone (successfully, but with a lot of pain and risk) through this process ourselves, we realized that there had to be a better solution than the clunky code scanning technologies on the market. Why not have a seamless service, continuously monitoring which open source components are being introduced by developers, and raising a flag when something is not right or violates your company’s policy. Clearly, code scanners take too much time and effort to have any place in an agile development process.

Developing an Agile Solution for Open Source Analysis

So, after putting our heads together, we developed WhiteSource – a service that can be effortlessly retrofitted into any modern SDLC by plugging into the tools already used by developers. WhiteSource automatically and seamlessly monitors open source components, and alerts you only when something needs to be reviewed or tended to. And this not only goes for license issues but also for security and quality issues as well.

At first, it was difficult to convince customers to use WhiteSource. Many of them had been burnt by the old “code scanners” and didn’t want to hear about us unless our proposition came in a certified letter from legal. It helped that we were able to show them that WhiteSource took less than an hour to install and produce a fully open source usage analysis, and from that point on, they didn’t need not do anything unless an open component needed attention. With time, customers started to refer friends to our “effortless” open source analysis tool, and our community grew. I still cannot believe we’ve hit 25K project. Wow!

When we started WhiteSource, analysts were still recommending companies to use the old scanner-based technology. Also, some legacy vendors kept warning customers that the “WhiteSource kind of analysis is not good enough”. But over time, we started to see more and more customers realizing the benefits of our new approach. Many came through referrals from existing customers that “saw the light”.

Expanding Our Solutions

At some point, some of our customers started presenting WhiteSource reports in response to technical due diligence requests, e.g., in M&A situations. Since they already had WhiteSource installed, they were able to print out their complete open source inventory at a single click. At some point, we stopped counting, but by now we probably have had a few tens of acquisitions being facilitated by WhiteSource reports. Some very large and known brands, some very small startups.

Since then, our service has grown and matured substantially. We now:

  • Cover most languages – We quickly learned that this is very important because even die-hard Java companies still have components in other languages, e.g., JavaScript or mobile languages.
  • Integrate with most development tools using native plugins, further reducing the time needed to set up WhiteSource.
  • Provide tools that give developers security, quality, licensing and policy information even before they download a new component.

All this has allowed organizations to further shift left their security. Something which is a huge cost saver in any SDLC!

However, the defining sign that WhiteSource’s approach to open source management is the future started to appear last year. Forrester was the first analyst firm to put out a Software Composition Analysis (SCA) “landscape” report in late 2015, and they’re now working on a “Forrester Wave” report – a clear indication that the area we pioneered in 2011 is now considered a field of its own.

As legacy code scanning vendors watched their customers abandoning their technology in droves, some decided to switch to the new technology, whereas others folded into bigger companies or stopped developing their products altogether.

The future looks bright for WhiteSource. As our approach to open source management and security becomes the standard, we see a growing number of vendors of complementary products seeking to integrate our solution into their products. For example, Static Application Security (SAST) vendors, specializing in identifying vulnerabilities in users’ own code, add WhiteSource to identify and report vulnerabilities in open source components. Docker security solutions use WhiteSource to scan for vulnerabilities in Docker images. Repository vendors (source and binary) add WhiteSource to verify the security and quality of their content, as well as of new components being added to the repository. DevOps and ALM vendors add WhiteSource as part of their chain of automated tests. And the list goes on.

Meet The Author

Subscribe to Our Blog