Software Security Gurus Webcast Episode #10: Rami Sass

Matias Madou:
Welcome to the Software Security Gurus Webcast. I'm Matias Madou, CTO and co-founder of Secure Code Warrior. This webcast is co-sponsored by Secure Code Warrior, and for more information, see www.softwaresecuritygurus.com. This is the 10th in a series of interviews with security gurus, and I'm super pleased to have with me today Rami Sass. Hey, Rami.

Rami Sass:
Hi. Thank you for having me.

Matias Madou:
Great to have you. So do you mind sharing a few words about yourself?

Introduction:

‍

Rami Sass:
Sure. Absolutely. I'm basically a software engineer by training and history, and I'm one of the co-founders and CEO of a company called WhiteSource, and have been doing that for the last nine years. So from inception all the way to we are now well over 200 people worldwide, the customer base, and doing pretty well.

Matias Madou:
Nice. I thought you were 10 years old, so?

Rami Sass:
Nine and a half.

Matias Madou:
Nine and a half? 10 years is coming up. That's going to be a big celebration.

Rami Sass:
Yeah, the decade is coming.

Matias Madou:
The decade is coming.

Rami Sass:
Yeah.

Matias Madou:
Absolutely. So you have a decade of open-source experience, and that's exactly what I would like to dive into today if that's fine with you.

Rami Sass:
Absolutely.

When it comes to open source components, who is responsible for security?

‍

Matias Madou:
So open-source. I would say it's everywhere. Like today, I think it's no longer possible to write a piece of software without using open-source components. At the same time, I was actually wondering about the people in an organization that really care about security problems in open-source because it doesn't seem to be developers, I would say, because developers are like, "Well, if I don't have to code it myself, I'm happy. It works." Then, I was thinking it should be AppSec. But I looked at OWASP Top 10, and it's number nine, and it came in very recently. In my mind, if it's not in the top three in an organization, well, no time. We only have limited time and budget. So my question is like who really cares about open-source and vulnerabilities, and be more so like who should care about these problems?

Rami Sass:
Right. So very broadly speaking, everyone cares about it because when something... If you are either a software vendor or produce software for your business in any capacity, then if you are ever in a position where your software gets hacked, or there is some kind of a privacy leakage or data breach, or something of that nature, then you can be sure that everyone in that organization is suddenly going to care a lot about that, the vulnerability, and about security, and everything around that. So the people who are worried about those kinds of risks in the company usually care enough to also care about the stamina or security status of the open-source that the developers bring in.

Rami Sass:
You're absolutely right though that on a day-to-day basis, the engineers don't really care that much, and they have a different priority. So they need to get some job done, right? They have a feature to develop, or a bug to fix, or something that they've been assigned to do, and they want to get that done as quickly and as high-quality as they can. Security is often in the backseat of that, but you will find more and more that the managers care, the VP of engineering care, people in DevOps care, security officers care. We see more and more over the last two, three years, I would say, the emergence of a new role in many, many enterprise companies and also increasingly in smaller-sized companies of something called a security architect, which is something of a mix of security and DevOps.

Rami Sass:
So very often, these individuals will be situated inside the DevOps team or somehow more broadly in the engineering organization or engineering division, and they... The main thing that they care about is the security of the software being developed, and how it's being deployed, and the environment in which it runs. Those people care deeply about the security of open-source, which makes up a very large percentage of the software that ends up running and servicing their customers.

Matias Madou:
So essentially, the way you just explained it makes it clear to me that open-source is something very tangible, like SQL injection or injection problems to managers or to architects because it's not very tangible. While open-source, well, you take a component from the web, and you add it to your software. It's probably very easy to understand for people. So now, I understand better that managers and security architects, why they care more about open-source and why they come to people like you or companies like WhiteSource to figure out like, "Hey, what can we do about this particular threat?"

Rami Sass:
Right. The problem, so to speak, has two advantages over other problems in the sense that, one, you're absolutely right, it's much easier to understand and to explain. Right? It's easy to imagine what an open-source component is, and how it gets into your organization, and what it can do. Secondly, and this is very good news, it's relatively easy to mitigate, right? It's not that complicated to handle the problem. Right? It's not a hugely complex and like rocket science kind of problem. It just requires some kind of attention. Obviously, I have some interest here, but you need an automated tool to handle it. But again, if you do that, then you very quickly, so it's like very quick time to value, can be in a much better position in terms of the open-source security and move on to worry about other stuff.

