Ep. #54, From Crisis to Creation with Rami Sass of WhiteSource

Brian: Welcome to another installment of JAMstack Radio. On the line I've got Rami Sass. Rami, do you want to say "Hi?"

Rami Sass: Hi, and thank you, Brian, for having me here.

Brian: I'm excited to get to know about you and about WhiteSource and how that got started.

Do you want to explain a little bit about yourself and how you got here as CEO and co-founder?

Rami: Sure. It's mostly by accident, I think. By having a lot of very good fortune.

This wasn't really much of a planned venture, and we didn't think it would get so big when we got started.

We're actually three co-founders and we know each other from a previous company that was acquired in 2009.

Then during the acquisition, we were required to provide a very detailed report of all the open source components that our engineers were using in our development of the software.

Obviously, we didn't have such a report, and we actually had no clue what our engineers were using.

I was the head of engineering at that company, and we spent a whole month during the most stressful part of the due diligence just doing research and tracking down all of these packages.

They're what's called "Transitive dependencies," and finding them online and figuring out what their licenses were, and if they had any known issues associated with them.

Then by virtue of blind luck, there were no major issues and the transaction went through and everyone lived happily ever after.

But it was very apparent that there was a big risk associated with this unknown, this huge unknown that you are carrying with you. The developers are just pulling these packages online and pushing them into your own software and then redistributing them to customers in your business.

The acquisition was 2009, and then we got back together again in 2011 to start WhiteSource.

Brian: OK, so you were all working at the same company, working on a feature to discover vulnerabilities and packages, and then what's the difference between 2009 and 2011?

What brought you back together to work on this?

Rami: The experience of the acquisition.

The previous company was a completely different company, and it was around identity management which is another aspect of security, but completely different angle.

The experience around the acquisition were we all of a sudden found that we had these 250 dependencies, these are packages like open source packages that our software was dependent on, that we had no idea about.

It seemed like a very big gap for any company to carry with it.

There was a lot of associated risk with that we managed to avert, but it was just luck and we had zero control over it.

Brian: It makes sense, definitely. But now we're here and you're a well-known-- As far as in our security space, when it comes to open source you're well-known and people are aware of what WhiteSource is doing.

I guess on the website I'm looking at, it's "The simplest way to secure and manage open source components in your software."

What is the approach that WhiteSource is taking to figure this out?

Rami: Really back in 2011, we pioneered the approach of looking at open source as components rather than as a code.

There were some pre-existing tools that we were trying to analyze what open source you were using, but trying to look at your entire code base and find if there are any snippets of code that look like they could have been copied from open source.

But we were the first to come in and try and look at the way the developers were actually using open source, which is by downloading a pre-packaged piece of software and then calling it through documented APIs basically, and then started looking mostly--

Or, initially we were looking at the build phase, which currently is what's called CICD more commonly.

During build time, we analyzed the bill of material of all of these packages as they were being compiled or built into your own software.

Then once we had this bill of material, we had a very large database on our central service of a lot of metadata that we continuously collect about these packages, that we can then enrich the report based off of.

Primarily, the main point of interest is whether or not these packages have any known security vulnerabilities.

That was the very beginning. This is a very naive initial implementation of the service, and today it's much more advanced.

Brian: Awesome. I'm curious, who's the target audience for a tool like this?

I imagine the way the development world works is so many people are using open source as the "How to build" their projects.

You mentioned that this is something that comes at build time, that you check on this.

Is this just limited to open source, or what about packages that I'm using internally from other repositories or projects or tarballs?

Rami: You can definitely use the tool to track these, but we will not have any meaningful information about them.

Brian: Gotcha.

Rami: But for open source, we have a lot of meta data collected and continuously curate additional information, not just about vulnerabilities but primarily about vulnerabilities.

We also offer fixer recommendations and a whole host of management and privatization, and even automated remediation capabilities around these vulnerabilities.

You'll get a lot more value around the open source packages.

Brian: OK, yeah. I guess the value really of WhiteSource is that database of open source metadata.

Rami: Yes, that's in the heart of it. But today we are actually providing much more advanced services.

I mentioned one earlier about the ability to automatically remediate vulnerabilities in many cases, not always but in many cases.

Another advanced feature that we have, we call it "WhiteSource prioritize."

Which is the ability to not only identify the vulnerabilities in the open source package, but also look at your code and see if you are exploitable to those vulnerabilities.

Brian: Gotcha.

Rami: Which is very significant, and we have many thousands of real projects using this technology in production.

What we found is that on average, only 15% of vulnerabilities are exploitable form your code, and the other 85% are still there.

You're still dependent on the package, but you're just using some other method or some other functionality of that dependency and you're not "Stepping on the vulnerable method."

It's really not applicable to you, and you can maybe worry less about it or worry later about that and invest your resources and your time and focus on the 15% that are actually applicable.

