Date: On Demand
Duration: 1 hour

A recent survey by the non-profit ATARC found 24% of the almost 300 respondents from 27 agencies say they are using DevOps or DevSecOps for software development.

Another 33% say they are using agile or scrum or the Kanban methodology.

This means 57% of the respondents using a software development methodology that focuses on the customer or end user, that is iterative and that ensures mission areas receive capabilities faster and better, and, maybe most importantly, if there is a problem, it’s addressed earlier in the process.

It’s clear DevSecOps is taking hold across the federal government.

But like any new process, agencies must guard against the wolf in sheep’s clothing challenge–meaning calling your process DevSecOps but really following the waterfall methodology where you define the end result, require all the documentation and funding upfront and deliver capabilities every six months or every year.

This means agencies need to train developers as well as the mission or program owners on the DevSecOps methodology to ensure they don’t fall back into old habits.

Federal DevSecOps leaders say institutionalizing this approach to software development is a journey that must bring together the technology and business sides to change an organization’s culture.

“We have achieved a couple of very important milestones that have defined a lot of the successes that that we have been able to achieve. I think the most important thing that we’ve done is we transitioned the way we plan for a product from project action to product,” said Stephan Mitchev, the director of the Office of Application Engineering and Development and the acting chief technology officer at the U.S. Patent and Trademark Office in the Commerce Department, during the panel discussion Securing Mission Critical Apps sponsored by GitLab. “That transition allows us to form our agile teams, to give the decision power and the prioritization to the hands of the business side, rather than the CIO’s office. It also put our customer in the center to talk really about consumer centric design and work.”

Mitchev added after two years PTO is in a continuous improvement process and is adopting the DevSecOps thinking.

James Scobey, the chief technology officer of the U.S. Securities and Exchange Commission, said part of this journey is accepting there is always a “buy vs. build” decision that must take part during the upfront planning stages.

“We’re going through each application and we’re looking at whether an application would be better met with something like a software-as-a-service or a platform-as-a-service, or is this something that we really need to refactor and rearchitect to move into our environment as a custom application?” he said. “There’s a number of metrics we’ve put against that in terms of delivering value to the business and the ways that application will be maintained. As we go through those, that decision making, looking at security, the option to maintain it as is or operate it in an infrastructure-as-a-service environment, and then do we have the right teams and the right skill sets to be able to refactor this application and maintain it in real time.”

Scobey added the SEC is reskilling and retraining employees to help run these DevSecOps projects.

David Vergano, the division chief of the systems development division at the Bureau of Information Resource Management for the State Department, said it’s been almost three years since his organization moved away from waterfall to the agile methodology, and now are transitioning to DevSecOps.

“Our first big pilot this year was for the virtual student federal service application, which is a great program that matches agencies with college students looking to intern and do government work. That took about nine months or so. It was a pilot where for the first time we really were able to dedicate a team 100% onto that effort. In addition, we had a working group that was meeting regularly to evaluate how things were going, how we could do things better,” he said. “That was the first time we really got all of those pieces together to deliver that product. For our other efforts for the last few years, we were doing more DevOps where we have built pipelines, trying to move to automated deployments, cloning, scanning, putting automated testing, so that our folks are spending more time building solutions and less time running through regression tests and doing some of the tedious manual things.”

Vergano said many of the users have embraced DevSecOps and are helping to manage the prioritization of new capabilities.

Bob Stevens, the area vice president for public sector at GitLab, said these three examples are becoming more common across the government, but agencies still can fall into common potholes.

“One of the largest challenges that we see across all of the organizations is there are a lot of processes associated with DevSecOps that bogs things down. That creates timelines that are not advantageous to the developers, the customers and the organization,” Stevens said. “One of the things that I see that is a head scratcher for me is a government agency will outsource the development to maybe a system integrator, and that system integrator will go through the process, but then the customer has to do it all over again. I don’t understand why they can’t accept the security automation or security processes that the integrators put in place and come and achieve the ATO. We’ve got to get better with the process. We’ve got to get better with understanding what it really is. We have automation or everything is continuous now with the exception of security. So how do we get there? I think it’s going to take out a cultural change, similar to what we’ve seen in the transition to DevSecOps over time.”

Learning objectives:

• Current state of DevSecOps
• The application rationalization journey
• ATO challenges and recomendations

This program is sponsored by   

Complimentary Registration
Please register using the form on this page or call (202) 895-5023.