Making DevSecOps More Available

In many of its programs and other offices, the Defense Information Systems Agency (DISA) is instituting modern software development through development security operations, known as DevSecOps, and the establishment of software factories, with tools to create software solutions for a range of program offices.

The agency’s latest work is to advance DevSecOps into critical environments, especially for some of the Department of Defense’s (DOD's) highly classified systems—not necessarily an easy task, said Alexander McFarland, Olympus technical lead, Hosting and Compute program, DISA; John Machate, manager, Directorate Information Systems Security, PEO Spectrum, DISA; and Kyle Saunders, software factory engineer, Command and Control (C2), DISA.

The DISA software engineers spoke on a panel today at AFCEA International‘s TechNet Cyber conference, held annually in Baltimore. The panel was moderated by Matthew Palmer, chief engineer, Command and Control Portfolio, PEO Services, DISA.

DISA’s DevSecOps capability began around 2020, starting from the C2 portfolio and the need to modernize a lot of the agency’s C2 software, Saunders explained.

“A lot of the C2 stuff is on the high side, on the SIPRNet [Secret Internet Protocol Router Network] and at the time, there was no DOD-wide software factory on the SIPRNet side,” he noted. “That is where we wanted to get a software factory put together.”

The latest iteration of the software factory is called the Citadel, Saunders explained, and the intent there is to expand secure software production and provide capabilities or artifacts to the greater DISA community.

“In the rebrand, we wanted to back away from just the C2 Portfolio and offer those solutions to all of DISA,” he offered.

The Citadel Software Factory has a full ATO, authority to operate, and is in the highest security environments, Impact Level (IL) 5 and IL 6. The software includes 20-25 tools that are specifically focused on providing source code and other artifacts for programs to use, for continuous monitoring, for example.

The next step, Saunders shared, is for the Citadel Software Factory to become the agency’s enterprise software factory.

“We recently got the nod to be the agency enterprise software factory,” he stated. “And you may have heard of the Vulcan before. It is another DISA software factory under the same portfolio, and we're currently doing a technical assessment to figure out what a consolidation of that might look like in the future.”

As DISA moves forward with its secure software factories, the experts cautioned that DevSecOps is not just about software. It is making sure the right culture and procedures are in place.

“When we talk about a holistic approach for DevSecOps, I think about people, processes and tools across the value stream,” McFarland said. “And we can provide tooling that helps. And the good thing is that tooling influences culture, and it influences processes, and it can provide a nudge in the right direction. So adopting this can be pretty transformative.”

It is also more about creating capabilities, not just specific software tools. Saunders noted a move to the GitLab platform as a source code construction environment and repository that could help with development in a disrupted, degraded, intermittent and low-bandwidth, or DDIL, environment.

“Another recent move for us was that we pivoted a bit away from Jenkins and moved to GitLab,” he noted. “And we’ve been really liking GitLab Runners. There are also some more requirements that are coming in the future, like deploying to a DDIL type of environment, where we think GitLab Runners is going to be able to help us out. Because you can kind of wrap everything inside of a Runner to actually deploy the infrastructure, to compile code. And we still offer Jenkins in the software factory for some of our legacy programs.”

The successes DISA is seeing with DevSecOps do not come without challenges, however.

The Risk Management Framework (RMF)—a process designed to integrate security, privacy and cyber supply chain risk management—is having a negative impact, Machate ventured. There are no DOD standards as to what triggers a change request if source code is changed, for example.

“Everyone knows RMF can be a blocker,” he stated. “The way this is implemented, it certainly slows things down, particularly when it comes to DevSecOps. Because you have to do the change request, you have to do all this paperwork and all these things. There's a lack of standardized processes.”

Staffing is another issue, Machate continued. While DISA is adroit with tools and technical solutions, the agency does not have enough personnel needed for software development. “We have these two tiers of DevSecOps environments, but we don't have any staff to run them,” he acknowledged. “So the PMs [project managers] have to go out and buy staff to run them. But DISA has all the tools; they have all the capabilities.”

Palmer noted that the agency had Carnegie Mellon University prepare a study of the state of DevSecOps, which confirmed, among other things, that DISA’s issues are not on the capabilities side.

“The number one thing the study found was that none of the problems were technical problems,” Palmer said. “It was really a culture thing. And specifically, there’s a culture of hierarchical control. If you are a decision authority or branch chief, you feel like it is your job to be the filter for every release, for every software program under you that goes through.”

Instead, to be more effective, the agency needs to get to a culture “of hierarchical control of approved processes” versus control of every software release. In addition, one of the most successful DevSecOps examples, Palmer said, was for U.S. Strategic Command, and it was built 100% through the DevSecOps pipeline for forward-deployed warriors. The command dictated that it come through the DevSecOps process and specified not only the requirements but also how they wanted to receive it. “And the money was tied to that [DevSecOps],” he noted.

Additionally, the Department of the Navy’s Rapid Assess and Incorporate Software Engineering platform, known as RAISE, offers promise to DISA. The agency is looking at what it will take to be certified under RAISE, as the first non-naval organization to do so, Palmer shared.

The latest version, RAISE 2.0, which was rolled out to the Navy and Marine Corps in 2022, outlines the tools, services, people and culture required to successfully implement tailored cybersecurity processes and DevSecOps.

The Navy and DISA already have a lot of shared products, and this may make a good foundation for more, including DISA’s software factory. Already, DISA’s Command and Control Portfolio under PEO Services runs the Global Command and Control System-Joint, or GCCS-J program, and the Navy extends that into GCCS Maritime to run on ships, Palmer said.

It may be a business case for the Navy to do a RAISE 2.0 accreditation of DISA’s software factory, saving them process steps. “I did talk to one of the reps today, from the action level, and they were very excited [about the possibility],” Palmer shared.

TechNet Cyber is organized by AFCEA International. SIGNAL Media is the official media of AFCEA International.