Brian: Yeah, I was just going to add that I'm aware of partnerships w ith some major companies like GitHub, but I'm curious if there is also any other partnerships with security researchers.

How are these vulnerabilities being discovered? Are you sourcing that information from another partner, like Hacker One or whatnot?

Rami: Not directly. We are collecting them form a plethora of publicly available sources.

Primarily the NVD, the National Vulnerability Database from NIST.

That is a very large source for vulnerabilities, but there is a long list of other sources as well.

Many of them are more niche, small security advisories around specific programming languages or specific frameworks.

Also, GitHub.

The commits and the comments about security vulnerabilities being discovered or being resolved, like when someone pushes a commit and says "I fixed this security problem. That's another source for you to know that there was a problem in the previous version."

Brian: One of our listeners on the podcast are developers at companies and engineering managers and individuals who aren't pushing code on a regular basis, and maybe are already relying on some public announcements on Hacker News or on Twitter.

How does someone leverage something WhiteSource today to start engaging into some of this information?

Rami: There are many different ways. But before I touch on that, let me just touch on your point of trying to do that on your own or manually.

I think the biggest problem there is that it's very difficult just to even understand the full list of the dependencies you really have, because each open source package you pull in a piece of software in its own right. It has dependencies or its own.

It also depends on other libraries, which they also in turn can depend on additional libraries and so on and so forth.

There is this hidden transitive tree of dependencies spanning from this single library that you brought in to help you achieve some tasks, or feel some functionality that you very likely are not aware of or don't actively track it.

If you as a developer, let's say, only use ten or fifteen libraries, you may actually under the hood be using 100 or more just by way of these transitive dependencies bringing them in and putting them behind the scenes.

I think it's not reasonable for anyone to try and think that they will be able to manage that themselves just by looking at vulnerabilities being disclosed on some source, or even if they are very diligent.

Having said that, there are a few ways. We have a freemium offering, we call it the WhiteSource Bolt.

It's available on various marketplaces in the GitHub marketplace in Azure DevOps and elsewhere.

You could also start small with the WhiteSource basic offering and grow from there , and normally our service covers the entire process and workflow around tracking and managing the open source components.

Our solution is more intended for the entire organization.

It's very easy to set up, but the value is fairly broad and immediately gives you visibility, control, reporting, policy enforcement capabilities, dashboarding and tracking.

I think it's much more oriented towards the organization and the broader needs, and not just for individuals.

Brian: Excellent. I was just looking at the product page and it's saying it does focuses for organizations, but also considering that I think we talked a lot about packages but I also want to know more about how vulnerabilities work with things like containers.

Because I know now more and more we're pointing to packaged environments as opposed to just packaged code, does WhiteSource also cover something like things that are hosted on Docker hub are pulled in from all those other places?

Rami: Yes. Since you bought the topic of packages, let me just make it point here.

We as a company cover practically all the programming languages, over 200 different programming languages.

Many of these languages actually don't have proper dependency management capabilities, and many of them do not necessarily distribute the open source as packages.

We also have the capability of finding open source in loose files, loose source files.

Let's say if it's C or C++ or PHP or native JavaScript, then we are still capable of identifying files that were pulled from open source repositories and tagging them as such and identifying their vulnerabilities and all of the other meta data that's associated with them.

Having said that, we also have the capability of scanning Docker containers as images, basically figuring out their content.

We do that twofold. One, we would know what operating system packages have been installed.

If it's a boon to Alpine that had some packages installed right in the operating system, those are also open source.

These open source operating systems have their own known vulnerabilities which we track and can report on, and then we would look at all of the other packages or files that have been installed inside the image and provide you with all of the information that we've collected about them, including vulnerabilities and everything.

Brian: Cool. I want to take a step back to one thing that you mentioned about this open source vulnerability database, and maybe take a step aside from WhiteSource and talk more about the security community itself.

Because I think this is something I don't really spend much time or knowledge in, and I do rely on tools like WhiteSource to care about this more than-- I care about it, but I just don't have the information.

I'm concerned for my listeners who are listening and th inking, "I'm just writing a little bit of JavaScript. I have a marketing site here. How much am I really exposed?"

How is databases like this being developed in the open, and where are areas that people can also outside of WhiteSource know of security researchers or even potentially be more informed of security just in general?

Rami: There are many sources online and offline, I know there's this Corona outbreak right now that stops local events or any kind of events from happening.

But there's a lot of very good meetups and the places you can go and attend. There's a long list of very good events, topical events about security.

I'll just name RSA and the Black Hat are these big annual conferences that always have top notch speakers talk about the latest trends in these areas.

They're very informative and educational and serve as a very good source of information, and can then point you if you want to drill deeper into specific areas of interest.

Those are the places that I go to and I enjoy very much, and that I use to stay up to date.

Brian: Excellent. I even see there, I'm sure there is a few newsletters that people can probably subscribe to and keep informed.

Rami: OWASP is a very good community and has a lot of sources, and newspapers and have I think even online events now. Definitely a very good to be a part of.

