We first heard about the term SBOM, or software bill of materials, back in May of 2021 when President Joe Biden issued an executive order that will, eventually, require software vendors working with the federal government to deliver an SBOM along with all of their software products. Since then, the Department of Commerce has helped to define what would need to be included within an SBOM. And agencies, which were given a wide amount of freedom to decide when and how to begin requiring them, have started to research how they would work.
The idea behind an SBOM is an interesting one, but over the past two years since the executive order mandated them, no agency has begun requiring them in any major way. Many vendors are cool to the idea, and there also seems to be a lack of understanding about why they are needed, how to create them and what an SBOM could really do to secure the software supply chain.
The somewhat confusing factors surrounding SBOMs made for a perfect backdrop for a video webinar I was recently asked to moderate on this topic. The webinar was hosted by FedInsider and featured some of the top experts in this field working in industry and government, including those who are actively defining SBOM standards or trying to implement them at their agencies. I learned a lot during my time with those experts and wanted to share some of that knowledge to try and dispel much of the ongoing confusion about what could eventually become a very useful tool government could use to protect its software supply chain.
Why are SBOMs needed today?
Bob Martin, the senior principal software and supply chain assurance engineer with MITRE, has been studying this issue for decades. According to Martin, the nature of creating software has changed over the past two decades to the point where something like an SBOM is needed in order for an agency to know what it is really getting when it acquires new software.
“In the past, we have this image of someone sitting down with a literal blank sheet of paper and writing a program from scratch,” he said. But today, “No one writes the majority of the code. They use other people’s components and frameworks, and they assemble them together to do most of the work that an application needs to do, adding in the specifics of what they are trying to accomplish. Today that is the norm because each of us who make modules are doing basically the same thing.”
So, according to Martin, if an agency obtained a module or a program from a vendor in the past, then it could be fairly confident that a single programmer or a small team wrote all of the code that made it up. But today, lead programmers may borrow code from any number of libraries, frameworks and code repositories—because there is no need to reinvent the wheel every time a module is created. Instead, most basic software functions are created from reused, previous code, with only the final bit of unique functionality added by a programmer.
Problems can then happen if a vulnerability is later discovered in some of those libraries or frameworks that make up a component of the millions of programs and modules being used by government. Without SBOMs for active programs, agencies have no quick way of knowing if they are affected by newly discovered vulnerabilities, because they don’t know what went into the code and software that they are using.
What is an SBOM?
Although papers have been written about proper SBOM components, there is still a lot of confusion about what they really are. To help with this, Sam Kinch, the director of technical account management with Tanium Federal came up with a clever way to think about them.
“I like to think of SBOMs like an ingredients list on the side of a food package,” Kinch said during the webinar. “With most packaged foods, you will get a list of ingredients that the company used to create that food, and in the same way you can think of SBOMs as an ingredients list on the side—or as part of—a software package that you receive. It provides you with details about what the components are that the developer used to create a software package.”
Thinking of an SBOM like the ingredients list for packaged food is a great way to help visualize the concept, but Kinch notes that there is one important difference. Unlike a package of macaroni and cheese, which remains the same until someone boils and eats it, an SBOM for software can change over time, even after the software has been delivered to an agency.
“If you perform an update or a patch on software, then that can change the SBOM because new elements could be added,” Kinch said. In the same way, an SBOM could also change based on what platform a piece of software is installed on or how it is used. Because of this, agencies don’t just need to require SBOMs from software vendors, but also need to keep them active and updated as that software gets used throughout an agency.
How can SBOMs be used in government?
Once SBOMs are established, federal guests talked about three scenarios where their use would be extremely helpful. First off, they would be good to have during a crisis, such as when the Log4j vulnerability was uncovered.
“Instead of having to do all that ‘boots on the ground’ work when the next Log4j happens, you could instead have a database or provenance repository of SBOMs to turn to,” said Supply Chain Lead with the Department of Education Jason Mullins. “I could simply search that and see where I’m affected, where did my bad ingredients come from and where did they end up, and where this bit of software is connected to my systems. Then I can start acting on that right way.”
Pat Sullivan, senior advisor to the director of supply chain management with Army Materiel Command, added that not only will SBOMs help during a crisis, but also for the day-to-day monitoring of networks as a key component to cybersecurity.
“It’s a valuable tool to help not only at the point of crisis but also as we work every day to detect and deny identified malicious intent,” Sullivan said. “It’s interesting that we are having this discussion now because, as recently as October, our deputy secretary for acquisitions shared that the Army is going headfirst into SBOMs, so while composition analysis has been going on for years, it’s time now to take the next step.”
Having SBOMs might even bring more security to the software acquisition process, something that is growing increasingly complicated for many agencies.
“SBOMs are definitely something that can help you in the acquisition process to make sure that the software you are getting is not different from the one proposed or demonstrated to you,” said Justin Murphy, a vulnerability disclosure analyst with the Cybersecurity and Infrastructure Security Agency. “If you have SBOMs for everything on every device in your enterprise, then you are going to have a much finer grain detail than we do today.”
John Breeden II is an award-winning journalist and reviewer with over 20 years of experience covering technology. He is the CEO of the Tech Writers Bureau, a group that creates technological thought leadership content for organizations of all sizes. Twitter: @LabGuys
source: NextGov
