 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
A software bill of materials (SBOM) tells the consumer what’s inside the software to determine better if there is a security problem. The idea is that the software gets patched without necessarily returning to the vendor.
That’s the view of Justin Hutchings, senior director of product management at GitHub, who spoke with The New Stack Makers podcast about SBOMs and related topics.
But what is inside an SBOM becomes the challenge.
Every software package is different, Hutchings said. An Android application, for example, consists of a developer’s application code. But then there’s a whole bunch of open source that the developer uses, and that’s probably in the form of Maven packages, things that open source developers have made and published.
The application depends upon all of those dependencies. In theory, the software bill of materials serves as a full machine-readable listing of all the application dependencies, so the developer can rely on that and decide its security.
“Here’s what they ought to include if they’re good ones, and candidly, most of them aren’t,” Hutchings said. “What they ought to include is a machine-readable identity for the software that lives inside. So that means identifying the app as well as identifying the software dependencies inside the app.”
In a well-documented SBOM, an Android app will have many Maven dependencies described in a machine-readable way. A developer who sees a version of Log4J can check if it has any known issues.
“But this is sort of the dream world. We’re broadly speaking, not there yet,” Hutchings said. Because most of the SBOMs that are being created aren’t fully machine-readable. And frankly, the vulnerability out there is in an even worse state.”
A lot of things need to happen for SBOMS to meet the standards that Hutchings describes.
“First of all, there are a lot of software languages where actually interrogating what’s inside the build is incredibly difficult,” Hutchings said. “I was picking on Android first because, you know, that’s actually a place where it’s pretty good. But if you’re writing, say, desktop software, and C and C++, if you’re an operating system vendor, for example, there’s not a centralized distribution point for dependencies in C and C++.
“Most developers actually download those dependencies, and check them into their code. There’s not a standard way to go and enumerate those and have strong names and strong versions. And so when you look at a lot of the SBOMs that are out there, they actually don’t have a good way to resolve machine-readable names for those. And this is a problem that we need to deal with across the entire software supply chain.”
Check out the full episode for more.
