Why It’s Hard to Integrate Software Development and Security

[00:00:35] Tom Garrison: Hi, and welcome to the Cyber Security Inside Podcast. I’m your host, Tom Garrison. And with me as always is my co-host Camille Morhardt. How are you doing today, Camille?

[00:00:44] Camille Morhardt: Doing really well.

[00:00:47] Tom Garrison: So today, we are going to talk about this relationship between software development teams and security teams. And oftentimes, there’s maybe a bit of a chasm that exists between those organizations. And as we all know, of course, we need to bridge that gap and make it more automated, make it just better sharing between development organizations and their security teams.

[00:01:13] Camille Morhardt: Yeah. And I think it’s kind of commonly referenced these days, automation in the context of secure development life cycle. So it’s very interesting to hear this guest talk about what exactly does that mean and how do you get that started and rolling.

[00:01:29] Tom Garrison: Yeah. So let’s jump right into it. Our guest today is Harshil Parikh. He is founder and CEO of Tromzo, focused on application security management platform automating SDL. He’s experienced in building security and compliance from the group up and scaling it with people, process, and technology. So welcome to the podcast, Harshil.

[00:01:57] Harshil Parikh: Thank you so much, Tom. I’m glad to be here.

[00:02:02] Tom Garrison: Well, our focus today is this connection between software and software development and security. So maybe we can just talk about the current landscape and what you see as the larger unmet needs when it comes to software and how it intersects with security.

[00:02:24] Harshil Parikh: This is becoming more and more relevant because every company is becoming a software company in a way. So how to build secure software, that is obviously important. Nobody’s going to argue with that. But the way software is built has changed as well dramatically over the past few years, especially with the broader adoption of agile and DevOps and really high-speed deployments of software across cloud infrastructure and so on and so forth. That has changed how security should be done because the traditional models of I’m going to do a quarter review, I’m going to do an architecture review, and a threat model. Before you can release your software to production, those things don’t really work anymore.

So as a software security industry, we’ve got to figure out how to integrate better with this modern development life cycle. And integration doesn’t really just mean technical integration, like running a bunch of tools in the CI pipeline. That’s a good start, but it’s just a beginning. So how do you make the developers empowered to build better, secure software? I think that’s the key question that we have to come together and answer.

[00:03:34] Camille Morhardt: Are you meaning that development is more iterative and the pace is faster? What do you mean when you’re saying it’s made differently now and we can’t just do a threat model once in advance?

[00:03:46] Harshil Parikh: Yeah. I mean, that’s exactly what it is, because developers earlier, there used to be large planning phases, waterfall model. There would be a change approval board who would approve certain changes to go into production and so on and so forth. But now, an individual developer is empowered to make their own decisions, use the technology stack of their own choice, and deploy whenever they want to.

So that obviously leaves the central visibility out of this and that equation. So as a security person, as a government person, you don’t really know what is actually happening. What developer in an organization of hundreds or thousands of developers writing code and deploying frequently, how do you as a security person know what needs high-tech security or what is relevant from a security perspective? You can’t do that. So at the end of the day, then you just have to empower the developers to make the right decisions.

[00:04:43] Tom Garrison: Why is it that in large developer organizations that an individual developer’s allowed to make a change? What’s driving that?

[00:04:52] Harshil Parikh: I think it’s the agility that comes with faster speed of deploying features, deploying software because at the end of the day, every business is competing with agility and time to market. If you think about the whole COVID pandemic and how that has changed and transformed businesses, a significant portion of the business has shifted to internet-based businesses. So whether it’s retail stores doing more business online, so on and so forth. That’s just a small example. But a large portion of the business critical processes are now driven by software. So then if you really think about it, the key advantages that a business can have in the market, they are fundamentally driven by software capabilities.

So being able to iterate faster, being able to deploy and be agile really helps you get a competitive advantage from a business perspective. So it’s got nothing to do with security, but it’s more about how software agility can be used to gain an advantage from a business perspective.

[00:05:55] Camille Morhardt: So in this massively distributed model that you’re describing, in those companies, how do you go about structuring an SDL so that you don’t have major problems or even conflicts within the developers in your own organization?

