The concept of DevSecOps has been around so long that it is now firmly established in most federal agencies as one of the key foundations for producing secure software, and even small agencies increasingly have their own DevSecOps pipelines to achieve that goal.
But getting the results they need will take more than just having that pipeline. It will also take planning – including a lot of “shifting left” from the processes agencies have used in the past.
At the Export-Import Bank, for example, this means that we consider security as a basic requirement for development from the very beginning, together with the infrastructure that will be needed to support the system.
“You can’t build a great application and have it sit on top of an infrastructure that has problems. So from a shift-left perspective, we’re making sure we meet all our requirements at the start of the project,” said Darren Death, head of information security at the Export-Import Bank, during Federal News Network’s Cyber Leaders Exchange 2025.
“Historically, security requirements have always been the things that were negotiable, as if they weren’t required. Well, they are required. They have to be treated as functional requirements. And that’s one of the cultural things that we do here at ExIm: we treat them as functional requirements. And the reality is that if you do them at design time, you can design the functional requirements and security requirements together, and then a lot of those problems (of fear, uncertainty and doubt) disappear because you build them. together. You have a high. A powerful system that is also safe.”
Addressing supply chain risks
That same mentality has taken hold at the Bureau of Safety and Environmental Enforcement, the small part of the Interior Department that oversees the offshore oil and gas industry.
Madhuri Sammidi, deputy chief information officer of BSEE, said the agency has moved to a model that includes ‘security by design’.
“Security starts very early, even before we start implementing a system,” she says. “It really starts at the planning stage, and the planning stage could include anything including software supply chain risk. That’s a huge risk that we’re all dealing with, and some of the incidents that we’ve all seen are caused by supply chain risk. And we have to think ahead. The security staff – the security team and the cybersecurity assessment team – needs to be involved in all of these conversations, where applicable, wherever they can be, so that we don’t have to tighten security later. think about security at every stage of the software development lifecycle, starting with planning.”
And mitigating that supply chain risk also requires early conversations with suppliers, Sammidi said.
“It needs to start publishing their inventory before we even start acquiring their software,” she said. “We as a government rely heavily on third-party vendors and their software and integrators. So it’s really important to have all these expectations and engage with the vendors from the beginning about these aspects of cybersecurity and integrating security into every phase of the software system lifecycle, and getting them on the same page as you with your DevSecOps model. How their software BOM can be integrated and used in your continuous integration, continuous delivery pipelines is very important, and something we can all benefit from.”
Build in certainty during acquisition
And especially in the case of small agencies, the staff carrying out the development work may generally be contract employees themselves.
That means all considerations that go into the DevSecOps planning process must also be factored into the contracting process, Death said.
“If you don’t fulfill your contract properly, you get something, not something safe,” he said. “We’re about to enter 2026, and you would think we would be getting secure stuff by default. But we’re not, which highlights the importance of a responsible manager taking the time to build out those security requirements. You can’t assume that. And ultimately what you ask for is what you pay for. You need to have that integration with your procurement team so that the right person (the CIO, the CISO or someone else) is looking at that contract to make it happen. to make sure these things have been settled and that you’re trying to get something safe.’
To take AI ‘baby steps’
Meanwhile, agencies are also considering how new AI-enabled approaches to secure code development can help with the task of integrating secure design principles early in the process.
Sammidi said BSEE is still taking “baby steps” toward using AI as an enabler in software security, but there are promising signs.
“Right now there are so many manual processes around things like code repository evaluation and vulnerability scanning and reporting, and the dashboards we see are not always live data,” she says. “AI could be an answer to some of these challenges that we’re all facing now because false alarms and false positives are creating a kind of fatigue in the security community. AI could be a big help in reducing some of that fatigue. AI still needs human intervention because there are some challenges around things like data quality reporting, but it could be a great enabler, and we need to start small and with that continue until we automate things using fully AI-driven information. cyber security.”
At ExIm bank, officials are already in the early stages of using AI tools for code analysis, Death said.
“When we do our code reviews as part of the CI/CD pipeline, and software that we suspect is vulnerable is discovered, the tools will actually suggest changes to the software code,” he says. “You are still responsible for your results and the software developer ultimately needs to have the skills to determine if those updates and changes are actually valid, but the tools can speed up time. Previously, when you ran a security scan, it wasn’t the developers who did that. That’s another important thing we do here: we get developers to run the scan. We (in the security community) control the configuration, we understand what it is like configured, but then we give them the option to run the scan. Because there’s nothing special about me pressing the start button against them. They can push it, but then they get the results of the scan, and then the tool can actually give them that information.”
Discover more articles and videos on our now Cyber Leaders Exchange 2025 event page.
Copyright © 2025 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.
