On this episode of DevOps Dialogues: Insights & Innovations, host Paul Nashawaty is joined by Jack Poller of Paradigm Technica and Mitch Ashley, analyst and founder of Techstrong Research and Chief Technology Advisor at The Futurum Group, for a discussion on the SDLC and the impacts of security as it is integrated into the pipeline.
Their discussion covers:
- How security is not just security
- Security a bolt-on afterthought
- Impacts to DevSecOps as it relates to the software release cycles
These topics reflect ongoing discussions, challenges, and innovations within the DevOps community.
Watch the video below, and be sure to subscribe to our YouTube channel, so you never miss an episode.
Listen to the audio here:
Or grab the audio on your favorite audio platform below:
Disclosure: The Futurum Group is a research and advisory firm that engages or has engaged in research, analysis, and advisory services with many technology companies, including those mentioned in this webcast. The author does not hold any equity positions with any company mentioned in this webcast.
Analysis and opinions expressed herein are specific to the analyst individually and data and other information that might have been provided for validation, not those of The Futurum Group as a whole.
Transcript:
Paul Nashawaty: Hello and welcome to a special edition of DevOps Dialogues. My name is Paul Nashawaty. I’m the practice lead for the AppDev practice at The Futurum Group. I’m joined today by Jack and Mitch. Jack, would you like to introduce yourself?
Jack Poller: Sure, Paul. It’s great to be here and thanks for inviting me. I’m Jack Poller. I’m an independent analyst. I used to be a industry analyst doing research on cybersecurity, focusing particularly on identity and access management and data security. And now I’ve started my own company called Paradigm Technica and glad to be here to talk about security with you.
Paul Nashawaty: Excellent. Thank you for coming on the show today.
Jack Poller: Thank you.
Paul Nashawaty: Hey, Mitch…
Mitch Ashley: Good to be with you again. This is a habit for me, isn’t it?
Paul Nashawaty: Absolutely.
Mitch Ashley: I’m Mitch Ashley and I’m analyst, founder of Techstrong Research and covering cybersecurity as well as DevOps, DevSecOps, AI, and cloud. A lot of areas, I know, but they all tend to intersect these days, right? And I also am a practicing CTO, still run our infrastructure and backgrounds and product creation in those areas. So good to be with you.
Paul Nashawaty: Yeah, great to have you here on the show.
Mitch Ashley: And nice to meet Jack. This is my first time-
Jack Poller: Thank you.
Mitch Ashley: Meeting you too.
Jack Poller: Nice meeting you too, Mitch.
Paul Nashawaty: Great. Excellent, and thank you for both. This is great. This is a very important topic. When I think about my practice and the conversations that I’m in with a lot of the customers that I’ve talked to, we often talk about the past, present, and future, the state of applications, where they’re going. The lion’s share of applications are running in the heritage kind of state and they’re trying to migrate and bridge the gap over to a more current state, which uses containerization or microservices and such. When I think about my area of coverage, I think of day zero, day one, day two, so build, release, and operations.
But from a DevOps perspective and platform engineering perspective, you can’t have the SDLC without some type of security integrated into it, right? Because you have container security. You have application security. The funny thing is, I was in a conversation recently and I said, “Oh, well, security is just security.” And when you think about it, I’m like, “Is it physical security? Is it infrastructure security? Is it application security?” So I guess maybe, Mitch, maybe we can start there and say, when we think of security and we think of the impact to applications, what does that mean to you and to DevSecOps?
Mitch Ashley: Well, having spent time in the traditional security world as well as doing software, I feel like we’re sort of making some of the same mistakes we made in security, which is, let’s stovepipe every type of security. This is your intrusion prevention. This is your firewall., this is your … fill in the dot, right? As long we’ve got one of all those, we’re good. We’ve done that with shift-left and things like code scanning. There’s a lot of elements to it, but I’ve come to think about it, as you mentioned SDLC, which is exactly right. Think about end to end. How do we design security? And how do we operate in a secure way in all the processes, the workflow steps along the way?
But also think about, yes, here’s software we’re building and we’re adding into that from external sources. There’s also, what about the whole pipeline underneath of the tools and technologies that we’re doing for our DevOps workflow CI/CD. That has to be secure as well, because software supply chain, not just the ins and outs, but the whole process in between. So I think we have to bring in our security teams, because they know this cold. They’ve learned those lessons and so many things. You’re talking about containerization and microservices. That looks a lot like nodes on a network communicating over a protocol using secure mechanisms. We’ve got some great expertise that, combined, we can do some powerful things together, I think.
Paul Nashawaty: Absolutely, and when we look at it, talking about from the build perspective, you have applications that are being built. You have new executive orders being put in place every day to think about how these applications are being treated. With acceleration of delivery, what we’re seeing in research, we’re seeing, Jack, we’re seeing that in a recent study that we did, 24% of respondents indicated that they want to release code on an hourly basis, but yet only 8% can do so. That means releasing code on an hourly basis. That’s very, very rapid. But when you think about that, what does that mean from a security and building those applications?
Jack Poller: Well, fundamentally the challenge is, is security a bolt-on afterthought? Or is it really baked into your process and your product and your process at the beginning of time? If you don’t think about securing, how do you secure your product? How do you secure access to your product? How do you do logins? How do you protect the data? How do you protect the telemetry data, the log data, all of that? If you don’t think about that at the beginning of time and design that into the product, then when you go on a rapid CI/CD environment and you’re doing releases every hour or every half day or every day, or even if it’s every week or every month, it really doesn’t matter. It’s hard to play catch-up with product functionality and security at the same time. What I would really like to see is, I would love to see if DevOps organizations could think about compensating and goal-ing their developers on both application functionality and security, rather than on application functionality and schedules.
Paul Nashawaty: Yeah, that makes-
Jack Poller: I think that’s really critical.
Paul Nashawaty: Yeah, it makes sense. It makes sense. I did some trending data over the last few years and I was showing testing as part of the CI/CD pipeline. We were seeing that in 2022, the research was showing that only 29% of organizations were doing their testing as continuous testing. But yet in ’23, that number jumped up to 66%. And it’s because you don’t want leave your testing to your end users, because that’s not a good way to do it, right?
Jack Poller: No, it isn’t.
Paul Nashawaty: But you touched on something here that I think is interesting. And Mitch, you were talking about when we look at the whole SDLC and such. Releasing code has to have almost a template or a blueprint in it, right? When we think about the impacts of code and security, one way to overcome some of these things is have that SBOM in place. How important are SBOMs when it comes to that fast release or agile release process for DevOps?
Mitch Ashley: I think SBOMs are a starting point. Right now, we’re at the generate an SBOM stage, which is really just taking a picture. It’s like the Amazon delivery person saying, “Here’s your package on your doorstep.” It doesn’t mean it’s there when you get home, right? Things have changed. I think that the kind of shift we have to make is software is a fluid process. It’s a liquid. It’s not a solid state, because everything around it and in it is changing all the time, whether it’s our own stuff or we’re talking to a SaaS service or a database or a security system, whatever it might be. So part of this fast delivery, I think put it as quality. You don’t go, “Let’s fix this thing and now our quality is fixed.” It’s a continuous improvement process. Security is the same way, right?
Because you don’t always build it all in up front. You’ve got to add it as you’re going and building up your application or your product and you improve the security over time. You’re continually investing in it. So while most of us are not going to release once an hour, that’s not just in the DNA of people’s ability to do it, to consume it once an hour. We do need it to be able to release code in an hour in an incident situation, either a bug fix or security. It’s one of those, just because we can, doesn’t mean we have to. But when we need to, we do want to be able to do that. And that’s where that repetitive process, having that down and working when we need to call on it, we’ve got that nitro boost that we can get something into production.
Jack Poller: Right, and that also means as you’re thinking about, how do I enable my organization to do this thing to move so quickly, is what are all the different things involved in along that process? It’s not only the code release. It’s not only the SBOM at the time of that snapshot point in time. But it’s also, what is everything else around it? What’s the security picture for the code release? And how does that work in my environment? And if I’m releasing once an hour, that may be one sort of environment. But let’s say we’re releasing once a month or once a week, right? You may release code on Monday, but then on Tuesday the security environment changes. How does that impact the code? So that goes back to that continuous testing, that it’s a fluid, dynamic environment. It’s not a point in time, discrete environment that we now live in.
Paul Nashawaty: So Jack, I think that’s a good point. Are tools like CVEs and code scanning, is that enough?
Jack Poller: No. Well, in the cybersecurity world, we believe in what we call defense in depth. Some people call it belt and suspenders, right? There are so many different attack paths and so many different attack surfaces that app developers don’t necessarily understand because they’re not versed in security. They’re versed in their own application functionality, that we need multiple tools in multiple ways of protecting everything we have. So you need to look at scanning your environment to make sure it’s up-to-date and all that’s patched for existing CVEs. But you also have to look at other things like your identity infrastructure.
Who has access and why? Are you in a traditional castle and moat environment? Or are you in a zero trust environment? and what does that mean for your application security and your application developers? And how do they work around that? What type of tools do you have for doing forensic investigation? When an incident does occur, can you go pinpoint exactly what happened, who had access to your environment, who had access to the data? What else did they touch other than your application if they broke your application? All of those types of things are part and parcel of securing your environment.
Unfortunately, it’s a very complex thing to do, which is also why I think we touched on it earlier in another conversation. But this concept of DevSecOps, DevOps, where does security fit in? Is a DevOps person a developer primarily? Are they an operations person primarily? Is a security person a DevSecOps person because they’re doing security in a DevOps world? There’s a lot of different facets to cybersecurity in this rapid development environment?
Paul Nashawaty: I like where you were going with that, because one of the things I was thinking about is there’s a convergence between the security approach and all the different actions you take to touch the applications. But there’s also the development aspects. A trend, I won’t call it a trend, I guess a movement that we’re kind of seeing in the application development space is a slimming down process to remove or reduce the attack surface space.
So basically when you modernize an application and put it into a microservice, instead of having the common elements replicated across multiple microservices, it’s having a microservice with the common elements in it. Then only have the business logic on certain containers so you can reduce that attack space. Yes, there are some risks about doing some of this, but for the most part, that does reduce the attack base. Mitch, do you think that’s a good way to approach software development in the context of all the areas you have to think about with security?
Mitch Ashley: Well, just to ingratiate Jack to me, it’s a segmentation approach. It’s the same idea as in network security or in security in general, which is let’s do small modules, small functionality, things that are more atomic or can be isolated. Then we’ll scale that up, right? So we can run as many of those as we want if they’re containerized or they’re microservices. I think that the good thing is that network folks can understand more than just ingress and egress into an application through APIs.
They can understand that, oh, we’re using APIs for all these things to talk to each other. And we don’t always know what’s going to go external and what’s not, right? How do we control that? We can do that through gateways, API gateways, and security identity, machine identity. Who’s allowed to talk to who? So all those principles still apply. They’re just easier to map to a software architecture. I think that makes that conversation. If I’m in the software peanut butter and you’re the security chocolate dude, we can talk. We know how to make that connection. Where before, it’s like I don’t understand you developers. I don’t understand security people.
Jack Poller: But if I may, it brings up one thing. You brought up a favorite topic of mine, is machine identity, right? Machine identity was really easy in the old monolithic application world where you had one application. If you think about even as we got into the cloud world and you had the traditional LAMP, Linux, Apache, MySQL, PHP stack, you had one application talking to one database, talking to one web front end. It was a very simple environment. There was one machine identity for everything. Now in container service environments, you spin up new instances rapidly all the time.
You can go from one to a million almost instantly. Every single one of those needs a separate machine identity that has to somehow be validated, verified, and checked before, from the network perspective, before you even allow the communication to occur, right? So again, it just very quickly goes from that very simple environment to very complex. How do I manage machine identities when I have thousands and thousands of machines, rather than 100 and I can manage it on an Excel spreadsheet?
Mitch Ashley: Well, to that point, if I can jump, in all of those identities and all that communication, guess what? It’s all encrypted. So there’s all certificates behind it, right?
Jack Poller: Yes, exactly.
Mitch Ashley: API certificates, which we understand from the network world. The challenge is the life of those certificates might be seconds or minutes or under an hour, constantly being rotated. Software folks don’t want to mess with that, more or less understand how to want to understand how to manage all of that. That’s another place where security can help set up that infrastructure. We know how to manage a PKI. We know how to manage certificates and rotation of keys and things like that. So I think that’s another one of those critical ingredients you want to add into the design, into the infrastructure, wherever that starts and stops. It’s not always clear, but that’s what creates secure underpinnings of software you can build apps on.
Paul Nashawaty: No, it certainly does. And you touched on so much there. You both did, but Mitch, I think this set the segue up to a conversation around service mesh in north, south, east, west traffic, which we’ll probably have at another time because running out of time right now. But with that, I want to thank both of you for your time and your perspectives on this topic. It’s really an important topic. For the audience, it’s just really the tip of the iceberg. So with that said, to learn more about what we have to offer in our research, come to TheFuturumGroup.com to learn more about it. And with that, have a great day and thank you for your time.
Other insights from The Futurum Group:
Enterprise, Cyber Resilience, and Hybrid Multi-cloud Storage – The Futurum Group
Insights from JFrog’s State of the Union Report – The Futurum Group
DH2i DxOperator Redefining SQL Server Containers for Kubernetes
Author Information
At The Futurum Group, Paul Nashawaty, Practice Leader and Lead Principal Analyst, specializes in application modernization across build, release and operations. With a wealth of expertise in digital transformation initiatives spanning front-end and back-end systems, he also possesses comprehensive knowledge of the underlying infrastructure ecosystem crucial for supporting modernization endeavors. With over 25 years of experience, Paul has a proven track record in implementing effective go-to-market strategies, including the identification of new market channels, the growth and cultivation of partner ecosystems, and the successful execution of strategic plans resulting in positive business outcomes for his clients.
