When you install software are you sure it’s code you can trust? There are so many questions we need to ask: do you know how that application got to you, how it was built and what third-party software is running under the hood?
SEE: Google Workspace vs. Microsoft 365: A side-by-side analysis w/checklist (TechRepublic Premium)
Today’s applications are part of a software supply chain, one that reaches down into the open-source community and up into large-scale continuous integration/continuous development platforms. It’s an issue that’s been put into sharp relief by recent events: the use of a compromised build process to put a back door in the Solar Winds management platform before attacking its customers’ systems and the hijacking of various open-source libraries to, among other attacks, build in cryptominers to steal your power and CPU.
End users had no idea that they were using compromised software. As far as they were concerned this was legitimate code from legitimate sources. It was code that they trusted to be secure. But with no visibility into how that software was built, there was no way to know that that software shouldn’t be trusted. The software we use is built from many different components, using everything from container base images to build scripts.
Understanding the software supply chain to protect it
We know about the supply chains that deliver our material goods, and we take steps to protect them. There are international laws and rules that control how goods flow between factories and across borders, with certifications and customs documents to track how they’re moving and if they meet standards. But we don’t do this for software, we simply install it and use it to run our businesses.
A year ago, the U.S. Government issued an executive order that aimed to get the industry to work to protect the software supply chain, requiring a Software Bill of Materials (SBOM) for all applications provided to the U.S. federal government. It’s a comprehensive order, intended to deliver guidelines on how to improve and secure the software supply chain. The intent is to put in place processes that put software engineering on the same footing as other engineering disciplines.
Microsoft has been using software manifests internally for a long time, allowing it to keep track of the various components and modules used to build its software. That work led to it leading the Consortium for Information and Software Quality’s Tool-to-Tool SBOM working group to build a cross-industry standard for sharing this information with customers and partners. While work was quite far advanced, it wasn’t the only SBOM platform under development.
As a result of the U.S. government order, Microsoft and the rest of the consortium are merging their work with the Linux Foundation’s similar project. This is part of the ISO standard for open-source license compliance, which has been designed to share all the licenses bundled with an application with end users. Attaching license information to a SBOM makes a lot of sense, as it allows you to see what license applies to what component using a machine-readable manifest built using the Software Package Data Exchange (SPDX).
Working with SPDX to build a SBOM
While SPDX isn’t quite the tool envisaged by the U.S. government’s National Telecommunications and Information Administration, it’s very close to it and can be used to handle most of the initial requirements and should be easily adapted to meet the rest. Beyond that, it’s the most common SBOM tool in use and can be easily built into most software development environments, with a suite of applicable open-source tools. License compliance may have driven the development of SPDX, but as it requires understanding what software you’re using and where it’s from it needs to be easily extensible to adding other verifications, such as digital signatures and hashes, allowing you to build a SBOM that covers binaries and other software artefacts as well as source code.
SEE: Hiring kit: Back-end Developer (TechRepublic Premium)
Microsoft has been moving its internal manifest tooling from its own formats to SPDX to comply with the NTIA requirements and the executive order. The result is tooling that generates a JSON SBOM file for each build. It’s not doing this only for government customers, it’s doing it for all its software. At the heart of its SPDX implementation is a mapping of the key NTIA SOM fields to SPDX, so for example, where the NTIA asks for a component name, the Microsoft SPDX implementation uses the SPDX package name field. It also means making fields like supplier name, package version, package checksum, and relationship mandatory where SPDX treats them as optional, allowing Microsoft to deliver as detailed a SBOM as possible.
Implementing this is a big job for Microsoft. It produces around a half-million builds a day, across Windows, Mac, Linux, Android, iOS and more. So, producing a SBOM needs to be automatic, for all official builds (test and development builds that don’t leave the development lab won’t need a SBOM). It needs to be part of any CI/CD build pipelines, delivering the SBOM alongside the rest of the build artefacts.
The result is a cross-platform tool that not only identifies commercial software components, it also detects and identifies open-source components from most common software repositories, like its own NuGet or the popular JavaScript NPM repository, and even works with languages like Go and Rust, as well as applications that have their own Git repositories.
The resulting SBOM has both SHA256 and SHA1 hashes for code, going above and beyond the NTIA specification, and the resulting files have their own digital signatures for additional security. It even tracks the build system used, with a signature that encodes the build run. Finally, the output of a build is checked against the SBOM, and if there are any discrepancies the resulting software won’t be released–preventing compromised code from running in services like Azure.
Building your own SBOMs for more than secure software
There’s a lot of value in understanding the software supply chain, and it’s not purely a security issue–it can resolve issues in building and maintaining business relationships. Having a public SBOM for something ubiquitous like Word is going to help improve relationships between suppliers and their customers. Asking for proof of origin for software will soon be part of all contract negotiations, helping companies manage risk more effectively. With an SBOM installed alongside your software you’ll be able to pass it on along with the rest of the necessary documentation.
You should be able to generate your own SBOM for your own custom software, using the same tooling as Microsoft in Visual Studio. Microsoft has said it’s going to open source its SPDX tooling, which will allow you to use it in any CI/CD tool and in any IDE. The same tool that’s in Visual Studio for .NET will be in Android Studio for Android, or in XCode for iOS. That’s a big win for the entire industry, as organizations extend the SPDX platform and give us a cross-platform, industry-standard way of understanding the increasingly complex world of the software supply chain.