David Habusha, WhiteSource Software, The (Open) Source on DevSecOps

Andre Pino: In today’s episode I’m joined by David Habusha, who is the VP of product at WhiteSource Software. Welcome, David.

David Habusha: Hi, welcome, and thank you.

Andre: David, for our audience, you have a very extensive background in security. Perhaps you can tell us about your background and how you got into the security space and what you've done leading up to today?

David: Sure, so I actually got into the security space by chance. I was working for a company called the Precise Software that was delivering application performance management solutions for enterprises. Precise was acquired by Veritas Software, which was then acquired by Symantec so I found myself working for a cybersecurity company and after a few months of the acquisition, we actually started integrating our systems with what used to be called then the __ solution of Symantec. And we’ve kind of developed a really interesting product that tried to correlate the business impact of a security breach and the effect on the underlying IT systems in terms of outages and cost of outages and loss of data. So that was really fascinating and kind of put me in the security space. And then we’ve added some more products integrated in the Symantec suite of products so that’s how I really got into the security space to start with. And to be honest, I was always kind of around the Absec side of security and a little bit on the consumer side so after spending a few years in Symantec, I joined a company called GreenSQL which had an open source product for database security that went commercial at the time. The idea was to provide database security solutions for small, medium businesses with databases like MySQL, __SQL and Microsoft SQL Server at the time the large vendors were focusing on the large databases and large enterprises but no one really served the small, medium businesses. And that’s how the company started. We actually succeeded; it was acquired by Huawei, the Chinese company a few years back. The most interesting part with security is after serving as the VP of product of GreenSQL, I started my own company that started as a consumer privacy company but turned into a consumer security company, a company called My Permissions, in which we started by letting any user understand which applications, either mobile devices or on social networks in the cloud, had any access to their private personal information. But very quickly, we found ourselves doing some risk analysis of cloud and mobile applications, not just for consumers but also for enterprises. And then almost a year back I joined WhiteSource, again in the applications security space.

Andre: So tell us a little bit about WhiteSource and what you're doing today?

David: Well, we essentially help businesses develop and shape better software by harnessing the power of open source. So, we provide multiple open source management solutions, starting from just understanding what are the open source components being used by all the software being shipped by the organization. And it sounds easy, but it’s really hard to understand what all the teams are actually using, including all the dependencies in the other line packages and open source source files and so on. And then we help them manage open source in terms of the compliance aspect, namely licenses and compliance notices as well as maintaining an open source security post for notifying on vulnerabilities, and on open source software quality. So all in all, we tap into the software development lifecycle and provide enterprises with the management tools to actually be able to control the open source usage within the organization.

Andre: That’s really interesting. So, can you talk a little bit about how well the security community has embraced open source software?

David: You mean in terms of open source security solutions or in terms of securing open source software? That’s kind of two different questions.

Andre: Security solutions.

David: Oh, in terms of open source security solutions. So, we see many open source security solutions that kind of serve a small-to- medium size of problem, such as OWASP Dependency-Check and some other tools that help, running pen tests and doing some application security like SSLs and VPNs. We don't see a full suite of application security or input security solutions that are open source. I believe this is because these are different projects managed by different open source communities or backed by different companies, but we do see a lot of our customers who actually used open source security solutions before realizing that they need a commercial solution that would provide a larger use case. And these will mostly be small to medium businesses or departments within larger organizations who can really easily implement the open source security solutions to serve a problem that they had and they had to kind of resolve it fast and the open source solution was the right way to go. And some of them even spent years working with these solutions which provided them with what they needed.

Andre: That's great. And so, David, one of the hottest topics in the DevOps world today is DevSecOps. As organizations look to integrate their security practices and policies into their continuous delivery process. What’s your view on the current state of DevSecOps?

