Tag: developers

The security of open source code is one many organizations are grappling with. Add to that the number of times that applications using open source code are updated and the integration issues that come with those updates, and it’s no wonder open source security comes into question.

WhiteSource thinks it has a solution to the open source code security problem. In this DevOps Chat, we speak with Azi Cohen, head of U.S. operations at WhiteSource, about the issues surrounding the security of open source code and how his company is helping to reduce the problem.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, Security Boulevard, and we’re here for another DevOps Chat. In today’s DevOps Chat, I’m happy to be joined by someone who I’ve had the pleasure of speaking with several times, but not on a podcast, I believe, and it’s Azi Cohen – “Cone” or “Cohen,” depending how you pronounce it. Azi is head of U.S. operations and a co-founder at WhiteSource Security. Azi, welcome to DevOps Chat.

Azi Cohen: Hi there. Good morning. How are you doing, my friend?

Shimel: Good. Happy to have you here with us. So, Azi –

Cohen: Okay, and, by the way, the name of the company is WhiteSource Software.

Shimel: Oh, okay.

Cohen: Yeah.

Shimel: I apologize. WhiteSource Software.

Cohen: Yes.

Shimel: You know, and that’s a good bridge, Azi. Before we jump into today’s topic, which is DevSecOps-related, for those who may not be familiar with the company, why don’t you give us a little background?

Cohen: Sure. Perfect. So WhiteSource Software was initiated by three of us. We are three partners that were actually working in a different company that was acquired, going through an acquisition, by CA Technologies. And, through this process of due diligence, we found ourselves getting questioned about open-source that was included or not included, you know, in our technology. And that was a very cumbersome process. Took a lot of time and effort. So, not surprisingly, after the three of us been acquired and spent some time acquiring companies, we realized, “Hey, there must be better way to do all these things,” and, a few years later, we started WhiteSource.

The idea was to allow companies that develop intellectual property using open source – and, remember, we’re talking about 2011, 2012; open source was well-known phenomena or the use of open source, but still not very well-adopted by the large enterprises – so the premise was to help software houses or companies that developed their own intellectual property, using open source, to have a better management and control of the inventory, the legal aspect or the compliance side, and, later on, in security.

So we started the company in Israel. We got some grants from the Israeli government. We developed a solution and, obviously, we started to focus on companies – you know, at startups and technology companies. And we were doing very well for quite a long time. I think that the big change came somewhere like 18 months ago, maybe 24 months, where we started to feel a growing demand from large enterprises – banks and technology companies, consultants, large chains, health companies. So all those started to use open source and started to look also for a solution, and that’s when we realized, “Hey, there’s a big opportunity here.”

We went out, raised a lot of money from VCs, including from Microsoft, etc. Started the U.S. operation. And, fast-forward today, we have a very large office here, more than 30 people, in North America. I run the U.S. operation. We’re growing 300 percent year over year. Almost more than 500 clients, from multibillion companies to small ones, and it looks, right now, that demand is not going to drop.

Shimel: Fantastic. You know, as they say here in America, mazel tov.

Cohen: [Laughs]

Shimel: It’s an American –

Cohen: Thank you for that.

Shimel: – _____ success story, right? And congratulations to you and the team. But, Azi, you know, sometimes – and, like you, I’ve been in business 30 years – sometimes, it’s better to be lucky than smart. It’s good to be both. But you really – WhiteSource Software and your team has been a little bit of a benefactor of being in the right place at the right time. We live in an age where so much of our – well, everything is software and applications, but so much of our applications are built on open source component, primarily, right? A majority of –

Cohen: Absolutely. That there is a Gartner report that states that something like 40 to 60 percent of the new web applications consist of – is consisted of open source and this is just going to grow. Right? So it’s not going to stop there. And we definitely see that by our biggest clients. We see them starting when they have something like 20 percent of their code being open source, very quickly reaching to 30, 40 and more, right?

So this is not something that is going to happen, and I think there is a very good reason for that. If you look at large ITs today – banks, etc. – you know, the CIOs are being asked to create more and more innovation. Someone wrote an article about it. Something like that they’re required to generate something like 25 percent of new ideas and new application or, if you want new lines of code, you know, 25 line of code, year over year, but they don’t get 25 percent more people to do it. Right? They just get 2, 3 percent. So reuse instead of build is the most obvious solution, and that’s why we’re not going to see that percentage dropping, but going higher and higher.