Matias Madou:
Yeah. So as long as you don't have any breaking changes, I agree. But I think the moment there's breaking changes when you update or upgrade libraries, I think the developers are more like, "Yeah. The previous thing did work."

Rami Sass:
Right. So look, a big thing in our world and especially in our company, again, I don't want to be too promotional here, but what we found over the years that prioritization is a big topic, right, because you have to start weighing more seriously the pros and cons of doing an upgrade if it is indeed not backwards compatible or if it breaks something. At that point in time, you want to know more about that vulnerability. How serious it is? Does it really affect me? In what way does it affect me? How urgent is the fix?

Rami Sass:
We found, again, relatively good news is that a large percentage of vulnerabilities being found on average in hundreds and hundreds of customers that we've seen over several years are relatively low priority. Right? It's not that easy to tell which ones are the ones that you need to care about most, but if you are able to do that and again, the tools to help you do it, you're in a very good position of not having to run and break your software or at least buy yourself some more time to do it in an orderly fashion and not urgently, immediately as like a production bug kind of situation.

How does the legal department feel about the risks of open source components?

‍

Matias Madou:
So you're touching on a really good point, which is what I see, and where there's definitely a need for a better structure is where legal comes in because quite often, it's very black and white, what they do. They say, "You know what? This particular package, it has a problem. It has vulnerability. It cannot be used." While if you look at a technical level, well, you're using a particular component, but you're not using that, that vulnerable routine or that vulnerable component in that library. But for them, for legal, it's black or white. They say, "No, you cannot use that." But from what I'm hearing is there is technology out there that can easily distinguish between, "You're using this vulnerable component," or, "You're not using this vulnerable component." Now, it's a matter of coupling that back to the legal department. Is that correct?

Rami Sass:
It is correct. It's even more fine grain in the sense that you may be using that component that has a vulnerability, but you are using a safe function of it or a safe method, and you are not touching on the vulnerable part of that component and making that vulnerability not exploitable for you. So there is a very easy distinction. It's not easy to ascertain, but it's easy to understand between vulnerabilities that are exploitable in your own specific software, not generally, versus ones that are simply not exploitable because your code never calls that vulnerable method inside the open-source dependency.

Matias Madou:
I would assume that a lot has been done in the last 10 years around that. Especially now, legal has more eyes on what open-source components are you using. I think, personally, there's still a lot that needs to be done because legal, I would assume, becomes more and more a driver to look into solutions like, "Hey, what kind of open-source components are you using? What are you using? What are you not using, and so on and so forth?" Is that correct?

Rami Sass:
Right. Yes, but look, there are two main drivers where security, I think, is the primary driver today and for at least the last five or six years and by a big margin. Some people, organizations, and companies, and engineering teams care more strongly about security issues, and legal isn't often part of that process. There is another process where open-source also has a compliance side to it because there is a very broad range of different open-source licenses that may be attached to different packages. At that point, legal is more prominent, and would care more, and would be more knowledgeable, and could give you better feedback.

Rami Sass:
Whereas in security, usually, their stance would be, "Look, we have these legal commitments toward our customers that we will not have high-severity vulnerabilities hiding in the software that we deliver," or something like that, but they don't go all the way into understanding that it comes from open-source, and versioning, or whatever. So we see limited interest of legal people in the security side, but very much so in the compliance side, which is another aspect of open-source.

How has open source changed over the past decade?

‍

Matias Madou:
What is the biggest change in the last 10 years? If you look at the last 10 years, if it's not the legal side, what is the biggest change that happened in open-source in the last 10 years?

Rami Sass:
Right. So I will take the liberty of counting it in 11 years because it...

Matias Madou:
Okay.

Rami Sass:
2009 was a big pivotal year for open-source, history speaking, because open-source has been around for, I don't know, 30, 40 years, right? Maybe longer. But for the first 25 years, it was considered something for hobbyists, after hours kind of amateur activity, and it took a long time for companies and especially larger enterprises to start working and adopting open-source. The transition took a while, but it blew up in 2009 where a long list of major software vendors changed their minds about open-source and changed their policies.

Rami Sass:
So companies like SAP, and Microsoft, and Oracle, and a bunch of others around that year changed their no open-source policies. So before that, they had strict, forbidden any use of open-source by their software engineers. Gradually, they started changing that policy and allowing their developers to bring in open-source basically only to find out that they've already been doing that under the hood and not telling them. But it started driving a huge swell of open-source adoption and equally important, contribution.

