The future of warfare depends on software. In this high-stakes talk from Prodacity 2025, Donnie Hasseltine, VP of Security at Second Front Systems, explains why secure software delivery is now a core national security issue—and why the Department of Defense (DoD) must change how it thinks about compliance, acquisition, and DevSecOps.

Drawing from his Marine Corps background and experience in defense technology, Hasseltine breaks down the biggest security risks facing military software, why compliance must be automated, and how DoD can move beyond outdated security models to meet modern threats.

🔹 Key Topics Covered:

• Why software is now a strategic asset in national security
• The growing threats to DoD software supply chains
• How traditional compliance models are slowing down the warfighter
• Why "check-the-box" security is failing in modern DevSecOps
• The role of automation in securing software for defense & intelligence
• How commercial tech companies can better partner with DoD

🕒 Key Highlights & Timestamps:
[00:03] - Introduction: The intersection of national security & software
[02:11] - Why the DoD’s traditional compliance model is failing
[05:26] - The biggest cybersecurity risks in military software
[07:42] - Software supply chain attacks & their impact on defense
[10:14] - Moving from slow, manual compliance to automated security
[12:33] - The real cost of slow accreditation & ATO processes
[14:59] - Why "secure by design" must be the new standard
[17:20] - Lessons from private sector DevSecOps for DoD teams
[19:47] - The role of Second Front Systems in accelerating secure software adoption
[22:42] - Final thoughts: The future of defense tech depends on software security

🔗 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 defense, cybersecurity, or DevSecOps, give this video a thumbs up, subscribe to our channel, and share it with your network. Modern warfare is digital—let’s secure it the right way.

‍

Donnie Hasseltine (00:03):

So we've got self-driving cars, we've got electric taxis, we've got all kinds of modern technology. Every one of us has a supercomputer in our pocket with an immense amount of modern SaaS applications that can do just about anything. But what if we want to take those pieces of software, those applications, those tools that we rely on every day and get it to the war fighter? Well, if we want to do that, then you better make probably an 18 month calendar. You better thumb through your NIST SP 8---538. You better start mapping all these little pieces and kind of as was just talked about, and it kind of had heart palpitations what Andre said, it just now like spreadsheets, tears, and whiskey. He's spot on. I think more the last two than the first one. The bigger thing is once you've done all that, you still need to present reams of documents and artifacts to an accrediting official and that authorized officials probably not your mission owner who doesn't understand the use case for your software and for that aranian official to basically go in and approve it. They're going to rely on compliance analysts who don't understand your application architecture and who suffers from all of that, the war fighters do.

(01:13):

As mentioned, I spent 22 years in the Marine Corps before turning the dark side and becoming a cybersecurity professional. I love seeing Matt Parker's presentation earlier where he put the office space image. It seemed to resonate with everyone. That's my best effort to reproduce the printer smashing scene with war fighters. The other pick I'll say is pretty close to realistic depiction of me as a lieutenant getting frustrated with software and punching the computer monitor in front of me. A few minutes later, one of my marines came up and looked over and said, Hey sir, that cracked screen is an awesome screensaver. I'm like, yeah, it's not a screensaver. It's an actual cracked screen. So a missing damage gear statement and a trip to supply to get a new monitor Later. I was back in business, but we've all lived through some of these experiences here.

(02:00):

It's frustrating because we can walk through and see what right looks like and see how it work. But if we're in the DOD, we can't necessarily use it. So the technology, we need to be competitive in the world stage when we talk about near peer competitors and peer competitors just isn't available and it's not making the operators fast enough. This current ATO process, it's slow, it's expensive, it's document heavy. Everyone in this room is likely to experience some portion of that pain. It hinders innovation and probably I think worse than the innovation hindrance and the frustration we're talking about, it actually gives a false sense of security by obfuscating risk. We're doing all these manual processes and checking all these controls. What ends up happening is we get this sense that, oh yeah, we've done it securely. We've managed it securely. So we walk around thinking we're safe when we're really, really not the central idea here, and I hate to ruin the day for anyone. I got probably more questions than solutions and answers here, but how do we get to a point where we can have a modern automated real-time approach to GRC one that can streamline the ATO process, enhance security and actual enable that continuous compliance that we're all seeking?

