Insight by GitLab

Automation, guidance, SBOMs and DevSecOps drive changes in how agencies manage cyber

Find out how automation, SBOMs and DevSecOps are combining to improve federal cyber operations. We get the details from GitLab’s public sector CTO.

Shape

Spotlighting Security and Other Trends in Civilian Agencies

I’ve seen automated red teams used as a proactive approach to application security. ‘Let’s secure this thing before it goes out the door. Let’s hit it hard. Let’s make sure it’s got our best foot forward before it goes into production.’

Federal agencies will have about $11 billion to spend on cybersecurity in fiscal 2023. But will they spend that money by applying a risk management approach that recognizes priorities and helps deliver the most effective outcomes?

That’s the crucial question, said Joel Krooswyk, public sector chief technology officer at GitLab.

“There’s a lot of buzzwords I could throw out here,” Krooswyk said, “from zero trust architectures to broad security scanning and fuzz testing. There’s just terminology galore.”

“But,” he added, “I think the question is, are people really putting security in a prioritized place? That’s the first question.”

Automation provides a way of getting more results out of the government’s cyber spend, Krooswyk said. In particular, agencies should consider automated “red teams” that actively look for vulnerabilities throughout the software lifecycle. The idea is to positively “secure this thing before it goes out the door. Let’s hit it hard. Let’s make sure it’s got our best foot forward before it goes into production,” he said.

The value of automation in cyber monitoring

The use of these automated monitoring technologies during the development stage shifts cyber assurance left, in current parlance — earlier in the development cycle than when cyber checking has typically taken place.

“But security almost needs to be shifted everywhere,” Krooswyk said. “It needs to be the top thought in every stage of the development lifecycle,” including continuous monitoring once software deploys. Automation of cyber testing throughout the software lifecycle, he said, is especially important as agencies develop and field the next generation of citizen-facing digital services.

In the year since the executive order on improving cybersecurity came out, Krooswyk said he’s seen agencies “dial in” to core cyber principles, including the importance of zero trust architectures, lifecycle scanning and paying attention to the sources of open source software. In fact, all elements of the IT supply chain have gained importance in the eyes of agency IT practitioners.

“We’re seeing that the reporting, the attestation, the signatures — plus the digitizing, authentication and authorization of things that we’re building — certify that what we built with our supply chain is what we were supposed to build,” Krooswyk said.

Cyber guidance provide guardrails, keeping agencies on task

Also critical to a modernized cybersecurity regime is refreshed guidance on secure development practices coming from the National Institute of Standards and Technology. NIST guidance helps agencies move beyond static security testing and limited dynamic testing.

“We’re moving into, what does it look like when the application runs? Who can try to get at it then? Is it secure when it’s active?” Krooswyk said. There’s information on “fuzz testing” – seeing what happens to an application when fields are overloaded with garbage and whether it stays secure.

The guidance is broadening the scope of cyber, he said. “I think that’s one of the biggest impacts of that document.”

Meanwhile, the cyber EO has driven the development and use of software bills of material (SBOMs) as a way for agencies to ensure the provenance and safety of software they acquire. SBOMs help agencies gain an understanding of what’s in off-the-shelf software, Krooswyk said.

SBOMs inform by shedding light on software nitty-gritty

Krooswyk made the analogy that SBOMs are akin to food ingredient labels. “It’s like buying your spaghetti sauce and looking at that label.” An SBOM can reveal potential vulnerabilities, which Krooswyk called “inclusions,” that an agency should be aware.

It can also help the IT staff understand the depths of open source components used in agency- or custom-developed software.

“For all the software we’re producing,” he said, “80% of code today has some sort of open source feel or some open source inclusion. We’ve got to know what that is.” The SBOM can show the makeup of open source components and the security vulnerabilities associated with them, he said. Krooswyk advised agencies to explore the range of tools available to generate their own software bills of material.

“That is step one, in my opinion,” he said. “Step two, of course, is making sure that everything there has its vulnerabilities remediated, and that’s the hard part – being able to interpret all that data and then figure out how to make it ready for everyone to use. That’s our real challenge with SBOMs.”

On the other hand, he said, by using SBOMs to create reliable, cyber-proven code and re-using it for common functions across multiple applications or systems, agencies can save a lot of time and cost.

Adding speed, agility through DevSecOps

What’s more, the development, security and operations (DevSecOps) model of software has undergirded agencies’ work toward digital transformation. And it’s starting to pay off, Krooswyk said. Agencies that have adopted the software factory approach, cloud strategies, and “those who set up for scalability” now have the capacity to develop and launch secure, digital services quickly and at scale, he said

He cited the example of when the government determined that the Postal Service would deliver COVID-19 test kits to any household that wanted them. Basically, the ask was, “Hey, post office, can you quickly whip up a site? And they did,” Krooswyk said. “Those are the kinds of things afforded to us by the digital transformations that have gone well.”

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.