Rami Sass:
So if you look now versus 10 years ago, you'll find that most of the open-source contributors today are actually coming from companies. They are doing it on company time. They are doing it many times on behalf of the organization. Right? Versus 10 years ago with this, it was much more of a individualized kind of a marketplace of ideas and people coming together ad hoc because they liked some idea or whatever. Now, it's much more structured, and it's much more driven by commercial needs and the organizational needs of these companies who are willing to pay with their employee time to make sure that the open-source projects they are using are well-maintained, are monitored, are supported, and so on.

Rami Sass:
I think that's the major change. The other one I think more minor change is that this surge of adoption of open-source by organizations have also kicked up awareness to the potential issues. Right? So it went from being a messy jungle where no one had any idea what's going on into something that's much more structured, much more managed today, and needs to adhere to the kinds of standards and criteria that are acceptable to large organizations.

Matias Madou:
So let's say the next 11 years. Do you see a major shift going on in the next 11 years too? Because I think right now, we're at, again, maybe a pivotal moment where there seems to be more money flowing to open-source because they are taking such a prominent place in software development. Is that going to continue? Is that going to be even more in the next 10 years, or do you think, "You know what? This is going to stay like it is today?"

Rami Sass:
So I'm not a prophet, and I very...

Matias Madou:
I know.

Rami Sass:
By way of predicting the future, but I think we are very close to actually some kind of a steady state or stable state that is not going to keep changing dramatically over the years, at least in my mind, because open-source by many accounts, and research papers, and everything today makes up something like 80% of a new commercial software project being developed. I don't think it's going to go to a hundred.

Matias Madou:
Yeah.

Rami Sass:
Right? So it will go to 85, maybe 90, but it's not going to go much further than that. So I think we're close to the ceiling of, percentage-wise, adoption of open-source. Obviously, there's going to be much more software in the world in the future, and as a result, there's going to be much more open-source. But percentage-wise, I think the big revolution is behind us. So going from zero to 80% is the big step, and going from 80% to 90% is not that big as a step anymore. On the business models around it, probably we're going to see more.

Rami Sass:
Although there's already been a lot of different open-source-related business models being tried by various companies. Some successful, some not. Some haven't been successful in the past, but are starting to be successful now. We'll probably see more of those, but again, I'm not expecting a huge surge in those. So you will keep seeing them come up, but I don't think there's going to be a big movement in the software world where 50% of companies will start basing their commercial side on open-source project or something like that. So again, there's going to be additional changes. It's easy to predict that it's going to stay on the same trend, right?

Matias Madou:
Mm-hmm (affirmative).

Rami Sass:
So I won't take any risks here and just say, "Yes, it's going to keep on the same trend."

Matias Madou:
Yeah.

Rami Sass:
But I don't think there is going to be a huge transformation in the next 10 years.

Matias Madou:
Yeah. So in that 80%, it's crazy that 80% is open-source. But essentially, the open-source components that are used or backed by organizations and are backed by companies, it's no longer just a group of people that had an idea, and created it, and dropped it online.

Rami Sass:
Right.

Matias Madou:
It's more backed by people. It's more backed by professional services and money essentially.

Rami Sass:
Right. I think it gives them more robustness, right? It gives them more security in the sense that they have prospective futures where they're not going to disappear because a community member who was very prominent is now changing position, and starting a full-time job, and doesn't have any more time to maintain the community anymore or something like that. So having these types of backers gives you more predictability about these projects continuing to exist longer term.

Matias Madou:
Yeah. Yeah, yeah, yeah. All right, Rami. I actually have a final question. I know you have a daughter roughly the same age as my kids, and they start to play with computers. Like my kids, they only play. They do a little bit of programming, but are your kids already programming, and are they allowed to use open-source?

Rami Sass:
So I'm afraid they are a big disappointment to me, my children. I try to converse them into programming, but they are not playing along unfortunately. Yet, at least I promise to keep trying. But my daughter who is eight years old, she's not into programming at all. But she's now starting to gain some more interest around like making. So we build little engines together and little robots that do stuff, like very basic stuff. So maybe that's a good first step. We'll see how that goes.

Matias Madou:
Arduinos. They're still very young, so we have plenty of time to get them into nerds.

Rami Sass:
Absolutely.

Matias Madou:
Rami, I think this was a fantastic chat. Thank you very much for accepting to being the 10th guru on our Software Security Webcast. Thank you very much.

Rami Sass:
Thank you. It's been a pleasure.