How do we modernize security and compliance while keeping software delivery fast and effective? In this expert panel from Prodacity 2025, industry leaders dive into the challenges of DevSecOps in federal agencies, automating compliance, and why Zero Trust is more than just a buzzword.

Featuring:

• Chris Hughes – Co-Founder & CISO, Aquia
• Mackenzie Wartenberger – Director of Security Engineering, Aquia
• Brian Panarello – Principal Architect, Google Public Sector
• Will Kline – Cloud Security Engineer, Space Force

Panelists discuss how security teams can become enablers instead of blockers, why compliance frameworks must evolve, and how platform engineering can make security a seamless part of the development process. If you’re tackling ATO, cybersecurity policy, or DevSecOps in government, this is a must-watch discussion.

🔹 Key Topics Covered:

• How federal agencies can implement DevSecOps without slowing delivery
• The real meaning of Zero Trust (hint: it’s not something you buy)
• Why compliance isn’t security—and how to fix the gap
• How platform engineering & automation make security seamless
• Lessons from Space Force, civilian agencies, and commercial tech
• How AI & automation are changing the future of compliance

🕒 Key Highlights & Timestamps:
[00:03] - Introduction: The three pillars of security modernization
[02:28] - Why compliance teams must shift from gatekeepers to enablers
[05:57] - DevSecOps vs. DevOps: Should we remove "Sec" from the term?
[08:14] - ATO automation & how to eliminate security bottlenecks
[10:52] - Zero Trust isn't a product—it’s a methodology
[13:25] - The challenge of securing legacy applications & infrastructure
[17:41] - How Space Force accelerated software delivery with security built-in
[19:49] - Why federal security teams need to "hide the veggies" for developers
[22:42] - Final thoughts: The future of security & compliance in government IT

🔗 Stay Connected:
Learn more about Prodacity: https://www.rise8.us/prodacity
Follow us on X: https://x.com/Rise8_Inc
Connect with us on LinkedIn: https://www.linkedin.com/company/rise8/

👍 Like, Subscribe, and Share:
If you’re working in federal IT, DevSecOps, or cybersecurity modernization, give this video a thumbs up, subscribe to our channel, and share it with your network. Security should be an enabler, not a blocker—let’s make it happen.

‍

Chris Hughes (00:03):

Tha nk you. Thank you. So we're excited to be here. We've got a bit of intros already out of the way, so we're going to dive into it right out the gate. We've heard a lot today about compliance modernization, automation, resiliency from a previous speaker, and there's kind of several threads that we see are underway, which is the compliance modernization automation piece, zero trust and digital resiliency, and then platform engineering or as we call it in the DOD software factories and platform as a service. So I wanted to open with asking, perhaps each of you maybe start with BP on the end there. How do you see those three converging? Do they compliment one another, contradict one another? What are your thoughts given your experience

Brian Panerello (00:40):

In the agile world? We talk a lot about integrated teams and working with one another and building towards a common goal, and that's really what we got to focus on. Cybersecurity needs to be part of the team, part of the platform team. Part of the development team needs to be entrenched in with the discussions that are happening during design phase and really you can build this integrated platform that hopefully does everything that you need and becomes part of that. So yeah, short and sweet.

Chris Hughes (01:05):

How about you Mac?

Mackenzie Wartenberger (01:06):

Yeah, I think we throw around terms like secure by design a lot, but involving the security piece early so that it becomes an enabler. I am a zero trust accolade. I think I'm in good company up here and the idea of having that strategy at the start so that it's baked in and you're not coming back and saying, no, you guys can't do this, or No, this doesn't work, but knowing ahead of time that we're going to use security as a driving force and not something that's a blocker.

Will Kline (01:34):