David: I think this is kind of the intersection of several technologies that enable DevSecOps to actually automate the processes of integrating security into the development and deployment lifecycles. If we look at the modern source code scanning and open source scanning technologies, they are very fast, they are very accurate, and they can tap into the software development lifecycle as part of build processes or we even see them as part of any changes in the repository. So we even see customers sometimes running a scan on every pull request or any push to the repo, or even running periodical scans because they're now so quick and so accurate. So they allow themselves to run them as part of the software development lifecycle. But also, all the CI/CD tools today enable any other vendors to integrate with them by running event-based accidents such as I mentioned running scans of pull requests or any other security checks or compliance checks on pull requests, which makes it easy on maintaining security hygiene of the code that is being actually stored in the repos, but also the code that’s being delivered to customers. But we still see some friction between and this is kind of a really interesting trend that is really hard to resolve now and I see a lot of companies and a lot of actually customers working on making these relationships easier. We see still a friction between the Dev teams and the SecOps and the DevOps teams and the DevSecOps teams because of the nature of the responsibilities. The DevSecOps teams are responsible for maintaining secured code and secured software. Developers are really interested in developing cool code, running the latest components with the latest programming languages and design patterns and generating microservices and running serverless code. They don’t really find security as something that makes their lives better or more interesting so it’s kind of something that they have to do but they don't really like doing. And this is I believe today one of the most, I would say, predominant problems within organizations. So even if you have all the tools in place and all the processes in place, you still need to bridge this gap. And we do see some companies trying to do that by delivering the right tools for developers to resolve security issues in their day-to-day environment like in their IDEs or in their repositories so they don’t have to get an offline report or use yet another tool that they don’t really want to. And we’re even seeing some of our customers who this is really interesting move developers to the security teams and move security analysts and security researchers to the development teams. So they can kind of share the mindsets of the different teams and think as if they were a developer or as if they were a security analyst and bridge the gap by just moving people from teams to teams and kind of generating a harmony between the different teams. So we think that’s actually happening very successfully with some of our customers.

Andre: So these are all elements of trying to move the security for software further left in the lifecycle, correct? Is that what you see as the big trend?

David: That’s right, and all the other LRD organizations today realize that the cost of preventing security vulnerability earlier in the process is much lower than actually discovering it in production or even in the build time or in the QA time. It’s much easier to fix it before it even hits the build system and that’s where they really want to be. Although, I must say that most of the customers that I’ve seen would really like to be there but they're still discovering a lot of the issues very late in the process. But we do see the shift left happening very gradually, very slowly, and by bridging the gap and by, as I mentioned, kind of moving people around within the teams and automating all these processes and providing the right tools. So we do see the shift-left approach happening in the organizations. I believe that in the next few years, that’s going to be even a standard within the DevSecOps organizations.

Andre: So with respect to automating the security testing, what percentage do you think an enterprise would need to run in order to feel that they have a fair measure of security in knowing that the software is secure and ready to go into production? What percentage of that testing do you think today with this technology can be automated, versus where you see it going in the future?

David: So I think that we have all the right pieces in the puzzle to automate the process but there's a few things that make it really complex for organizations to actually do that. One of them I mentioned is the politics and the lack of interest on the side of the developers. But the others are the complexity and the distribution of the development teams in different sites, sometimes even different countries or different continents, using different tools, different technologies. So standardization is really something that when achieved can be automated, but I think that it first comes down to trying to standardize on very few platforms in terms of the package managers and source programming languages, the repositories, the CI/CD tools. Because when you invest in automation, you still have to integrate into these tools in creating a secured software lifecycle based on these tools. And if you have multiple teams still using different tools, then you have a lot of work and then everything’s dynamic and sometimes the security teams don't control the new choices of the development teams. And most often, we see companies acquiring other companies, integrating more pieces of software into the original company and then they have to do it all over again. So I think that the first key for achieving automation is standardizing on a set of tools, then establishing security processes around the tools and creating the automation in place, and then making sure that it’s always running and maintained correctly by the security and development teams. And I think that we’re seeing the shift towards it and people realize that standardization is good not just for security purposes but for many other use cases. But it’s really still very hard to achieve. I believe that I would say less than half of our customers are today standardized on every three or four different I would say technology stacks. Most of them may have eight to ten different technology stacks, most of them even don't know how many technology stacks they really have, but we do see very big efforts on trying to deprecate older technologies and standardize on the new technologies to facilitate the security testing automation.

Andre: So, in your role, David, you probably have the opportunity to see what a large number of enterprises are doing with respect to their DevSecOps journey. When you think about some of the best that you've seen, what do you think sets them apart from some of the others?

David: I think it starts with awareness and education because when open source is being used by the different development teams, they can choose whatever they want and they can add components without any governance. Then, you generate continuous problems and you'll never be highly secure because you don't control the process. On the other hand, you don't want to limit the developers because then they would not cooperate when they really need to resolve outstanding security. So it’s kind of a balance of creating the awareness so they will have that in the back of their minds when they choose new components, when they write new software and making sure that it’s by design, they think about security as part of their day-to-day jobs. Then, it comes to actually using tools to govern the process. And then I think that if you have the full chain automated by using the right CI/CD tools and if you are containerized in creating microservices and making sure these microservices are secured, and the whole environment is secured. Not just from the application security perspective, but by running periodic checks on the network and the servers, then you may get to the point where you have the right processes and awareness in place, and kind of a working machine that would most likely be very, very agile in fixing new vulnerabilities and making sure that the software is mostly clean.

