It sounds like the beginning of a bad joke: Who is lazier, software or security engineers?

While there isn’t a punchline, the fact is both developers and engineers are finding ways to do less work. But don’t call them lazy. Maybe, efficient is a better word.

For the Army Software Factory, Social Security Administration and U.S. Citizenship and Immigration Services that efficiency equates to cutting down the time it takes to move new capabilities into production.

“I don’t know if it’s the developers that I would consider lazy or the security engineers that I would consider maybe lazy in that sense. But I personally don’t want to go through line by line of code review. I would rather just look at an automated dashboard through a process and then audit my automation,” said Angel Phaneuf, chief information security officer for the Army Software Factory, during Federal News Network’s Cyber Leaders Exchange 2024.

“I’d rather go back and make sure that my pipelines are working the way the pipelines should be working, and I’m getting those kind of results,” she added.

Shane Barney, CISO for USCIS in the Homeland Security Department, couldn’t agree more. When it comes to software security, letting the machine do a lot of the heavy lifting is the only way to go, he said.

“We have really driven a lot of our security — what we call traditional security — off onto our development teams and have them do that kind of stuff, whether it’s static code analysis or dynamic code analysis. That’s not something my security organization really does much anymore,” Barney said. “Then, we build in the break releases as necessary in places that make sense. My focus remains on runtime and analytics. I want to know what the systems are actually doing versus what they’re supposed to be doing.”

No heavy-handed dev team oversight

In many ways, USCIS software developers are in better shape to make their jobs easier by automating vulnerability scans and the application of patches.

Barney said his security team found that software developers are good at analyzing and securing code.

“In fact, they’d rather do it because they realized that if they build it into their overall processes, then it makes their jobs easier. They can actually predict when releases are going to get done,” he said. “They actually feel like they’re more in control, as opposed to sort of having this heavy-handed oversight organization coming in and saying, ‘Oh no, you can’t release because you didn’t do this.’ Really, it’s placing them more in the driver’s seat and putting me where I want to be.”

Meanwhile, at the Social Security Administration, developers are using a concept called code batching to bring more efficiency to their security processes.

Tim Amerson, SSA’s deputy CISO, said code batching is an exercise run twice a year to ensure developers have the best skill sets to write secure code and ensure it remains that way.

“It’s a training model that walks them through best practices,” he said. “The Open Worldwide Application Security Project, OWASP, Top 10 results [detail] vulnerabilities in coding. So if you think about those Top 10 results, it’s all really based off of laziness in coding,” Amerson said. “It’s not really about where the laziness sits. It’s really about focusing on where we get the biggest bang for our buck and where the adversaries are going to leverage those items — and defending and protecting those as best as possible. So, if we can build those best practices from the get-go, we’re all becoming lazy. Because if we’re to become more efficient, then that’s all we really care about: the efficiency of securing our agencies and our citizens data.”

Like USCIS and the Army Software Factory, SSA is releasing new capabilities every day. Its security teams and developers work side by side to drive that efficiency into each secure code release.

Shared responsibility to secure code

None of the three agencies, nor any public or private sector organization for that matter, solely relies only on home-grown software. As agencies adopt more software as a service and implement more commercial applications, security experts say they have to ensure any software they are using is secure.

One way to do that is through the application of software bills of materials (SBOMs) or similar attestations.

The Army said by February it will have new rules in place to begin incorporating SBOMs into most new contracts that involve software. Phaneuf said the software factory already uses them.

“We also do SBOM-like artifacts to track which packages are being used across our digital real estate and that those correlate to those being released, the vulnerabilities for fast identification and fixes,” she said.

“You can’t fix what you don’t know you have. When we talk about open source and when we talk about third-party dependencies, it’s so important for organizations to have a process to be able to bring those in quickly. Otherwise your developer is just going to copy and paste, and it’s not going to show up in your SBOM. You have to implement an SBOM solution. We have a pretty robust one, and we’re able to use it.”

Improving the security of the government’s software supply chain is a key component of President Joe Biden’s May 2021 cybersecurity executive order. The Federal Acquisition Regulatory Council also is working on a highly anticipated software security rule. Once finalized, it will require government software vendors to comply with specific secure software development requirements.

Early this year,  the Cybersecurity and Infrastructure Security Agency released the Secure Software Development Framework (SSDF) attestation form that requires company executives to sign off certifying that the company is following the requirements based on the National Institute of Standards and Technology SSDF.

Making sure code remains consistently secure

Additionally, CISA says 220 companies have signed its Secure by Design Pledge to make a good faith effort to meet the seven goals of what it means to develop secure software.

SSA’s Amerson said the key to SBOMs, or any attestation effort, is vendor transparency. He said another important aspect of this effort is that the process must be automated so an agency can continuously validate it. The process cannot rely on a paper document that’s out-of-date as soon as it’s printed Amerson said.

“I’m starting to look at this as a CBOM, a code bill of material, because a lot of times what happens is software vendors will source out parts of the code. So is there a way that you can baseline that understanding of that SBOM to where you see an anomaly in the code snippet so you can actually get a better understanding if there’s an issue there as well?” he said. “I’m starting to look at it from a CBOM as well, not just stopping at the software, but actually at the code. Is it consistent throughout the life of the application?”

The use of tools like SBOMs and CBOMs is one step, but USCIS’ Barney said they may not work well for the big cloud providers like Amazon Web Services, Google, Microsoft and others.

“Where I get a lot of concerns is from third-party risk. Whether you’re talking Cisco products or you’re talking about a networking application or you’re talking some application that’s used to do photos. They’re not related directly to your coding or directly related to your applications, but they’re used within your environment,” Barney said.

“We just saw that with CrowdStrike. I’m not sure an SBOM would have solved that. That’s sort of a different problem altogether. But my point is that we have these applications that are running, and they may have vulnerabilities that crop up. We would have absolutely zero insight into them because we’ve deployed [a vendor’s] application. We’re not coding for them or utilizing their code at any level. Where does the SBOM fit into that realm? I think that’s actually a bigger concern for me.”

Discover more articles and videos now on Federal News Network’s Cyber Leaders Exchange 2024 event page.

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