[00:06:10] Harshil Parikh: I think that’s a good question. And I think this is structuring an SDL is something that shouldn’t be done by the security organization. It’s really the engineering and the DevOps organizations who drive that. So typically, companies or engineering teams that have mature engineering processes, then it’s imperative for security teams to latch onto those processes and really integrate themselves.

But if there’s no process, if there is no defined way of doing things within the engineering organization, then it’s really hard for a security team to do anything. But at the end of the day, for a company of any reasonable size, they would have to have some sort of process built in to the agile framework, the faster speed of deployment, development, so on and so forth. Because it’s impactful not just for security, but also for quality scale reliability. All of those things come into the picture. So when you think about how to build software, there are mature processes that engineering teams will adopt. So that’s not something that security teams should really drive forward, but they should really make themselves a part of that existing process. Does that make sense?

[00:07:18] Camille Morhardt: Yeah. We hear a lot about integration and the importance of integration between the SDL practices or process, or tools which are moving more and more toward automation, at least certain tools, and the actual product development life cycle. In other words, the less separable those two are, the better the end result. Do you have a perspective on that?

[00:07:43] Harshil Parikh: Yeah. I mean, that’s 100% right. I mean, I think product development is a process that when you think about mature products, people who are defining that, what product needs to develop and all the metadata, all the other attributes that go with a high-quality product, I’m sure every engineering team wants to build a high-quality product. Now, what do you define as quality, that depends on company to company, whether you focus on just performance or just scale, reliability or security as well. 

So I think just becoming a core component and giving security a seat at that table, that it just becomes a core part of your high-quality software. I think that’s an important piece right there. That makes security a first-class citizen of the overall product development lifecycle.

[00:08:31] Tom Garrison: So you mentioned that one of the advantages is the speed with which changes can be made and the application can move out with the speed of the market. I wonder if part of also the value prop of what you’re describing is the continuous checking of what is the latest software attack, or the latest software vulnerabilities that are coming out there? Because if you just develop in the old model where you sort of develop an application, you get it out and you move on to the next revision, that old revision now is subject to whatever the latest attack is that wasn’t even known when it was built. So is there an element here of this, not just the benefits of speed but also the benefit of using the latest in vulnerability knowledge to check your application?

[00:09:29] Harshil Parikh: Yeah. I mean, I think that’s a phenomenal outcome of agile and DevOps processes that security can leverage. We are not yet in most cases. But a lot of security practitioners think of high-speed development and deployment and agile practices as something to be scared of. I think it’s an opportunity for us because exactly as you said, just the fact that you can address security issues quickly, really is impactful.

So it’s not something to be scared of in terms of we have no idea what developers are doing, but it’s really, we have an opportunity to highlight the things that are vulnerabilities or bugs or concerns that are coming in quickly and get them addressed quickly.

But obviously to be able to do that, you really have to be a part of that engineering development process so you can collaborate with them. But it really is an incredible opportunity for us as an industry to find out things faster, to address things faster, and just be more agile in terms of security as well.

[00:10:32] Morhardt: It seems to be there’s a lot of excitement around this notion of automation, especially in security processes and tools. I’ve seen examples where that absolutely fits and works and is very easy to deploy and scale and other examples where it seems extremely frustrating to try to make happen. 

So I’m wondering, in your experience, how quickly do you think automation is moving forward? And what kind of environment sort of lends itself to automation, or what kind of process or tool lends itself to that versus the type of scenario that is probably further out on the horizon?

[00:11:09] Harshil Parikh: One of the biggest benefits of this digital transformation or cloud transformation journeys is that almost everything is defined as code. So now you have infrastructure as code. Obviously, all of the software is as code. Your dependencies are all codified. So for an engineering team that is further along in their DevOps journey, cloud transformation journey, you can pretty much infer the entire stack if you just look at the code, which is great because now that you have data available as code, you can automate a lot of those processes.

So earlier, you couldn’t tell what’s going to happen in the infrastructure in terms of changes or how the infrastructure is configured until it’s actually deployed. So you are looking at a runtime infrastructure, and then everything becomes super manual because it’s already there. In the world today where it’s infrastructure as code, people are using Terraform and AWS, you can actually look at the code and automate your entire process of infrastructure security as well. Your cloud security gets automated. So there’s a huge opportunity. 

I mean, I think the fundamental pieces are there to be able to automate these processes, these checks and balances from a security perspective across a full stack. It’s a matter of us really understanding how to do it, how to make it seamless, and get ourselves as a core part of that process.