Shimel: Oh, and – but it makes good sense, right? So much – you know, when you look at the average application, so much of it is rinse and repeat, right? Sending an e-mail, firing off an e-mail or registration, opening a window. So many of – there’s no sense reinventing the wheel of these things _____ _____ –

Cohen: Oh, absolutely.

Shimel: You know, when you look, there’s so much Java script reused, there’s so many Java components reused. There’s so much of these open source reuse – like you say, it’s only gonna be more and more, as these libraries and repositories get bigger. But that begs the question, Azi, of it doesn’t make us more secure, necessarily. And, as a matter of fact, some may argue it makes us less secure. What’s your position?

Cohen: Well, it’s a great question. You know, and, obviously, when you have one component being used by millions, it’s just an opportunity for attacker to find a way to hack it, crack it and now they have thousands of companies that may be vulnerable to this one, right? And then, for them, an open door to get into those accounts. So what we actually see is that, with the fact that more and more open source is being used, on one end, we have attacker trying to exploit those open source components and we have seen some cases in the past, right?

In the same time, the community tries to find more vulnerabilities and fix them as fast as possible, but, if you look at the DevOps guys, this create a huge problem because, think about it, on one hand, they use more and more open source; on the other hand, the community, which is very active, is finding more and more vulnerabilities in those open source and provide fixes, right?

So now the DevOps guys have more stuff to deal with, a larger inventory to track and check and validate, but, on the other hand, we know that the attacker, that know that these guys will patch those vulnerability very quickly, try to hit them faster and faster. So DevSecOps or DevOps guy have more stuff to do in less time. So the only solution is by automation, right? The only solution is by some control that will let them know what’s good, what’s bad, and provide alerts when something bad is happening or when new vulnerability that is – that they are exposing the inventory is _____ _____.

Shimel: Yep. Absolutely. And you know what, Azi? This is – what you just described, yes, it’s 100-percent dead on for DevSecOps, but it also describes so much of what we are seeing in software development in general. If the machine, if the factory is gonna run, at the optimum speed, we must automate so much of this, right? Because, otherwise, it just can’t keep up and security is certainly no exception. No exception. _____ –

Cohen: Absolutely. And another thing here is that you have to detect or try to stop bad things from coming in at the gate and not later, right? Because every step later – so it’s automation but also automation at the front of what’s called shift left, right? As early as possible in the development cycle. And then, at WhiteSource, we do exactly that.

Shimel: Yep. So this begs the question, though, “Sounds wonderful. Let’s all do it. Why aren’t we more secure? Why aren’t more people doing it? Is it really that easy?”

Cohen: I think it’s mostly a matter of awareness and perception as well. So, firstly, when I meet with CIO, CISOs, they don’t – in many cases, they don’t understand what level of adoption of open-source they have in their environment. Their perception is that, in many cases, that they use only 10 percent or 15 percent of the code, is open source. The reality is it’s higher.

So perception of the problem is one thing, and top managers in many places don’t understand that the amount of open source being used right now is larger than what they have, but the other thing is that, you know, the perception is that standard tools, like application security testing tools from IBM or from Checkmarx and from other vendors, right, are solving the problem. You know, since they scan the proprietary code, then most likely scan the open source as well, but that’s not true. That’s not the case.

And the last thing is that, once more awareness or, if you want, education – the assumption by most managers is that open source behaves like the proprietary code, right? You use a scanner. You test the open source. You find vulnerabilities. Somehow, you either fix them or not, and they’re fixed. It’s a one-off. What they miss is that open source is a living thing. You may have a clear open source component that are using now, which is fine, but then, month later, there could be a vulnerability in it, right? You have to be able to track it later on. It’s not a one-off test and gone.

A good example is Apache’s Struts No. 2, right? A year ago, the whole world was astonished by this Equifax thing that was created by an attack to Apache Struts. Everyone mostly likely fixed it by today. And guess what? Three days ago, a week ago, a new vulnerability in Apache Struts No. 2, which was fixed, was discovered. And that’s not going to be the last one, right? So open source is a living thing, vulnerabilities are coming and going, and you have to keep track.

So I believe the top managers – CIOs, sometimes CISOs – are not aware of all those effects that came out there, with more open source, right, that the current tools does not solve it. And, finally, that they need a tool that is designed to track changes in the security of their open source inventory along the time.

