The conversation around software supply chain security has centered quite a bit on software bills of materials (SBOMs), which is basically like a list of ingredients for all the components that are included in software. But Carol Woody, principal researcher for the Software Engineering Institute at Carnegie Mellon University, said focusing exclusively on SBOMs can run the risk of missing the other half of the problem: How is the software purchaser going to use it, and what risks are inherent in that use?

That’s why Woody’s team recently released an Acquisition Security Framework for software, to help emphasize the relationship between what a supplier included, and how the buyer is using it.

“The ingredients are only going to be one piece of it. It’s really got to be the combination of what’s in the product and then how am I applying it? If you think of it, poison can be very useful under certain circumstances, but you don’t want to put it on the dinner table,” Woody said on Federal Monthly Insights – Software Supply Chain. “So you have to be looking at how I’m using and applying what it is that I’m acquiring. And you have to be educated to do that because software is not something that you can easily measure and manage. You have to know what to do and what to look for. And we’ve not done a good job of educating our workforce on any of the challenges of security and how to address those issues.”

Part of the problem is that software invariably has defects. And while standards around security have been put into place, those standards aren’t always updated and improved upon. And that’s largely because of a culture where everyone is afraid to share information about a data breach or potentially compromised software. Data points are limited because there’s no standards about releasing those details of what occurred and when.

Another challenge is that SBOMs are only a list of ingredients; they don’t tell you how the ingredients were applied or what the end result was. Other pieces of important information to manage supply chain risk are needed to actually apply the SBOM in a way that makes it useful. And that’s a huge volume of information, considering there are thousands of pieces of individual software involved in just operating a phone.

“You have to tie the SBOM back to things like what vulnerabilities do we know about for each one of those pieces of software? How am I using that software in my environment? What’s it connected to, so that I can worry about are there attack vectors that I have to be concerned that can come through linkages that I’ve established?” Woody said on the Federal Drive with Tom Temin. “All of those elements involve different kinds of data, but we’re talking about massive volumes of data. This is not something someone is going to sit and inspect and do a couple of verifications and then check the box and say it’s good to go. We’re going to need more automation to help us actually manage all this data and apply it effectively. And we haven’t started on that yet.”

The other element of this is that, as experts are looking through an SBOM, they don’t necessarily know what they’re looking for unless there’s already a known vulnerability. And by that point, they’re already in reactive mode, and potentially already compromised. But the idea is to be proactive about building better systems.

Because that’s the two sides of the software supply chain problem, Woody said. The first is reacting to known vulnerabilities, and making sure they’re mitigated as quickly as possible. And then the second is how to avoid creating or inviting more problems down the road.

“That’s where we’ve fallen down very badly over the past, because we’re only looking at cost and schedule. We’re not appropriately vetting those vendors to really establish the right kind of relationship and incentivize those vendors to want to give us products that are stable,” Woody said. “We right now are more concerned about how fast we can get something in, how quickly can I get it implemented and make it as cheap as possible. Those criteria are not incentivizing the vendors to put in place the right processes and practices, to remove potential vulnerabilities, to use secure coding so that I’m creating a product that is as robust and effective and reliable as possible.”

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