How about you? I do a lot of work with developers primarily, and one of the challenges here is that the way that the security folks have traditionally brought into the party is they get invited late and they just tell everyone, no, no, no, no, no. That obviously builds some animosity because at the end of the day, developers are going to develop and try to deliver mission on the things that they care about and if security is standing in the way, that's going to be a problem. So a lot of this is trying to talk to developers on my side is how do I introduce them to what these risks actually are so they can visualize what does a SQL attack look like? Basic things, and then once you start building that platform of security knowledge on their side that they kind of geek out about a little bit, then when the security folks can come in and start talking about these concepts, they understand, oh, this is not some abstract thing that some button pusher needs to check a box. This is a very real capability that's building and adding to the thing that I'm trying to build. Absolutely.

Brian Panerello (02:28):

Go ahead. So I was just going to say one of the first talks earlier today was talking about that culture and understanding the why behind things. It's one thing to come in and put down the iron fist and say, you have to do this because RMF says you have to do this, but it's another thing to sit down with the developer and explain from my perspective as a cyber engineer, this is what I need to see. How can you help me get to that point? Let's work together as a team and let me explain to you the why of things. Then they start to understand. You find that commonality,

Chris Hughes (02:53):

Right? Yeah. It's funny, in cybersecurity we often hear all the tech mumbo jumbo and acronyms and buzzwords, but you're talking about empathy, communication, building trust, rapport with your peers. I think that gets lost in our community sometimes. So giving you all have a mix of federal civilian experience, department of defense experience, and he kind of talked about building guardrails in, we've heard like pave paths, terms like that. What are some examples you all have seen of building those kind of paths for developers so that they don't have to necessarily worry about ATOs 853, the litany of security controls that we all love and bemoaning at the same time? What are some examples you've seen at different software factories or platforms you've been working with and perhaps start with BP again,

Brian Panerello (03:34):

So you're forgetting all the overlays and everything too and how complicated it all gets, right? You can do this unless you're this, then you have to do this and well, why do you have to do that? No, but getting back to your point, what was your point? No, I'm just kidding. Getting back to that again, it comes back to I love that you brought up empathy and I love that you brought that up. I'm a huge advocate of I'm not a developer. I want to let the developers develop, let the developers develop. That's what they do. Good. Let me do what I do good so that I can let you do what you do. Good. We worked on a space force project together and that was a core principle of the design. We're working on some Google stuff together. That's a core principle of our designs. Let the developers develop, tell them what they can do, not what they can't do, and then put the things in place to make sure that they stay on their track and they're able to do what they do best. I hate the term DevSecOps because that puts, cybersecurity is everybody's job, right? We've heard that idiom a million times, but I like DevOps. Take the security out of the thing, just wrap the platform and security. So security becomes a byproduct of the actual platform itself.

Chris Hughes (04:37):

Yeah, I think we've had to create that term. Just on that note real quick, we've created that term because security got lost in that discussion and then we've kind of bastardized it to be DevOps, but the reality is we're trying to deliver mission outcomes by delivering code to production. Security shouldn't be proceeding that, in my opinion, unless you're baking it in or building it in. We're talking about, so how about on the federal civilian side or some examples you've seen?

Mackenzie Wartenberger (04:58):

So it's interesting, will you were saying the challenge for security teams I think on the DOD side and the feds side is that you don't want to be the no no people, but that's kind of where we've become security has been left out of the conversations. Now we have to kind of come in and be the bad guy on the fed civ side. I think because we have a more complicated, I don't know how many of you work on the civilian side of things, but we have a more complicated system. We don't have the kind of easy centralization points, but it's introducing centralization as much as possible, which makes it easier for us to secure systems, but also much simpler for people to build systems. I think it's really easy for things to get super disparate and spread out and you get that sprawl to trying to find ways to claw that back in. We've been talking a lot about identity backstage and using that as a touchstone to not overcomplicate things for teams that are building but actually simplify and speed things up and security then becomes a byproduct of that centralization.

Chris Hughes (05:57):

Anything to add to that will,

Will Kline (05:59):

