With all stories, it’s good start from the beginning.
The idea for WhiteSource came about when our founders, Ron Rymon and Rami Sass, were going through the process of selling their previous company. Unsurprisingly, the buyer needed Ron and Rami to complete an open source scan as part of the technical due diligence process. This was needed to identify all the open source components contained within their code, as well ensuring all open source licenses were compliant with the buyer’s open source policy.
Unsurprisingly, due to the lack of an automated inventory solution, this took a lot of time and effort, as developers had to manually go through every open source alert in pages and pages of reports. Due to this, Ron and Rami decided to develop a solution which enabled organizations to gain a complete and 100% accurate open source inventory report at a click of a button. And so WhiteSource was born.
The automated inventory feature proved itself to be invaluable when one our potential customers required to us go through a registration process so that we could become their official vendor. So, in one-click, we were able to provide a complete BOM list of all the open source components contained within our software, as well as a complete list of all of our open source licenses. Due to the accuracy and speed of the report, we successfully completed the eligibility process, and so we became our customer’s official vendor. It just goes to show, lessons from the past have the potential to shape success in the future.
Here at WhiteSource, we’re a big fan of open source, but we realize that there are certain risks associated with open source usage, such high security vulnerability severity and certain licenses, such as those of the copyleft variety. So, before we developed our automated policy enforcement feature, our developers needed to manually check the CVSS severity score of every single open source component before it was integrated with our product, as well as delving into its open source license.
As you can imagine, this had a negative effect on our deployment rate. In fact, in the early days, we were only able to deploy once in a while. And due to human error, sometimes when we did deploy, our product contained high severity vulnerabilities and undesirable licenses. This caused headaches for ourselves and customers alike, as our developers needed to go back to the code base, rectify any issues, and redeploy.
Due to this need, we developed our automatic policy enforcement feature, which allows our team to define and automatically enforce our open source policy. This means we can determine what components to automatically reject, approve or which ones need manual approval. Now, through our Jenkins plug-in, every time we run a build, WhiteSource automatically fails the build or sends an alert to the relevant person depending if any component is blacklisted or requires manual approval.
As we know, sometimes it’s not possible to prevent vulnerable components entering your products, as vulnerabilities can be discovered after integration. Subsequently, in September 2015, our researchers learned about vulnerability CVE 2013-4204, which affected a component named GWT (version 2.50). Not only had this vulnerability been around since 2013, but the component it impacted was central to the framework we used to build our UI. Therefore, through this somewhat difficult finding, our team learned the value of being updated on vulnerabilities affecting used components proactively, allowing us to remediate as soon as possible.
For example, we found spring-web version 3.2.0 was affected by a vulnerability. With our automated remediation guidance feature in place, we found that the secure version to go for was 3.2.8. This meant our developers didn’t need to waste their time trying out the seven versions in between, to find out if they were secure. Using this feature, our developers always know the best method to solve any security issue, without having to manually research the solution themselves.
WhiteSource has just released its own selection tool plug-in to enable development teams to identify and select high quality open source components when browsing online repositories such as MavenCentral. Here at WhiteSource, our developers have been using and testing the tool for a while, but not long enough. In fact, if we had had our selection-tool feature in place when our developers downloaded component GWT version 2.5.0, they would have automatically seen it was impacted by a cross-site scripting vulnerability, meaning they could have chosen to integrate a newer version, or select a different component entirely.
As we have just released our selection-tool plugin, our customers can learn from our mistakes.
Even before downloading a component, our customers can drill down into component’s quality, discovering any security, license or software issues, and even confirming if it complies with their organization’s open source policy. This means they can identify any problematic components from the earliest stages of coding, allowing them to save time and effort when selecting the best components to integrate, enabling them to produce high-quality products faster.
Ultimately, with the many automated open source management features on offer, WhiteSource has proved itself to be an invaluable tool regarding how our organization builds its product.
Now that we’ve just released our selection tool, adding a further layer of quality to open source management and security, we look forward to our customers reaping the benefits of all that we’ve learned from our open source management journey.