[00:12:34] Tom Garrison: You’ve been in the industry for a while now. And I wonder if there are maybe some either best-known methods or worst-known methods stories that you can tell us about, like the implications of doing things either really well or maybe some of the stories that’d probably be more exciting, the ones that didn’t go quite so well. Obviously, without names.

[00:12:55] Harshil Parikh: I mean, I think there have been a lot of well-known scenarios. Initially, when these things started, when infrastructure as code started initially, a lot of times people got super excited and things like using S3 buckets as a file storage system and making access control restrictions, giving that capability in the hands of people who don’t actually know what to do with it.

So for example, I saw one case where a very junior developer was in charge of configuring the cloud accounts for one of the organizations. And that person just came out of a completion of a Terraform course, and they just started to learn how to manage cloud configurations, and so on and so forth. And now, as a person who can dictate configurations through code, that person had no idea what it means for making S3 buckets public and accessible over the internet and so on and so forth.

So one minor change that affected a lot of confidential data that was stored across S3 buckets. And I mean, in a way, that’s very powerful because one person can automate changing of configurations at a massive scale. But what ended up happening was obviously not good in terms of a lot of the data potentially getting exposed. Thankfully, it didn’t result in an incident. But you could imagine the massive implications of one small change done by one individual and the absence of checks and balances in that entire process. 

So now we are at a time where there can be checks and balances built into it. And AWS is much better at protecting S3 buckets from accidental exposure and there’s a lot of notifications and alerting. But back in the day when this technology was new, it was very easy for people to make massive mistakes, cause massive headaches for the rest of the organization.

[00:14:52] Camille Morhardt: I tell you, I just went with the kids up to a little mountain motel, kind of a lodge, this past weekend. And of course, they wanted to get on the internet to do one of their games. So I was, “Okay, here’s the password,” whatever. “Look for the name of the lodge.” And my son, he’s nine. He said, “Oh. Oh, we’re supposed to be on the wifi that’s the name of the lodge?” I said, “Yeah, name of the lodge guest network, and here’s the password.” He’s like, “Oh, I got the password. I just thought I saw Arlo. So I’m in their camera system. I just used the same password you told me.” I was like … “Log out!”

[00:15:28] Harshil Parikh: Oh my God. Wow.

[00:15:29] Camille Morhardt: Like, “Can you see anything? He’s like, “No, I can’t see anything, but I’m on the wifi.” So there’s kind of all sorts of small examples of not even ill-intentioned setups where you could have possibly not a good scenario on your hands.

[00:15:44] Harshil Parikh: Definitely.

[00:15:45] Tom Garrison: Just leave it to kids. They’ll figure it out.

[00:15:47] Harshil Parikh: They’ll figure it out.

[00:15:50] Tom Garrison: All right. Well, what does the future look like, Harshil? We’re talking about sort of cutting edge right now or what could be defined as cutting edge. What do you think software development looks like in the next, say three to five years?

[00:16:04] Harshil Parikh: Large companies used to have armies of people and their job in the security team and their sole job was to find bugs, find vulnerabilities and report it, throw 1,000-page PDF back to the development team and tell them, “Go fix it.” That’s what used to be in the testing world, but that doesn’t exist anymore. I think that’s exactly what we’re going to see over the next five to 10 years in security where this whole concept of I’m going to find 1,000, 2,000 bugs and send you a PDF report and you’re expected to fix everything. That’s not going to work.

The way forward will be those testing capabilities, security testing capabilities will be automated just as a part of your normal DevOps tool chain. And we have indicators of this. So when you have dev tool companies like GitHub and GitLab and Artifactory, JFrog, all of them are coming up with security capabilities. And really what they’re doing is they’re democratizing security testing. So they are saying security testing is not the sole proprietary of security teams. It has to be a core component of everyone. All developers should get security bugs just as a part of their life cycle.

So what we will see is that piece of application security where teams used to focus on testing, finding bugs, that’s going away, and security engineers will really be focusing on more high-value, high-leverage security work. And it’s not just finding bugs. Obviously, there will be some… there’s a huge percentage of things that only human can do and it needs security expertise, obviously, so that will continue to be there. But this whole concept of I’m going to click play on this security scanner and generate a report and send it to you as a developer. That’s not going to happen.