I think that's always my big thing when I'm working with BP on projects is I think that the challenge that as a young developer who got dropped into EXACTA one day and told Shall do an ATO package, the really hard part is trying to read these abstract controls would describe a vague vibe of what they're trying to go for. It's hard to tie that back to a realistic, don't do this, do this. And that's something that VP and I always work on is like it's not enough. Even on a technical response level, when you're building out the controls and guardrails on an a s environment or cloud environment, it's not enough just to say, slap their hand, electrify the fence, so to speak. It's not enough to do that. You have to provide meaningful guidance of this is what I intend you to do when I'm writing these security controls and provide a path to 'em because they're going to find it. And when you lock, you pen your developers too much, you suddenly find that you have a huge team of internal pen testers that aren't reporting to anyone and they will

Chris Hughes (06:56):

Find a way out. Yeah, I love what you said there because I feel like we see shadow IT or shadow whatever, and it's because of our behaviors, in my opinion that we get locked out, they put working with us, they work around us, we actually create risk by the behaviors that we kind of put our developers underneath and how we behave towards them and they leave us out of conversations like you said. So on the zero trust front, everyone is hot on zero trust right now. It's a hot topic. Everyone's trying to move forward on that, but we kind of look for shortcuts. It feels like everyone's looking for the quick fix or they want to buy zero trust. And we've had a conversation backstage about how zero trust is not something you buy, it's something you do, right? It's a behavior, it's a methodology. I'm curious, as you all have been working with your engineering architect, development peers, et cetera, how do you kind of get that across that, hey, this is a behavioral change, not something we can just drop in with a purchase perhaps? Start with you Mac on that one.

Mackenzie Wartenberger (07:49):

Wow. Yeah, and I think you hit it perfectly, Chris. Zero trust is a buzzword and it is a buzzword, but I think that's kind of gotten co-opted by the vendor community and now it's like, okay, here, buy this tool and now you are zero trust, whatever. And we've been talking, I think the crux of this entire conversation is around frameworks and strategies and how do we use those to make security easy and make security a kind of a catalyst for transformation in general. How can we modernize? How can we streamline and be secure? Zero trust is exciting. It is this more prescriptive strategy regardless of if you're kind of following the DOD model or the cis a model on the fed civ side, we're a little behind the DOD because we don't have that great mapping that's bringing compliance and zero trust kind of into the same conversation. But I think it is talking to stakeholders that know they should be doing zero trust. They know there's executive orders that are telling them to do zero trust, but they're also being told by a vendor community that this will solve that for them as opposed to looking at the entire system and thinking, okay, I need to do a criticality analysis, figure out how I make these frameworks and these strategies align with my mission. Zero trust is just one piece of that and then building a roadmap from there

Chris Hughes (09:15):

Makes sense. How

Brian Panerello (09:15):

About UBP? So I'm probably going to, I don't know if you saw, they brought me an emotional support microphone. Hopefully you guys can hear me a little bit better now, but I'm going to probably say the loudest secret that everybody knows. Zero trust is not new. We've been doing zero trust since the advent of computers and cybersecurity. It is nothing new. We just keep calling it different names and slapping it on the label of whatever product is trying to be sold to us. Sorry to all the vendors. I love you guys, but how many times do you go out and see a product that is magically overnight? Now it's AI enabled and Will and I have talked about this, this is the exact same thing you were doing five years ago, but now you're calling it zero trust or AI enabled. We've been doing it since the beginning. Zero trust is not easy, but it's simple. It really is simple, right? Trust no one verify everything. Give somebody the least amount of privilege you can give them in order to get their job done. That's such a simple thing to do. It's just not easy. Right?

Chris Hughes (10:23):

Yeah, I was going to say, I think that's well said. I love like Scooby do meme where they pull the mask off and it's like zero trust you put off it's like least permissive access control microsegmentation. It's like, oh, these are foundational concepts that we have been trying to do for a long time. And you mentioned the mapping, right? And DOD has that mapping of zero trust to RMF, right? Which is a great resource, but I'm curious from your perspective, each of you, how do we avoid it becoming a compliance paperwork exercise where we're just checking the boxes, we're doing the things, but we're not really measuring the outcomes like the previous speaker was talking about.

