WhiteSource has become a force in the security of open source components in your applications. One would think that it would follow that securing these open source components inside of a container would flow from this. But with containers, all is not always as it seems, especially with container security.
Containers require an approach that is unique. So the folks at WhiteSource went to the lab and have engineered a solution that is container-native and container-specific.
In this DevOps Chat, we speak with VP of Product David Habusha about WhiteSource for Containers. As usual, the streaming audio is immediately below, followed by the transcript of our conversation.
Alan Shimel: Hey, everyone, this is Alan Shimel, DevOps.com, Security Boulevard, Container Journal. And I’m here with David Habusha, VP product of WhiteSource. David, welcome.
David Habusha: Hi. Thank you. Happy to be here.
Shimel: So, David, I’m always torn between just saying “WhiteSource” and “WhiteSource Software,” “WhiteSource Security.” What is the proper term these days around WhiteSource?
Habusha: Oh, the company name is “WhiteSource Software.” The product is “WhiteSource” – actually, it’s going to become suite of products. WhiteSource for Containers is the one that we’re going to discuss today, is the first one in the suite. So just use “WhiteSource” – that’s easy.
Shimel: It’s easy. Exactly. So, David, I think most people in our audience are probably familiar with WhiteSource already, but, if not, just give maybe a quick elevator kind of story and what is WhiteSource about.
Habusha: Sure. We help businesses all over the world to harness the power of open source. What we basically provide them is the peace of mind, when it comes to using open source, with regards to compliance and security and quality of the components. Our technology allows them to scan all of their applications, understand what are the open-source packages being used by these apps, including all the dependent packages. And we’re talking today about more than 80 percent of any lines of code in any app that are open source.
And then we apply some workflows, policies, alerting and reporting logic, based on that. We have the largest database of open-source security vulnerabilities and we provide our customers with their current end posture, with regards to security and compliance, as well as some trends and allowing them to actually safeguard their software development life cycle, using open-source components.
Shimel: Excellent. And, not to belabor it ’cause I wanna jump into what we wanna talk about today, but, certainly, the open-source components make up such a large – it’s kind of like when we buy cars that are supposedly made in one country or another, but so many of the parts, the third-party parts, are manufactured in different countries. It’s the same thing with applications today, right? So many of the components that make up that application, so much of the functionality, comes from components that are really kind of pre-written and just – I don’t wanna use the term “Frankenstein,” but, you know, added to the mixture, add the needed functionality. So people don’t realize that, when they’re using any application today, chances are, that application, within it, is using more than several components, many, many of which are open-source. So make sense, David, yeah?
Habusha: Yeah, that’s right. I mean, we did a big survey in 2018 about the volume of using open source in small to largest organizations and it’s just all over the place. And, you know, when it comes to these large organizations, they don’t even realize how many open source they have in the organizations, in the various teams; it’s just out of control and really need to be in control of what’s going on and what components are being used and be on top of that all the time, throughout the software development life cycle.
Shimel: Understood. Good. Phone here in the office – I apologize. David, but, when we talk about applications today, of course, they’re kinda a lot of the infrastructure, a lot of the deployment, a lot of the design, is around containerized applications, right? So it’s between microservices and so forth, we are developing containers that exist in – developing applications, excuse me, that run in a containerized environment. And things like Kubernetes and Docker and so forth have become the – I don’t wanna say it’s dominant yet because I don’t know if it’s truly dominant, but it’s certainly the platform of choice, if you will, the architecture of choice, of many of today’s up-and-coming applications. Would you agree?
Habusha: Oh, yeah, definitely. Yeah, by a survey that we ran, actually speaking to several analysts, Kubernetes is around 90 percent of the market when it comes to container-orchestration platforms. And we do see this number growing. We see a lot of organizations standardizing around Kubernetes and a lot of solutions being added on top of Kubernetes, like service meshes and monitoring and many others.
With regards to use of containerized systems, yes, depending on the maturity level of enterprises, they will see a lot of shift towards creating modular architecture, where software is being delivered as smaller pieces of microservices. The more mature organizations, they have hundreds or thousands of microservices being consumed by multiple different types, but the ones that just started exploring containers and microservices architecture, they may have a very few apps, but they have some of the services being containerized and run as microservices just to understand how the environment works. And yet, when they are the standard, when they realize the huge advantage of software reuse and the use of containers, they actually make it standard in organizations.
Now that, when the maturity level spans across just having one or two containerized environments or very few applications or maybe they’re starting with new apps, up until the organizations that decided that we migrate all the existing apps towards a microservices architecture. And, by that, the actual solutions that they employ vary between just having sporadic images here and there and storing these images in _____ container registries, like could be Google Cloud Registry, AWS ECR, Azure Container Registry or even JFrog Artifactory, to the ones that actually have a model of running production-orchestration platform, such as Kubernetes, where they actually run multiple different containers, based on organizational policies, based on workloads, et cetera.
Shimel: Got it. Absolutely. And, you know, David, let’s be honest – this whole move to an orchestra – excuse me, a containerized architecture and orchestration with Kubernetes, et cetera, I mean, obviously, it presents, as you’ve touched on, it presents unique security challenges. And it really has grown up a – not grown up, but there are several organizations that are container security – I mean, that was their original reason for coming about. And then there are several companies, from big to small, who are seeing the challenges, from a security point of view, in a container architecture and are attempting to meet the challenge. What’s WhiteSource doing around this and what makes it unique, you think?
Habusha: So it actually moves the problem from the build-and-test stage to the deploy stage. So WhiteSource, traditionally, and many other vendors provided security solutions for containers during the build phase. And, actually, when they store these images in container registries, like I mentioned, now organizations look into having solutions that will enforce compliance on their runtime environment in Kubernetes. So, first of all, they want to be able to check every new image that is being added to the Kubernetes cluster, to make sure that it’s a clean image, that it doesn’t have any high-severity security vulnerabilities associated with it, and that it doesn’t violate an organizational policy, with regards to compliance or quality. But then it doesn’t stop there because new security vulnerabilities are published all the time – one of them, by the way, it was published last week, which is the RunC – [break in audio]
Habusha: That actually affects the runtime or the orchestration platform – Kubernetes or, in this case, it’s also OpenShift itself – so these customers want to make sure that, first of all, they introduce security images to the cluster because these images are going to run in production. And then they want to make sure that, if a new security vulnerability is published, they will immediately be alerted on this vulnerability and understand what are the images that are affected by the vulnerability and may take them out of order.
So there’s two ways. One of them is – and it kind of resembles the IDS and IPS terminology, when it comes to firewalls and traditional security systems, so, first of all, there’s monitoring and being able to understand what images you have in the cluster. And WhiteSource provides what’s called a “management pod,” that runs as part of the Kubernetes engine, that, first of all, that scans all the images and, whenever a new image is being added to the cluster, it’s capable of reporting all the vulnerabilities associated with it, but also report newly-published security vulnerabilities.
But moreover that’s unique to WhiteSource is we’re capable of actually enforcing compliance in production. So we don’t allow to add new vulnerable images to the cluster, but we also can take runtime, run images from the cluster, in case a new security vulnerability is being introduced. And that’s based on the organizational policy – again, it’s a matter of maturity of the organization and the severity of the vulnerability. So, assuming that, first, organizations will do the monitoring and _____, but _____ _____ – and we do have some customers that also enforce compliance in runtime as well.
Shimel: So this enforcement in runtime is really – I mean, it’s a bit of a departure for WhiteSource, right? It’s much more proactive.
Habusha: That’s correct. That’s our first move in that direction to production and to Dockerize the environment. It actually makes sense to be the first one to allow these types of technologies to be applied. And we kind of monitor the image throughout the full life cycle, from the build phase to the deployment and production phase. And that’s something that we’re exploring, if we should pursue more than just Dockerized environment in the future – maybe looking to securing also virtual machines and looking at modern technologies such as microchromas and others as well.
Shimel: Serverless. So, David, I’m reminded of my own history when one of the companies I cofounded was, at the time, when intrusion detection was all the rage. And we started moving into intrusion prevention, where we were actively blocking bad traffic. And I remember, though it made perfect sense to me to do, many of our customers were scared to death that they were gonna inadvertently block something that was important, whether it be a CEO’s e-mail or something less important. I’m wondering what kind of feedback you’ve gotten from customers and testers on the proactive blocking or the proactive remediation here.
Habusha: You know, it’s very interesting because the feedback is not just technical; it kinda of brings up the known friction between the dev teams and the security teams and the DevOps.
Habusha: And it kind of allows the security and DevOps teams, for the first time, to actually control the life cycle of the software deployment. So they’re not in the mercy of the development teams to resolve issues of the build time because they can actually now enforce compliance in the runtime, when it comes to running software or applications with known vulnerabilities. So they’re doing it with caution because they still need the dev teams to fix these issues back in the build time and then recreate these images and redeploy them. Usually, they do it automatically in the CI/CD pipeline, so they have a full pipeline that compiles, commits, merges everything to the buster bench and the repo, generates a microservice which is then being stored as a Docker image in one of the container registries, and that being deployed to the container-orchestration platform.
But, at least if they decide that there’s a high-severity vulnerability that affects the one of the running images or more than one, they can actually take it out of order and remove it from the production system. So, I mean, that’s the feedback that we’re looking and they’re happy to have the control. Many of them are still looking for the cooperation of the dev teams, but now they have the leverage over the dev teams because they control the runtime environment.
Shimel: Got it. I mean, I hear that. You know, it’s funny; no matter how many things change, a lot of it stays the same too.
Shimel: In that kind of friction between teams. Of course, key to DevOps, right, is “How do we break down these silos? How do we break down that friction? How do we all work together?” because, at the end of the day, we all have a common goal, right, which is to have great, secure applications that serve our customers and make our company more profitable, more efficient, better. And, sometimes, I think people lose sight of that and they get so involved in territories and defending the turf that they forget. But, anyway, David, it’s RSA season, so it’s a big time of year in security. There’s usually new product launches and new news. We’re about a week out, two weeks out, from RSA. Any news or anything else that you’d like to share with our audience?
Habusha: Yeah. So, as I mentioned, we’re – [break in audio]
Shimel: Talk _____.
Habusha: – _____ _____ suite of tools – WhiteSource for Containers is the first one – and we’re strengthening our effective usage analysis, which allows customers to more effectively prioritize security vulnerabilities, based on the actual usage of the apps and not by just looking at imported vulnerabilities. But, in the last year, we’ve been also working on providing developers with the right tools to work in their environment, to remediate security and compliance issues, when it comes to integrated GitHub application. And soon to be supporting additional repositories and also looking into IDE integration. We’re going to launch a new product suite called “WhiteSource for Developers,” that will incorporate all these developer tools.
Again, talking about the same friction, it will allow to better cooperate between security and DevOps team and the developers team because it will bring all these open-source information into their existing day-to-day environments, whether it’s their IDEs or their repositories, allowing them to easily resolve security issues and stay within their environment and cooperate better with other teams. So this is something that we’re going to launch in the next quarter and we’re very excited about it as well.
Shimel: Excellent. Excellent. Excellent. Well, David, you know, as I told you before we got on, the time goes incredibly quick. If I told you we’re over 20 minutes already, you probably wouldn’t believe me, but we are. And we’re gonna need to call a wrap on this DevOps Chat. You know what, are you gonna be coming out to RSA, David?
Habusha: Oh, we’re going to have a pretty large _____ –
Shimel: Oh, I know WhiteSource will be, yes.
Habusha: Yeah, myself, I will not be there, but we’re going to have –
Habusha: Yeah, a very large delegation of people with a very nice booth. And we’re excited to –
Shimel: Oh, not only that, you’ll also be – DevSecOps Days is Monday, March 4th. It’s the fifth year we’re putting that on, in partnership with RSA, and, of course, WhiteSource is always – or it has been in the last few years, anyway – is sponsoring that as well, so you’ll have a nice table with folks from the company there, for anyone who stops by. And consider that an invitation. But, David, I’m sorry we won’t see you there, but, hopefully, we’ll catch up with you again soon.
Habusha: Yeah. I’m sure. And thank so you much.
Shimel: Thank you so much for being our guest today. David Habusha, VP of product, WhiteSource, here on DevOps Chat. This is Alan Shimel. Have a great day, everyone, and we’ll see you on the next DevOps Chat.