So I think there’s going to be a shift where a large portion of existing abstract work will be given back to the developers and they’ll just start owning it. And the decision-making will need to be transferred into the CI/CD pipeline just like how we did with the test engineering. Now, whether you’re allowed to deploy software to production or not, that depends on the policy as defined in your CI/CD pipeline. If you meet this threshold, you’re allowed to deploy. So the same thing should happen and will happen with security where you’re meeting a certain threshold of security, you’re allowed to deploy. There’s no human interaction. There’s no security testing team that’ll stop you. So that’s the direction we are going. I think that’s what’s going to happen in the next five to 10 years.

[00:18:29] Tom Garrison: We do have a segment on our podcast we like to do every time, which is called Fun Facts. Do you have a fun fact that you would like to share with our listeners?

[00:18:41] Harshil Parikh: I would love to. So I just came back from Maui a couple weeks ago. And Maui is the second-largest Hawaiian island. And it has the world’s largest dormant volcano. It’s really cool. When you go up top, there’s an observatory. And the observatories across the Hawaiian islands are really famous because they are so far away from all the population. So you can really see the sky really well. There are a lot of tours that take visitors up to those observatories as well. And it’s a fascinating way of looking at the sky and it gives you a very different view that you cannot get in most other mainland places.

[00:19:23] Tom Garrison: Little piece of advice–which I’m sure you learned– dress appropriately because the weather at the top is nothing like the weather down below. It is freezing up there. Exactly. All right. Well, a good one. Camille, how about you?

[00:19:38] Camille Morhardt: Well, I’m really excited that you mentioned an observatory, Harshil, because that’s part of my fun fact. As part of my expedition this weekend, we ended up finding ourselves at the Goldendale Observatory, which is in Goldendale, Washington. I’ll say on the east side of Mount Adams, kind of what I would think of as way out there, which makes sense, I guess.

And the thing that I learned at the Goldendale Observatory is, well, two things. One, there’s this geosynchronous equatorial orbit, which is essentially this line that’s hovers above the equator about 22,000 miles off of Earth’s surface, that if you get your satellite in that orbit, then it moves exactly with the Earth. So whatever the receiver is on Earth can actually just point in the same direction. It doesn’t have to be able to turn and go and look for the satellite.

But the other thing that’s cool that I just want to let people know about is there’s this website called Stuff in Space, and they were actually using this at the observatory, and you can see all of the different satellites that are around Earth. And you can see even the lines of Starlink as they’re being launched before they sort of spread out, and you can see this geostationary orbit called the Clarke Belt, after the sci-fi writer. So I would go check that out. It’s a pretty cool thing to look at.

[00:21:07] Harshil Parikh: That’s phenomenal.

[00:21:08] Tom Garrison: If it’s the same website I’ve seen, it’s incredible because at least for me, I didn’t have an appreciation for how many satellites are up there.

[00:21:18] Camille Morhardt: So many. Yeah, so many.

[00:21:20] Tom Garrison: It’s crazy how many satellites are out there. Way more than I thought. Well, I’m going completely in a different space for my fun fact, but I’m going to do it in a form of a quiz. So maybe everybody listening to the podcast can participate, as well as YouTube. So my question is what do you think is the height of the tallest person ever recorded? And then also, in what country do you think this person lived?

[00:21:55] Camille Morhardt: I’m going 8’10”, Mongolia.

[00:21:59] Harshil Parikh: I’ll go with around 9′, 9’5″, and somewhere in Asia.

[00:22:07] Tom Garrison: So the answer is shocking to me. And it’s because it’s way taller than I thought. The answer is actually 8′ 11″. So Camille, you get full props for only being one inch off. 8’11” and this person was an American. And his name was Robert Wadlow. And he was born in 1918. And he unfortunately died at a very early age of 22. According to the Guinness Book of World Records, 8’11”. That’s where it maps out.

[00:22:45] Camille Morhardt: I was just looking at the ceiling in my studio, I think is nine feet. So he’s basically one inch short of that. That’s just insane.

[00:22:55] Tom Garrison: Yeah. Incredible. Anyway, all right. Well, Harshil, thank you so much for joining us today. And it was a good topic on SDL and security and intersection. So good topic and thanks for being with us.

[00:23:09] Harshil Parikh: Thank you both of you. It’s been a pleasure.