(03:16):

Well, first, it depends on what your ATO journey is, and hopefully I'm not triggering anyone with a a pipeline up there and some of these other pictures, but the bottom line was built for a different age. It was built for different type of technology products and it's, it tried to adapt over time, but it hasn't quite caught up with that. There's really lengthy timelines. You all know it could be months, could be years to get an ATO. There's a massive documentation burden. Those artifacts are often outdated by the time you've submitted them or very soon thereafter, especially if you're running modern Kubernetes infrastructure. It relies on manual processes. It's inefficient, it's prone to errors, right? When I'm relying on a SCA to look through controls and read my implementation narratives to try to judge whether or not I've met the requirements, I mean, that's ridiculous and it doesn't scale.

(04:05):

I think that takes another point to it, right? It focuses on point in time security and compliance. If you're FedRAMPed authorized, you're going to submit up a asset inventory and scans once a month. Well, if you're a Kubernetes cluster spinning up and down daily, what good is that inventory and scan you just did? How useful is that for any sense of security and compliance? And I think it brings up that false sense of security, right? Checking the box doesn't secure an application. I think the way I like to look at it is compliance never begets good security. Good security should beget good compliance, but compliance is never going to get you secure. And I think when you do that, when you're not getting the cutting edge software into the hands of the people that need it, there's no ability to innovate because they need that software to try new things, to break things, to iterate off them, and to get feedback to get that loop going so we can keep pushing the ball forward.

(05:00):

So ATOs, were dreams die. That's kind of what I like to think about it. Now, it's important to think about it though, like let's step back for a moment and say let's some good here. These all start with good intent. I mean, there's nobody in the government who's trying to keep you from getting software to the right people. There's no one in the government who's trying to make things less secure. In fact, many times when I have conversations with aos, some of the most frustrating conversations I have are around questions where I have to step back and say, you know what? If the tables were turned, I'd be asking the same thing. The intent is there and they're trying to do the right thing. The challenge is, is they're stuck in an intractable bureaucracy. So when you take that good intent and try to drown at bureaucracy and then drown it in antiquated tooling, which kind of assumes and implies real time compliance is impossible, that's kind of where we get to this a ATO process, right?

(05:55):

It's a financial and resource strain and it kills opportunity costs, lost revenue, and when technology changes, those authorization processes are not agile. They cannot adapt. If you have any doubts about this, try to get something that has AI into the government now they have no idea how we can actually risk bound that and set it into conditions so it can be used because of that. You get in a situation where, hey, complex applications are very challenging, simple applications. You can sail that through the process. You can find probably way to get there. When you deal with a complex one or one that's ever changing, which most modern software is, you're in a situation where that AO is challenged to figure out what do that need to see to make sure they're doing the due diligence when they accept risk for the government. And that often turns into something like this, right?

(06:44):

What do you need me to bring you to show you that this application is secure and compliant? And the answer, the implied answer, oftentimes, I don't know, but I'll know when I see it. And that is immense amount of stress, frustration, and burnout, but not just on the application owners and the mission owners, but also really on the AO and the sky who has to figure out a way around this. They're challenged to appropriately assess and actually manage that risk and what those constant changes, having them be able to try to tell which one of these changes are risk relevant to the system, which ones are risk relevant to the government is incredibly, incredibly difficult. But because those antiquated tools, because of that intractable bureaucracy I talked about, you end up with things like this. I want to update and patch a system. Fine. Just follow this flow chart, and I didn't make this for the presentation.

(07:33):

This is an actual process for an unnamed government agency for impact assessments of software updates. So let's just say there's new malware out there and your CSSP or EDR pushes out new virus definitions for you. Or let's say there's a new feature you want to push out or a dependency like Log4J pops that's actively being exploited in the wild due to a zero day, and you need to find a way to plug that hole. Or your provider actually plugs that hole and says, here's the solution to get it on the software that's already potentially running. You have to go through this process to get some memorandum or piece of paper to say you can run that. Meanwhile, adversaries are having a field day on your application. These drawn out processes, these manual things actually add risk. I'd argue they're more designed to prove that you did something than actually identify and mitigate that risk.