Andre: So, it’s interesting, you've touched on the microservices architecture a couple of times now and so one of the thoughts I had was one of the things we see is that the shift towards microservices architectures and containers is really having a dramatic impact on the number of builds that an organization does in a given time period. And I was wondering if this shift to containers, microservices and the resulting number increase in the number of builds that are executed, is that putting more stress on the security aspects of what needs to be done?

David: Oh, yeah, you've got some more complexity because if during 2016, I would see very few companies having I would say very few to dozens of microservices. Last year, we’ve been seeing most of our customers having dozen to hundreds of microservices. And I believe that this year, we’ll see hundreds to thousands of microservices pretty much anywhere. So, it makes things more complicated because these microservices are built on containers which are kind of a layered build that you need to be able to maintain a secured environment in each of these layers in the build process. So you don’t just need to scan your code and run some penetration testing you also need to kind of tap into the inventory of even the container images you have, you need to scan them for security issues and then you need to always be alerted whenever a new vulnerability comes that affects any of these images, and then you need to tie it with the services and systems that are being affected by the vulnerability. So, it’s really, really complex now to try to understand the inter-relationships between the pieces of software and the actual applications that run them. Because one container may serve multiple different applications and then kind of understanding the impact becomes much more complex. So you need to have a really good discipline and systems in place to be able to continuously monitor these systems, understand the impact, and quickly fix issues in the containerized environments on microservices. So we see a lot of our customers, actually, instead of building servers or services or kind of agents just building container images that they can later mix and match and run in multiple different applications. And as I mentioned, that brings another level of complexity to the picture.

Andre: Sorry, I was on mute and couldn't find the button in time. We’ll have to edit that out. David, as enterprises utilize more and more open source software, open source security vulnerabilities start to bubble up to the surface as an issue. How do you see enterprises who are increasingly using open source software within their application development environments managing this?

David: That’s really interesting. The open source adoption is keeping on growing rapidly. According to the latest numbers, more than 80 percent of any piece of software today is comprised of open source components. The other trend that we’ve seen in the last two years is that the number of vulnerabilities associated with open source components more than doubled in 2017. And looking at the numbers of Q1 2018, knowing MVP and some other security advisories we can see that this number is even growing at a larger pace. So the awareness is there, organizations understand that while open source shortens the time to market and makes their software better because of reusability in the community, and brings a lot of good benefits in software. It has some risks associated with it but I don't see them refrain from using open source components because of that. I’m just seeing being more aware of the risks associated with open source. Definitely looking at the latest breaches such as Equifax and previous breaches like Heartbleed and others, organizations realize that they can use open source but they need to be closely, closely monitoring the security risks associated with them and be on top of any new vulnerability that is being published, and be able to quickly fix or mitigate these issues. Because these security issues are published and everybody sees these security vulnerabilities including hackers and there's kind of a short timeframe by which the vulnerabilities being published, until it’s being actually fixed by the organization, that is getting shorter. But still, on average, it can last 8 to 12 weeks in which the risk is really high. And that’s something that organizations really, really understand today and are trying to become very proactive in terms of fixing these vulnerabilities. Some of them may even access, even ask for access to an early publishing of vulnerabilities to be able to actually remediate faster and not wait for the full details of the vulnerability to be published. But I don't see it slowing down the adoption of open source. I’m just seeing it increasing the awareness of the security risks associated and having the right tools in place to automate the monitoring and fixing of these issues.

Andre: Great, David, any final words for our audience who might be facing some of these challenges with respect to application security?

David: Yeah, I think that the key for any piece of software, and definitely application security is included in the support, is to keep it simple, to try and not interfere with the normal working processes both in terms of automation and development, trying to find the right balance between maintaining very highly secured environment while not slowing down any of the rollout timeframes or development timeframes or releases. And that’s a right balance that needs to be adjusted with different organizations but it’s achievable once you have the awareness, the processes, and the tools in place. So when you have all these three components, I believe that the organizations have the right approach that can keep on doing whatever they're doing, enjoy the benefits of open source, while still maintaining a secured environment.

Andre: Well, David, thank you very much for joining us today and talking about this really important topic and I'm sure it’s still an area of challenge for many organizations. David, it was great having you. Thank you so much.

David: Thank you.