Brian Panerello (10:54):

So again, going back to the way that Will and I worked together, we've been working together for about two years very closely now. One of the design principles we have always had was build a safe sound and secure system and let the compliance piece document that you should let RMF work for you. You should let compliance work for you, not the opposite way. We should not be designing a system to be compliant. The system should be compliant because we designed it well and we allow them to come in and document it at the end. If you start throwing at your developers all these zero trust overlays and the controls, and now we've got A-C-N-S-S-I on top of that and we've got our PI overlays and we've got all these things, they're going to look at you and say, this is not my job. I refuse to do this. Or they're going to be so overwhelmed that they don't know what to do. So just build a good system that's secure and using all of the secure design principles we've been doing since the fifties and you're going to be okay. Let RMF be the documentation piece, not the architectural framework you use to design your platform. Right.

Mackenzie Wartenberger (11:54):

Go ahead.

Will Kline (11:54):

Oh, sorry. One of the things that BP and I run into a lot is that I think one area that you really can wield the frameworks as a weapon here and really get work done with it is when you're dealing with legacy applications that are developed under some other mindset. I know there's been a lot of talk yesterday about we shouldn't be developing new platforms, we should be buying platforms. But realistically, a lot of the really trends hard problems are living down in the basement on a single server someplace that we just hope that nobody ever goes in there and tries to access because it's not encrypted. It's

Brian Panerello (12:25):

Running re four.

Will Kline (12:26):

Oh yeah, it's some re L six monstrosity that's still up and running. And I think one of the things that we've run into is that a lot of these systems security happened and their value really gets delivered by the list of other systems that they connect to as we build this complicated framework, right, or system. And that's one of the things that we've talked about here is the idea that you start with something simple and it evolves over time. So when you pop your head in and say like, oh, I can replace that, you also have to start simple and evolve over time. And that giving the zero trust framework and tying that back to the controls really gives you a weapon to come in there and say like, okay, I can't change everything about your business case today, but please for love of God, just meet these couple controls and I'll help you make it easy. Let's figure out how to make this work. And it presents a way to say, I'm not the bad guy here. This is the I can help you, but we got to do it. How about you, Mac?

Mackenzie Wartenberger (13:25):

Well, we were talking backstage. I feel like compliance gets a bad name. I was a GRC analyst before I became a security architect. So compliance is designed to make our system secure. It's become a box checking exercise for in a lot of ways, but the ethos behind it is security. I think zero trust is exciting and we were joking about teaching to the test. We want our students to understand why security is important, not just try to get a hundred percent on the test. Zero trust is an opportunity to do that because it is more simple and there are these tenets that you can wrap your mind around, okay, this idea of lease permission, identify everything micro segment because assume breach people are going to get in. If that is this overarching theme to the way that we're addressing security and compliance, it allows you to identify how to make compliance important again, and not just a box checking exercise. Zero trust can be that catalyst.

Chris Hughes (14:24):

Yeah, I feel like comments that both of you made in terms of compliance not being the enemy and then also willing as a weapon because people who've been practitioners in security know that in the absence of compliance, the idea that we would get anyone to focus on security would probably be even worse than it is now. But at the same time, compliance is the floor. It's not the ceiling. It should be what we're striving for as a foundation, but we build on that from there. So I want to ask you, you all have been doing some great work around cloud native access points and we hear the zero trust is identity centric model rather than a legacy kind of perimeter, castle moat and kind of methodology. Let's hear about some of the work you guys have been doing on that front and maybe start with will here.

Will Kline (15:00):