Brian: You said OWASP?

Rami: OWASP, yeah.

Brian: OK. I appreciate this conversation, and it's got me intrigued to start being more proactive in security vulnerabilities.

At the moment, what I take advantage of is the GitHub automatic security notifications.

The way I understand it is that there is, as you mentioned, the central database that alerts the user if you're NPM package or your Ruby package has some sort of vulnerability.

Which is super helpful, and I think it's doing a really good job of raising the bar and awareness.

I think I see with WhiteSource if you really want to start digging in and being even more proactive with security on your site, it's an opportunity to definitely check out.

Rami: Just as a side note, we power some of these alerts with GitHub.

GitHub is a very good partner of ours, and we work with them very closely around security.

We really appreciate all the effort they are doing around empowering the open source community and providing this information, and we want to also facilitate that and work together with them to bring more awareness and to help engineers make sure they safeguard themselves and their projects against potential breaches.

Brian: I understand you have another-- I guess I don't know if you are integrated or partnered, but GitLab as well, which is also good to know that you cover the open source space and making sure that information is available to anybody who wants to read it.

Rami: Right, yes. Absolutely. That's correct. We also work with GitLab.

Brian: Awesome. Rami, what I do want to do right now is transition us to picks.

These are jam picks, things that we're "Jamming on," things that keep us going.

We're in very interesting times at the moment where a lot of the world, especially developers, are working from home.

That was a norm before, but it's even more of a norm today.

If you don't mind, I'll go first with my picks and then I'll shoot over to you if you've got anything you're jamming on recently.

The first thing that I'm jamming on right now is the Nintendo Switch.

I don't think I've actually given this a proper pick in the past, but I know it's come up a couple of times on the podcast--

but I've had a Switch for I guess roughly over two years now and I haven't really dug too much deep in the catalog of games.

But because I have so much more free time and I'm not really going outside at the moment I've been really having a lot of fun with in a particular game with me and the family, which is Overcooked 2.

Overcooked is this-- It's a game where everybody, I think it's up to four or eight players if you do online.

The goal is to cook, basically you're chefs and you have to cook orders.

Honestly, it kind of feels like a mobile game, but for the most part it's pretty much on console and PCs.

I just highly encourage anybody who's spending a lot more time with their family as of recent to check it out on whatever platform of you're choice.

I mentioned the Switch, but that's not the only platform that's available for it.

Honestly, I haven't really done too much else other than play Nintendo and answer emails.

That extends the amount of picks that I have. Rami, do you have anything that you're jamming on?

Rami: Yeah. I just have to tell you because it's so funny, Overcooked 2 is actually one of our favorite games as a family.

Brian: Nice.

Rami: We have a Switch at home and we play it with the kids and we have a great time around it.

They love it and it's great fun as a family, really. It's one of the greatest.

It also takes me back to my childhood where I had very old versions of Nintendo back in the day, and we'd play Mario Kart and all of these games, especially now when we are spending a lot of time indoors in the house.

The family is all together, so it's really funny that you brought that up of all things. Definitely, we love that game.

Brian: The one other thing I'll add too as well, I guess I'll add this as a pick. I've been livestreaming with my son.

We created a private YouTube channel, so it's unlisted videos and an unlisted playlist. But we've been sharing them with our family and friends, just as a way to show them what we're doing while hanging inside.

We've been recording ourselves playing Mario Kart every morning for 40 minutes.

We set a very strict time limit, because I don't want to play games all day.

But I'm more than happy to experience that with my son, because I think now all these younger kids are growing up with all these smart devices.

I don't know how old you are, but I didn't grow up with a mobile phone or anything like that because they didn't exist.

But now you're able to stream directly from your console to YouTube and record and stuff like that, so I think going through that process of figuring how that works with my son because he watches a lot of YouTube streaming and video games as well.

It's been a blast to figure that out as well, so I highly recommend people explore that.

Rami: Definitely. If I get a pick, I'm now bicycling to work which I think is a great alternative to public transportation now that it's not very recommended to share closed spaces with others.

It's a double benefit, also you can very safely keep social distancing while also getting some exercise, which we don't really get a lot these days.

I also would highly recommend anyone that's a reasonable distance from their workspace to try that out.

Brian: That's an excellent pick. Unfortunately, locally we've shut down all non-essential businesses.

So grocery stores and bakeries, but we were literally going to pick up a new bike for my son on Monday.

But the bike shop is actually closed at this point so we look forward to the day where we could buy a new bike for my son and we can actually get back outside and doing that, but until now, I will live my dreams through you Rami.

Rami: OK. I'll take some pictures and send you.

Brian: Excellent. I'll look for them on Twitter.

Rami: Sure.

Brian: Rami, thanks for sharing your pick and sharing more about WhiteSource and security and how people can actively engage and be more informed on things like vulnerabilities.

Listeners, keep spreading the jam.