It sounds like the beginning of a bad joke: who is lazier, software or security engineers?
While there’s no punch line, the fact is that developers and engineers alike are finding ways to do less work. But don’t call them lazy. Maybe efficient is a better word.
For the Army Software Factory, the Social Security Administration, and U.S. Citizenship and Immigration Services, that efficiency means reducing the time it takes to bring new capabilities into production.
“I don’t know if I would consider the developers lazy, or the security engineers I might consider lazy in that sense. But personally, I don’t want to go through code review line by line. I prefer to look at an automated dashboard through a process and then check my automation,” said Angel Phaneuf, chief information security officer for the Army Software Factory, during the Federal News Network meeting. Cyber Leaders Exchange 2024.
“I’d rather go back and make sure my pipelines are working the way the pipelines are supposed to work, and I get those kinds of results,” she added.
Shane Barney, CISO for USCIS at the Department of Homeland Security, couldn’t agree more. When it comes to software security, letting the machine do the heavy lifting is the only way to do it, he says.
“We’ve pushed a lot of our security (what we call traditional security) to our development teams and let them do those kinds of things, whether it’s static code analysis or dynamic code analysis. That’s not something my security organization really does much anymore,” Barney said. “We then build in the break releases if necessary in places that make sense. My focus remains on runtime and analytics. I want to know what the systems actually do and what they should do.”
No supervision from the heavy-handed development team
In many ways, USCIS software developers are better able to make their jobs easier by automating vulnerability scanning and patch application.
Barney said his security team has discovered that software developers are good at analyzing and securing code.
“They actually preferred to do it because they realized that if they built it into their overall processes, it would make their jobs easier. They can even predict when releases will be ready,” he said. “They actually feel like they have more control, rather than having a heavy-handed oversight organization come in and say, ‘Oh no, you can’t release because you didn’t do this.’ It really puts them more in the driver’s seat and puts me where I want to be.”
Meanwhile, developers at the Social Security Administration are using a concept called code batching to make their security processes more efficient.
Tim Amerson, SSA’s deputy CISO, said code batching is a twice-yearly exercise to ensure developers have the best skills to write secure code and ensure it stays 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 encryption. So when you think about those Top 10 results, it’s really all based on laziness in coding,” Amerson said. “It’s not really about where the laziness is. It’s really about focusing on where we get the most bang for our buck and where the adversaries are going to exploit these assets – and defend and protect them as best we can. So if we can develop these best practices from scratch, we’ll all be lazy. Because if we want to become more efficient, 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 releases new capabilities every day. The security teams and developers work side by side to drive that efficiency in every release of secure code.
Shared responsibility to secure code
None of the three agencies, nor any public or private sector organization, rely solely on homegrown software. As agencies increasingly adopt software as a service and deploy more commercial applications, security experts say they need to make sure the software they use is secure.
One way to do this is by applying software bills of materials (SBOMs) or similar certificates.
The Army said it will have new rules in place by February to begin including SBOMs in most new contracts involving software. Phaneuf said the software factory is already using them.
“We also create SBOM-like artifacts to track which packages are used in our digital real estate and whether they correlate with the packages being released, the vulnerabilities for quick identification and remediation,” 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 that organizations have a process in place to get these in quickly. Otherwise, your developer will just copy and paste, and it won’t show up in your SBOM. You need to implement a SBOM solution. We have a pretty robust one, and we can use it.”
Improving the security of the government’s software supply chain is a key part of President Joe Biden’s May 2021 cybersecurity executive order. The Federal Acquisition Regulatory Council is also working on a long-awaited software security rule. Once completed, it will require government software vendors to meet specific requirements for secure software development.
Early this year, the Cybersecurity and Infrastructure Security Agency released the Secure Software Development Framework (SSDF) attestation form, which requires business leaders to sign off and confirm that the company is following requirements based on the National Institute of Standards and Technology SSDF.
Ensuring that the code remains consistently secure
Additionally, CISA says 220 companies have signed the Secure by Design Pledge to make good faith efforts to achieve the seven goals of what it means to develop secure software.
SSA’s Amerson said the key to SBOMs, or any attestation effort, is supplier transparency. He said another important aspect of this effort is that the process must be automated so that an agency can continually validate it. The process cannot rely on a paper document that is outdated as soon as it is printed, Amerson said.
“I’m starting to see this as a CBOM, one code bill of materials, because software vendors often outsource parts of the code. So is there a way that you can base that understanding of that SBOM on where you see an anomaly in the code snippet, so that you can actually get a better understanding of if there’s a problem there as well?” he said. “I’m also starting to look at it from a CBOM perspective, where I’m not just looking at the software, but also at the code. Is it consistent throughout the life of the application?”
Using tools like SBOMs and CBOMs is one step, but USCIS’s Barney said they may not work well for the big cloud providers like Amazon Web Services, Google, Microsoft and others.
“What I worry a lot about is the risk from third parties. Whether you’re talking about Cisco products, or a networking application, or an application used to take photos. They are not directly related to your coding or directly related to your applications, but they are used within your environment,” Barney said.
“We just saw that with CrowdStrike. I’m not sure a SBOM would have solved that. That’s a whole different problem. But my point is that these applications are running and vulnerabilities could potentially occur. We would have absolutely no insight into it because we have implemented an application (from a supplier). We don’t code for them or use their code at any level. Where does the SBOM fit in that domain? I think that’s actually a bigger concern for me.”
Discover more articles and videos now at Cyber Leaders Exchange 2024 event page from Federal News Network.
Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.