Red Hat’s Transformation Specialist and DevOps Evangelist, Michael Ducy, discusses Red Hat's industry-leading enterprise open source tools for DevSecOps success.
Rich Savage: Thank you for joining us today. This is Rich Savage with the Red Hat team here at Carahsoft. I'm here with Michael Ducy, Transformational Specialist and DevOps Evangelist with Red Hat to talk about the impact that DevSecOps is having in the public sector. To get us started, Michael, can you please take a moment to explain the important distinction between DevOps and DevSecOps?
Michael Ducy: Sure. If you think about the journey that we've had the last 10 years with this term DevOps, one thing that people started pointing out is that there's so much more in the production life cycle of an application to actually get that application out to the end user that an application goes through. And we've had several different movements over the last 10 years or so around how people thinking that the base idea of development and operations coming together then tends to exclude a lot of people. There's a couple of different schools of thought on that. I'm personally of the idea of, "Well, it's not exclusionary. You just need to go and jump in and play well with these development and operations teams and you're probably underneath operations anyway." And then there's another mindset of where you want to take this hyper-focus to where you're actually including these organizations by explicitly calling them out.
And so that helps you as you go through this development and operations process. It helps bring security to the front of the mind of the developers and the operations people. It's not necessarily that they weren't there all along when you were just doing DevOps, but DevSecOps tends to be where we've decided to put this hyper emphasis on it because we are running an environment where our security needs to be the number one priority over moving fast or releasing code quickly. So the idea really is, how can you begin to bring security as we tend to overuse the term, shifting security left, as much as possible early in the development cycle, and then making sure that it's considered all the way through your cICB pipeline and all the way into operations?
Rich Savage: Great. Thank you for that, Michael. What are the advantages of integrating security into the full life cycle of an application?
Michael Ducy: One thing to remember is, as you're having any sorts of tests or gates. So security has always been a gate that we've had to pass. And what we tended to do was have the security gates very late in the development cycle, either in the code development cycle or in the code deployment, the release cycle. And so you would have all these things that you would do very early on, build, unit testing, integration testing, soak testing, and then get ready to release your application. The security team would come in and check off on it. And then if it's not good, then you would have a feedback loop that would go back into development.
But then you've had all this work that's been done between those build, unit test, integration and so forth. So what you want to try and do is have in-build, in-unit, in-integration, security gates or security checks that are relevant that part of the development life cycle. And so by shifting it left, you're able to catch the security problems earlier, and then you're able to actually go and fix them because you're getting that feedback to where you can actually go in and make those changes and fix those things versus it being this massive checklist that's done all at the end.
Rich Savage: How has shortened development cycles increase the urgency for security in applications? I feel like those two things are related in a way.
Michael Ducy: Yeah, they are. And I think when you tend to go quicker, you tend to take shortcuts. So that's where things like code scanners are really important where you can actually go and see, "Are we sanitizing inputs? Are we following best practices around how the actual code I should be writing looks and how it forms?" The other thing is, when you're trying to have a shortened development life cycle, the thing that's also very popular nowadays is frameworks or pulling in code from npm or other artifact repositories.
You don't necessarily know what's going in to the application. So developers are looking for shortcuts, not wanting to recreate a library that already exists out there, go and get an open source library, bring and pull it in. But nobody's went and actually vetted that code to actually make sure that it's something that we want to be including in our production builds. And so that's why it's very important to make sure that you're having those security checks very, very early on when you're going through this mode of try to deploy more frequently because developers take shortcuts and you need to be able to find those shortcuts very early on in the development life cycle.
Rich Savage: As one of the leaders in DevSecOps, how does Red Hat integrate end-to-end security with DevSecOps?
Michael Ducy: One thing that makes us unique around what we do with Kubernetes is, Kubernetes is a great platform for building a platform as a service. If you go to the Kubernetes documentation and pull up, "What is Kubernetes?" It basically says that it gives you all of the components that you need and all the pieces that you need to build a platform as a service. And then when you start mapping out what you're actually going to build to actually have a fully functional path on top of Kubernetes, you realize there's a whole lot of work that you need to do. So what we've done at Red Hat OpenShift is we've started to include all of those things that you need to actually have a fully functional path using open source software. So beyond Kubernetes and including things like Prometheus, Source-to-Image, other things as well in the open source community.
And then what this allows you to do is basically build what we call a trusted software supply chain to where you can actually move your code from your developers, we can also give you the tooling that you need for the developer experience that gets pushed into OpenShift's trusted software supply chain. And then through that trusted software supply chain, you're able to integrate security at each step of the build process, the integration process, unit testing, and so forth, and actually have an application that can be deployed out as well on OpenShift through those different testing phases as well.
So they can make sure that the actual security testing is being done against live running machines and just not something that's being done in a theoretical way. This whole idea of the trusted software supply chain where you can have this common way of deploying software, at least a common framework for deploying software, and then each individual team to make the steps of that trusted software supply chain relevant. But the security teams can define what that trusted software supply chain looks like on a high level, and the minimum required dates that you need at each phase of that trusted software supply chain.
Rich Savage: And Michael, sitting down with a customer, how do you recommend that customer's automate built-in security and adopt more Agile development practices?
Michael Ducy: There's a couple of different ways to do it. I take more of an operational focus because I don't really have a strong development background. I gave a talk at the Kubernetes KubeCon North America in San Diego back in 2019. And in this talk, me and my co-presenter talked about this idea of all the different things that you need at the different phases of a DevSecOps pipeline and it's pretty overwhelming. But what you need to do is you really need to start to understand, "At the build phase, I probably need things like source code scanning. At the integration phase, I probably need to start scanning the rest of my libraries and things like that to actually make sure that what I'm integrating into my application are going to be something that I want to ship to production." You need things like image scanning to make sure that you're not shipping vulnerabilities.
And then also, once you've packaged your image, and your application in your image, you need to make sure that you're doing that image scanning. These are the things that we've been talking about for a while. But one thing that I like to also think about is, how do you actually test the application in production? And how do you make sure that the application, when it comes up, it doesn't start doing something that you don't want it to do? And these code scanners don't necessarily always check that the container is not running something that you don't want it to do, or the application, all of a sudden, has some weird backdoor in it that you don't know about, or all of a sudden, it starts communicating that with the service that you don't know about. And so you can also integrate things like Falco, which is a CNCF project.
That's about container runtime security. It's actually watching what the container is doing, seeing what network connections it's opening up, see which files it's opening up. You can have these profiles for each application to say this application should only be running these processes, touching these files and making these network connections. And then if the application or the container image does something beyond that, you can then really start to understand that the container image is compromised somehow. Or it may not be compromised, it may just be doing something that the developer didn't tell you about. And it gives you a chance to go back and communicate with the developer to talk about what they're doing, what they're trying to achieve, why this port needs to be open, and then further then whitelisting that port or allowing that port to be used.
Rich Savage: Well, it's definitely some good advice for our audience. Do you have any success stories in the public sector that you would like to share?
Michael Ducy: Yeah, there are. What we're finding is, is there are pockets of innovation. And I feel like this is the same thing that I saw when I used to work at Chef, and we were talking heavily about automation and infrastructure as code. And usually what you end up finding is, is there's a pocket that does something and an organization that does something really, really well, and then they start to scale that out across the broader organization. So that's what we're currently working with, it's finding those pockets of success, and then taking that pockets of success and scaling it out using what we call a Dojo Model.
Of course, that's not something that we came up with. It's something that the DevOps community has been talking about for a number of years. But the idea of the Dojo Model is where you take this team that's been successful, you replicate what they did, and you have a new team come in. That first team trains the new team to basically learn the methods of DevSecOps, the methods of Agile or scrum or whatever development processes you want to use, the new ways to do operations, SRE best practices and things like that. And then also building cross functional teams. So you have these cross functional teams that are working together on the project.
They spend about eight weeks on the project. And then at the end of it, they deploy their new or modified application out into production. And now, you've built this muscle memory in this new group of people that they can then go back to their organizations and have this new way of working with their counterparts. And then you just keep cycling people through this eight week cycle where they start to learn this new way of working in this new behavior. And that's what we tend to find to be fairly successful is running these Dojo type models, and then having the organization take it away from Red Hat. And then eventually, Red Hat steps back and they can run these Dojos on their own.
Rich Savage: Thank you, Michael, for all of this great insight. We really appreciate it. For our listeners, if you want to learn more about Red Hat DevSecOps, we'll have additional resources here on the podcast landing page that you can check out. And of course, you're always welcome to contact us any time at redhat@Carahsoft.com or (877)-742-8468. Thank you and see you again next time.