The Risks of Decomposing Software Components
Software components decompose. They are not like gold bricks in a safe. They are more like lettuce in a warehouse. They have to be used and replaced. It’s not apples to apples, per se, but the point is that components require updating.
If the software is not updated, problems arise, and we face security vulnerabilities like Log4J.
But getting components updated in a timely way is a universal problem and a challenge getting tackled by the Linux Foundation’s Open Source Security Foundation (OpenSSF) said Omkhar Arasaratnam, general manager of the OpenSSF, and Brian Behlendorf, CTO, OpenSSF in an interview at The Open Source Summit North America in Vancouver, BC.
With a component fix, how do you get from upstream to downstream as quickly and efficiently as possible? People still use old versions, as illustrated with Log4J, where people are still relying on outdated and vulnerable software components.
“It’s a very classical case of a security issue, it’s not something novel,” Arasaratnam said. “I’d like to ensure that we start by making our software secure by construction so the issues like that don’t exist at all: through education, through using different techniques, hardened libraries, well-vetted patterns for addressing those kinds of issues. Now, when issues like that do occur, then you’re right, we do have to jump into rapid response mode. We have to have not only, as you pointed out, a good mechanism of traversing stuff from upstream all the way back down to what’s running in prod. But that’s where artifacts like SBOMs come in.”
An SBOM is a software bill of materials. The SBOM tells you the software components and, hopefully, even more.
According to the Linux Foundation, an SBOM is a complete, formally structured list of components, libraries, and modules required to build (i.e., compile and link) a given piece of software and the supply chain relationships between them. These components can be open source or proprietary, free or paid, and widely available or restricted access.”
Arasaratnam, who recently joined OpenSFF as general manager, said SBOMs, also noted by Behlendorf, provide telemetry. They provide data that can be reasoned over when making some of these decisions.
“Wouldn’t it be wonderful if we could also provide reputation data on a particular repo you’ve decided to link against? Wouldn’t it be great if you had that full inventory of the time that you use that GCC compiler flag that could have caused some kind of regression? All of this data is extremely valuable. And I think for a long time, we, in enterprise in general and production environments, have been fumbling around with imprecise data, and have been unable to really leverage all the telemetry we could be using.”
The discussion also covers the issues with package managers and how we may quantify the risks of software vulnerabilities.