(08:29):

So it gets to the point now of how do we come up with a solution and what should that solution be? I think the thing we need to understand is we can't wait for it to appear. There are things government does really, really well. This is probably not one of them. So what can we do to kind of keep track with that and drive it up there? Because if we just wait on the government, it's not going to happen. It involves all stakeholders, application providers, it involves mission owners. It involves AOs and SCAs, all of us to work together because all of us benefit from an improved process here. Laws and regulations do not keep up with technology. It's moving at a breakneck speed, and even when it was slower, they couldn't keep up with it. I love that. Brian Andrews, when he was on the fireside chat earlier, talked about being hamstrung by a 1929 procurement law.

(09:14):

Well, if I go in and hack one of your systems today and get caught, anybody know what statute the FBI is going to prosecute me under? It's 40 years old. It's computer fraud and abuse Act of 1986. Now you could say, yeah, it's been amended. It was amended in 2008 about the time the first iPhone came out. So it's 20 years old. How are we going to wait for regulation and government processes to keep up with the innovation and iteration that we're doing on a daily and hourly basis out in the field? We've got to think through this and think of what it would look like. So some of this we are making progress on in the private sector and even in the government, right? First thing is some of the stuff that Andres talked about, right? Integration with CI/CD pipelines. You should already be doing that.

(09:57):

You should already have automated software tests. You should already have automated security tests in your development pipelines. As you run those through though, have you now taken that second step using OSCAL other processes or every homemade things to make sure that when you push a change that you can actually tie it to the control it impacts and update that narrative. So at least you have the documentation that's needed to show that you've done the due diligence here. Does your change management process walk through a system or can actually now show you and show those government SCAs or AOs or anyone who asks what you're actually doing to address that risk? And then lastly, is the piece I think we're still really struggling with is how do we take that information in real time and present it to the government in a way that's digestible and understandable?

(10:43):

How do you get a point where an AO can actually see the risk in real time, see how it's changing the application, and more importantly, look across the portfolio to see what's at risk of emerging incidents. And I brought the Log4j thing a minute ago when I was a CISO for a P firm. The only way we could check that is we had to call up and go through each of our individual companies and talk to our CTOs and CISOs and determine who is at risk. If an AO had that thing happen today, how would he or she do that? Call all the mission owners. Mission owners probably don't understand the cyber side. Dig through eMASS and then download the documents and then do a control F to see if it's in there. Pull the SBOMs. I mean, it would be a royally huge and painful process. S what we really need to get to is find a point where that continuous Monterey, I talked about for FedRAMP, and these pieces like that are actually no longer point in time, but they're generated automatically. They show and they live in real time.

(11:39):

So how do we make the solution real? I hope I'm not triggering anyone with an eMASS snapshot up there, but eMASS is the program of record, right? It's incredibly manual. It's incredibly painful. Some organizations live and die by it. Some organizations don't like to use it or try not to use it either way. We've got to find a way to make it a little more modern. So a couple examples I throw out here just of places where we're starting to advance the ball. Rise8, our host here has Tracer, which is able to go in and when you're designing application, you can pull out the dependencies you want and it can track that inheritance and map the inheritance of those controls. So instead of having to manually go through everything, you have a way to do it. Okay? You can do these things on spreadsheets, excel tiers and whiskey, but why not use a modern application to do that? Second front is trying to build out a tool called Watchtower, which allows an authorization monitoring board. So when you talk about deployed applications that AO can look in there in live real time, see users, see where applications are deployed at double down on those applications, look at the information that eMASS gives you, but see it in real time. See that compliance and see that security in real time.

(12:47):