Yeah, well, I mean I think one of the obvious use cases is something that the Space Force project that I was speaking about where a lot of the entrenched systems are currently this VPN connects to that VPN and this endpoint, it's not quite SIPR , it's not quite NIPR. It's kind of this in-between gray space of things. And they're all interconnected and they have different access controls across them and it is really difficult to get information from one end to the other because if I'm on a Ts network and I'm sharing information, there's boxes to check to make sure I'm not sharing with the wrong people. But fundamentally, the network is designed in a way to share that information back and forth and really the delivering data to the people that need it and the stakeholders is the reason we have networks. So it's been really complicated to unweave that web, but zero trust in cloud native access points has been really powerful tool there because we have these people, that guy over here in California needs access to this data over here and because we've invented reasons to not connect these people, we have to burn it to a disk in between and send it as an email.

(16:02):

What are we doing here? Cloud native access points and identity-based networking allows us to securely open that up so they can deliver the mission wherever they need to, not make sure the right person is delivering the mission and getting the data not the right location I guess.

Brian Panerello (16:19):

And it's really, again, it comes back to it's simple, but it's not easy. You have to front load it a little bit. There's a little bit of work, you got to get your hands dirty and get in there and get a little bit of work, but the end result is now you've built this system that operates on its own. It's this beautiful automated system that does all of these things on its own, gives you visibility into your network, lets you see everything that's happening on your network. The four main tenants of the CNAP is identity authorized, ingress authorized egress and continuous monitoring, which if you build this thing, it works and it allows the mission to happen. And again, we're in 2025 and still burning things to disk or sending things over email and why are we doing that still when we have the capability? Because again, compliance isn't the enemy, but we often use it to not do the work. We often use it as an excuse of why we can't get something done. Brian Kroger at the very beginning of this said, let's get rid of this cynicism and let's look at what can be done. Stop saying we can't do it, we can do it. And people have been doing it for years, Netflix, Google, they've been doing it for years. There's no reason we can't do it. Right.

Chris Hughes (17:26):

Yeah, I think it's switching to you can do it and here's how you can do it securely or at least get the risk. Right. I'm curious, Mac on the federal civilian side, you've been doing work around identity centric zero trust and MFA and phishing resistant MFA, et cetera. How can you build on that? Some of the parallels we hear from them

Mackenzie Wartenberger (17:41):

Well, and honestly being on the Fed side, I'm very jealous of our friends in DOD land because it's a lot easier when you've got a bigger stick to centralize that stuff. But again, like BP was saying, it all comes down to identity. How can we make identity more secure for both users that are external and internal team members? That's harder because we don't have that great centralization yet on the side. But I think when we're looking at FI oh two compliant MFA, either we're doing that digitally or we're using hardware to do that, making sure that we're thinking about identity not just for people and nmps, but thinking all the way down. We were talking about data and how scary data is that data pillar in zero trust, but it's critical and that's where you have to do that. You got to eat your vegetables in the front end and build that system. But the beauty is once you do it and you bring in some automation, it's sustainable. That work is short-lived and then it builds and you've got a process that is kind of self-sustaining. So that's kind of where we are on the civilian side for the agencies I support is using identity as that first stepping stone and really getting that to be secure on the external and internal side and then hoping that can build into other areas of the zero trust pillar

Brian Panerello (19:00):

Yeah, so you brought it up and one of my favorite things to say is us as cybersecurity professionals in building a system like this with the CNAP and all the continuous monitoring and the automated controls, I'm not a parent, but I know other people are parents and I know a dirty little secret that you hide the veggies wherever you can to get 'em to eat their veggies. That's what we do as cybersecurity folks. We got to hide the veggies in there so the developers can do what developers do, and they don't know that they're doing it securely. They just get the job done, the operators just get the job done, they get the data where it needs to go, right?

Chris Hughes (19:29):

Yeah, I think that all comes full circle to what we talked about, the platforms of building it in rather than bolting it on. So it's a fundamental aspect of what they do, and they don't even necessarily worry about the minutia and the details. It's just kind of there and enables them to do security the right way. We've talked about compliance quite a bit in the previous two talks actually talked about compliance and all the things that are broken with it. Paperwork processes, static time-based assessments, legacy GRC platforms, I'm not going to name any names, but that are not API centric don't integrate with pipelines and the cloud, et cetera. And I often quip that GRC missed the bus on DevOps. Everything went API centric microservices automation and GRC is still living in Word and PDF and Excel. I'm curious, how do we bring GRC along to get towards these outcomes we're striving for without burdening our development peers? I'm curious. Any of your takes, feel free to jump in there.

