Federal IT shops are hungry for best practices on implementing DevSecOps, a practice and culture that has been around for years but was elevated to the surface as attention on network and access security heightened.
A common refrain among agencies embracing DevSecOps is its potential to enhance cross agency communication but also customer experience and a sense of ownership around the IT security at every stage of a product’s lifecycle.
The Department of Veterans Affairs shifted from a project-centric platform to more of a product focus, said Derrick Curtis from the Office of Information and Technology. As the director for Software Testing and Section 508 in the Enterprise Portfolio Management Division, his team owns and takes care of a product for its entire lifecycle.
“We are really engaged with our customers, understanding our needs, and then building a cohesive team around that product that takes care of it throughout this lifecycle, and – locking in an understanding what the customer really wants out of that product,” Curtis said during a webinar by ATARC on Thursday.
DevSecOps allowed the division to engage more with customers, and concerning IT modernization in the digital space he said it has changed how they look at refreshing equipment or infrastructure for a more agile methodology.
Focusing on product also helped the General Services Administration use methodologies such as human centered design and agile development, according to Crystal Philcox, assistant commissioner for Enterprise Strategy Management in the Federal Acquisition Service. She pointed to the Office of Management and Budget’s Circular No. A-11, Section 280; and the Executive Order on Transforming Federal Customer Experience (CX) and Service Delivery to Rebuild Trust in Government from December.
Philcox said that while human-centered design, CX and DevSecOps are separate they should be done together and should complement one another.
“If you’re doing DevSecOps, and you’re focusing on sort of a continuous build … if you’re not shipping usable code as you go, then it’s not worth doing DevSecOps,” she said. “As you’re moving into this methodology, get a little bit more comfortable with shipping regularly and get the business folks and your partners on the business side to be more comfortable with, ‘Hey, let’s just get out some usable functionality first, let’s do that now,’ and have a little bit more as you go and continue to build on the product.”
She advocated writing contracts to accommodate how a DevSecOps team is working or how an agency expects its contractors to work, i.e. “focusing on a north star that you’re trying to reach.” Then develop milestones around delivering use cases for real users, rather than around delivering documents, she said.
Rayvn Manuel, senior application developer for the National Museum of African American History and Culture, agreed with Philcox and Curtis that DevSecOps needs to work hand in hand with digital transformation. In her view, it also acts as a protective shell over the implementation, if one is considering security, while transitioning from a legacy state to a future state. She said teams must always be aware of the attack vector and looking for bad actors.
Manuel said she initially bristled when she first heard the term but she recognized that it helped highlight security within the whole development and deployment lifecycle.
“And yeah, most people probably actually were doing that. But I know, as a developer, I would do my little bit of security and then, as Derek said, throw it over the wall to somebody who knew better than I did, right? Because I really wasn’t interested in learning more about security than my little Idaho,” she said.
She said the previous, bottom-up governance of security has switched to a top-down approach. In addition, Manuel said she was surprised to see accessibility – something that has long been important for the Smithsonian Institution’s ability to attract visitors – come into play more so, due in large part to executive orders. With respect to CX, Philcox said DevSecOps could help agencies get their deliverables closer to what customers want and what users will adopt, with fewer errors and risks.
Philcox’s organization has had success with Tiger Teams that combine developer and security staff, who sit down before product development starts, and plan how they will work together.
“We also have a lot of, especially for between our dev and our business product owners, we have release planning – three-day release planning sessions, at least quarterly, where they run through all of the use cases that everyone is planning for the next couple of months, and that seems to keep everybody synced up and on the same page, too,” she said.
There are numerous ways to implement DevSecOps but Curtis said it bears remembering that every organization’s situation is unique. He recommended assessing an IT security department’s skill set and growing beyond that, but also do not be afraid to ask for help.
“Don’t suffer in silence. Sort of raise your hand and say, ‘Hey, we had this situation, how did you handle it? Or how do you do this?’ And you’ll find that almost every any scenario has been covered by someone at least once, whether it’s a pass or fail, but there’s always learning,” he said. “And we’re still learning as an organization, quite frankly, as well.”