Shimel: Exactly. I mean, you talk about Struts 2, which is sort of the poster child here because of all the press and notoriety that Equifax got. And I saw a presentation by – I forgot what company it was, but what really surprised me, Azi, is, even after we knew it was bad and you had to patch it, you had to upgrade it, the amount of people who were still downloading and using the old version – it dropped off from maybe 80,000 a month to 70,000 a month. Right?

Cohen: Awareness, right? And, by the way, these numbers are changing, so you may not know, but we just released a tool called “Vulnerability Checker.” It can be downloaded from out website, whitesourcesoftware.com, and, basically, it will check – it will do an automatic check to check, for clients _____ – people that are interested whether their systems are affected by Apache Struts 2, right? So for those that are aware and would like to know whether they have some issues with that right now, they can download it free and check very quickly their system and find whether they are affected or not.

Shimel: Yeah. But this is also the future of where companies need to be. They need to do this and then they need – you know, Azi, I remember I was selling vulnerability management and patching, oh, maybe 2005. I was talking to one of the CIOs. They had three CIOs at Citibank. This is before it was called “Citi”; it was “Citibank.” They had three global CIOs. I showed them a system that would scan for vulnerabilities and, if there was a known patch for the vulnerability, it’d integrate it with a patch manager that would automatically – that would patch these up.

Cohen: Sure.

Shimel: And he said, “This is great, but, Alan, we don’t just install a patch ’cause we found a vulnerability. Before we can install a patch, we have to do regression testing on all of the applications. We run about three months behind.” So, literally, there was a three-month cycle by the time they would patch a known vulnerability that they found. And, yeah, I’m not saying it’s that bad today, but that sort of mentality, that approach, just doesn’t work at the speed of business today.

Cohen: You’re 100 percent right. And I bet that Citi today have hundred times more vulnerabilities per application than they used to have at those days, but this is an important point because we face that any of our large clients – and, actually, we just came up with a very, very smart solution for that. So we know, as you mentioned, that it takes them a long time to patch, right? And we know that they have thousands of vulnerabilities sometimes, and they need to know where to put their time, right? Especially if it takes longer time.

So we came up with a tool called “Effective Usage Analysis,” and the idea is very simple. When a developer picks up a new open source component, this component usually come with 10 or 15 different functions. Each one of them may have some vulnerabilities, etc., so this entire package could come with, let’s say, 10 different vulnerabilities. But the developers will use only one or two functions, and, therefore, you’ll be exposed only to two or three out of those 10 vulnerabilities. So Effective Usage Analysis is a new module that we release. It runs over the code and identify how the developers use the open source and, therefore, clean out all the non-relevant code.

So, for this kind of – for the Citis of the world, that have thousands of vulnerabilities, Effective Usage Analysis will drop the number of relevant vulnerabilities by 70 percent – seven-zero. These are the statistics. And now they’ll have only the most severe 30 percent where they can and should spend those three months in order to fix them, on the road to get a better security solution. It’s huge. This difference is huge. We get a lot of good feedback from clients that are testing that. It really helps them to make sure that every hour that they spend is much more effective.

Shimel: Excellent. And this thing you can also get at WhiteSource Software?

Cohen: Absolutely. Yeah. It’s a new model that we just released.

Shimel: And what’s the name of it again?

Cohen: Effective Usage Analysis.

Shimel: Effective –

Cohen: EUA.

Shimel: – Usage Analysis. EUA.

Cohen: Yep. Yeah.

Shimel: Got it. Well, Azi, as I mentioned to you before we started recording, the 15 minutes here goes very fast.

Cohen: [Laughs]

Shimel: We’re already over 15 minutes. We could probably talk all day about this, but we’re gonna have to call an end to this episode of DevOps Chat. But maybe we’ll have you back on soon and we can continue the conversation.

Cohen: Sure. Thank you. It’s always a pleasure talking with you, Alan, so I’m looking forward to it.

Shimel: No, it’s my pleasure, Azi. I feel like we could sit and talk and go all day about this, but we’ll call it a wrap. Azi Cohen, a co-founder and chief of U.S. operations for WhiteSource Software, thanks for being our guest on this episode of DevOps Chat.

Cohen: Thank you for the opportunity, Alan. Always a pleasure.

Shimel: Pleasure. This is Alan Shimel for devopsy.kinsta.cloud, Security Boulevard. You’ve just listened to another DevOps Chat.

— Alan Shimel