The Linux Foundation is making available a set of free tools for building software bills of material (SBOMs) based on the software data package exchange (SPDX) file format it curates.
Backed by more than 20 organizations, SPDX is an effort to standardize the way metadata describing the contents of a software package is described.
The SPDX specification was submitted last fall to the International Organization for Standardization (ISO) by the Joint Development Foundation, an arm of the Linux Foundation.
The Linux Foundation, as part of its efforts, is also making available a free, online training course to provide IT teams with the foundational knowledge required to create and maintain SBOMs.
Kate Stewart, vice president of dependable embedded systems for the Linux Foundation, said SBOMs play a critical, often overlooked role in maintaining the security of a software supply chain. One of the major challenges organizations have today is that an SBOM isn’t often created, which makes it harder to discover what software components have been included in a package. That makes it difficult for organizations to determine if they are employing a version of a software component that now has a critical vulnerability that was just recently reported, noted Stewart.
Even when there is a SBOM, its construction can vary from one team or organization to the next. The tools provided by the Linux Foundation are intended to standardize how the fields used to describe a SBOM are defined, added Stewart.
The SBOM tools being advanced by the Linux Foundation are, in part, a response to President Biden’s executive order pertaining to the security of software supply chains, added Stewart. The National Telecommunications and Information Administration (NTIA), as a result, is now asking for wide-ranging feedback to define the minimum requirements for a SBOM.
It may take time before there is an agreed upon SBOM standard, but as microservices based on containers become more prevalent, it’s also apparent the issue will become more pressing. More, smaller packages of software being deployed in the enterprise without manifests will only further exacerbate an application security crisis that has deepened in the wake of recent high-profile software supply chain breaches.
Ultimately, a SBOM should automatically be self-generated as part of any DevOps workflow. The challenge is there is still a massive amount of software being created outside of any formal DevOps workflow. On top of that, the massive amount of poorly documented legacy application software already deployed in an enterprise IT environment makes it clear how big an issue the lack of a simple SBOM really is.
It’s not precisely clear who inside an organization should be responsible for standardizing SBOMs. The challenge is that within many organizations it’s not the kind of issue for which developers are rewarded, much less motivated, to solve. Nevertheless, everything from application security issues to the massive amount of technical debt that stems from duplication of software development projects can all be traced back to the lack of a simple manifest.
Of course, now that many organizations are starting to appreciate just how dependent they are on software, more questions are being asked about how it’s constructed. The thing that many of the business executives asking those questions are about to discover (with some incredulity) is how much of the software the organizations depend on is still being built using methods that have more to do with a medieval craft than they do a manufacturing line.