Brian Panerello (20:20):

Magic, oh, sorry. I was going to say my takes are probably hot and a little controversial, so I'll let the other folks speak first.

Will Kline (20:27):

I mean, I think this is one area where when we talk about, I hate it when tools just kind of sprinkle a little AI on something, but I think that a lot of what the GRC process comes down to is interpreting data from a number of sources, many of which are not well-defined, API JSON blobs that I can just ingest and consume, right? I need some way to read plain text of one type. Maybe it's a control response, maybe it's a Terraform code, maybe it's a section of Java code that's processing a header. I need to be able to grab all these disparate things and figure out which parts are relevant to then look at. And I think that's where is an area where I think the future of AI and LLMs being involved can help us meet that together until we decide to have the one API to rule them all, which kind of ends up being that XKCD comic where we're going to invent that. Maybe it's OSCAL, maybe it's not, but we're going to invent that and it's going to miss, it's going to cover 90% of the use cases and there's going to be those other 10%, and also nobody learns it anyways, and then we're going to invent it again, right? So we need to find ways to bring this all back to plain English that is understandable by everyone who's involved so we can have the same conversation, at least

Mackenzie Wartenberger (21:36):

Makes sense. How about you Mac? Well, you brought up Bosco and we were just talking about Osco because it has this incredible transformative potential to do exactly what you're saying, Chris, let GRC come into the future, but it's too hard. And that's the beauty of Zero Trust is it is so extrapolated, it's so simple. It's got these kind of really digestible pillars that should drive everything that you do. If you're a zero trust practitioner, I think that there is an opportunity to bridge between something that's ultra technical and GRC, which is a less technical kind of vertical of cybersecurity, and how can we use Zero Trust as a bridge between there? Can we make OSCAL something that is more approachable if it's OSCAL or if it's an iteration of something else through a zero trust strategy approach? Makes sense. Your hot take.

Brian Panerello (22:27):

I love everybody. Please come talk to me afterwards if this offends anybody. But we've got to get to a point where we have a common language. And in order to have something like that, we need assessors to understand what a container is. We need assessors to understand what an API is. There was a talk yesterday about involving them from the outset and on a project that Will and I recently worked on with the Space Force day one, before we committed a single line of code, we sat down with the SCAs and said, here's what we're planning on doing. Do you have any questions? We worked very closely with them. From the time we committed our first line of code to the time we achieved our ATO was eight months. They understood what we were doing and at every step. So again, it can be done, but we have to find that common language, be at zero trust, be at some kind of common language that we're all using that we all understand, so we can explain why we're not using ACAS to scan our containers, but it's on my sheet.

(23:23):

You have to have ACAS. It doesn't make sense. We're more secure by not having acas in the system, a single example. So just finding that common language, finding that common thing, and I think Zero Trust really does break it down. It does a great job. The DOD has done a fantastic job about providing guidance and making it almost so easy to consume with the pillars and with the overlays and everything. It does make it easy to consume, but we have to make sure we're all using, because we all work in a technical field, we all use computers. We're building systems of computers. We need to understand what we mean when we're saying this is a VPC.

Chris Hughes (24:02):

Yeah, fair enough. I mean, a lot of those folks, again, spend a lot of their time in Stack Documentation, PDF, Excel, they're not getting time to learn Kubernetes and containers and cloud and those types of things. And I think that's why leaning into technologies, we almost made it through without mentioning AI, Gen AI, LLMs. But for what it's worth, I agree. I think it has a lot of promise in terms of both digesting documentation and creating documentation. So I think it is going to be a value use case in compliance and GRC more broadly. But that said, we are out of time, so folks who want to chat, we'll be over there doing a Q&A and hanging out. So feel free to come find us over there and thank you all so much. Thank you.

‍