So I mentioned earlier what it would need to include. What benefits does it bring? I would argue if we can get to this stage, we get to a point where we can streamline this ATO process. It's no longer a 6, 10, 18 month process, but if you can see this stuff in real time, it makes it much easier to basically click through, understand the controls, and understand that software architecture you're trying to risk bound for the government. Ideally, we want to maximize reciprocity with that. If I have that system in place, and any AO can log in and look at it, instead of having to get read access to eMASS and have someone dod safe your artifacts over to you, it makes reciprocity something that could actually be believable. It'll give enhanced security. Again, the biggest thing is that continuous monitoring aspect. You may have the monitoring alerting tools on your infrastructure, but how do you show that to the government when they need to see it?

(13:38):

How do you get them the data they need that ties to that risk assessment. And then how do you adapt to changing requirements and changing missions, getting to that point where you can do real time continuous compliance? Because what this really does is it becomes a way to foster communication among stakeholders. As I said, this isn't the aos fault. It's not the Scott's fault. It's not your fault as the application owner, but it requires your teams, the mission owners we're fighters in the use case, the A and SCS all working together. And to do that, we all have to look at the problem in the same way, from the same angle, or at least be looking at the same thing, and we're just not right now. So I mentioned the R word of reciprocity. So I guess my question is, does it really exist? We talk a lot about it, but does it actually exist really in the government?

(14:27):

And I would say probably not, right? I mean, I think that's probably closer to what reciprocity looks like. When someone wants 'em to see my application, how do I create all of that data over to them and let them steal all those artifacts and thumb through the pages and determine whether or not it's okay for them? The DOD defines that risk as reciprocity as an agreement upon among participating organizations to accept each other's security assessments, reuse system resources, and or accept each other's assess security posture to share information. And that I would agree is ideal, right? But the problem is, is that an ATO is not an ATO, which is not an ATO. It doesn't matter if someone from the government has risk accepted. It doesn't matter if you've got a DSPA, the individual AO who's being held accountable for risks in his little enclave or system. They have to make that decision. They have to determine whether or not they're going to let it run. So you might have an ATO, but it's not an American Express card. It's not accepted everywhere. So if it doesn't exist yet, how do we get there? And I think that's one of the key things we're bringing in. How do we get this information in real time in a way that we can see and accept it and understand that?

(15:41):

So there's some progress that has been made, if you haven't looked at it yet, the National Defense Authorization Act of 2025 that just was signed does have some pretty interesting things in there. So I'd encourage you to look it up and look specifically at section 1522. And what that requires, the DOD to do is to publish and manage an active director of aos. Because right now, if you try to find out who are the AOs in the government, it's impossible to find out. It's a name game. It's who knows who and are the relationships, and how do you find that out? If you have that list of aos and you know what their portfolios are, and then you have systems of training to make sure they're looking at risk in a similar or comparative way across the government, so you don't walk into one and provide, get one ATO, then walking the other and get a completely different range of questions.

(16:30):

But once you take that, the next step is a second clause in that NDAA, which I think is really important. We'll see how live it becomes over the next year or two, but is the presumption of reciprocity. It's saying, if you have these specific software accreditation standards, that duty is going to go by. There should be reciprocity across the DOD something that would make the reciprocity playbook that came about last year real, and this is good, but no one's necessarily abiding by it, right? The good thing is, is it pulls out the key artifacts from the CNSSI-1254 and says, Hey, this is what you need for reciprocity. So if we can take those kind of key documents, your SSP, your sar, your rar, your poam, and have that an automated system that any AO could look at and manage and click through in real time, now we're going to the point where we can actually reduce a raise comfort level over that potential risk.

(17:25):

So here we are again, I couldn't sit there and tell you, here's the solution that's going to solve everything, but we really need to think now together as a community, how do we move this forward? Because again, it takes everybody in this room. How do we get to a point where we can build that ATO as a seamless integrated piece of the software development cycle? How do we get it to where we can maintain that rapid innovation, maintain strong security, and then how do we move that forward? I don't have the exact solution. I have ideas of how it should go. It requires all of us to pull together and kind of move forward to help the government to help us, and most importantly, to help the warfighter. Thank you for your time today. Please reach out if you'd like to stay in touch. I'll be at the q and a tables after this at noon if anyone wants to continue the conversation. I don't have a book like most people here, but I'm happy to scribble my speaker notes and a cocktail napkin for you. So good to meet you all and thanks so much.

‍