When you install software, are you sure it’s the code you can trust? There are so many questions 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 versus Microsoft 365: a side-by-side analysis with checklist (Tech Republic Premium)
Today’s applications are part of a software supply chain, a chain that extends to the open source community and to large-scale continuous integration/continuous development platforms. It’s a problem sharply solved by recent events: using a compromised build process to open a back door in the solar winds management platform before attacking its clients’ systems and hijacking various open source libraries to build in cryptominers among other attacks to steal your power and CPU.
End users had no idea they were using compromised software. As far as they were concerned, this was legitimate code from legitimate sources. It was code they trusted to be safe. But without an understanding of how that software was built, there was no way of knowing that that software could not be trusted. The software we use is made up of many different components, using everything from container base images to scripts.
Understanding the software supply chain to protect it
We know the supply chains that supply our material goods, and we take steps to protect them. There are international laws and regulations governing how goods flow between factories and across borders, with certifications and customs documents to keep track of how they move and meet standards. But we don’t do this for software, we just install it and use it to run our businesses.
A year ago, the US government has issued an executive order which aimed to put industry to work protecting the software supply chain, requiring a Software Bill of Materials (SBOM) for all applications supplied to the US federal government. It is a comprehensive brief, intended to provide guidelines for improving and securing the software supply chain. The intention is to introduce processes that put software engineering on an equal footing with other engineering disciplines.
Microsoft has long used internal software manifests, which allow it to keep track of the various components and modules used to build its software. That work led to it leading the Tool-to-Tool SBOM working group of the Consortium for Information and Software Quality to develop a cross-industry standard for sharing this information with customers and partners. While the work was quite advanced, it was not the only SBOM platform in development.
As a result of the order of the United States government, 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 licensing compliance, which is designed to share all licenses bundled with an application with end users. Adding license information to an SBOM makes a lot of sense as it allows you to see which license applies to which component using a machine-readable manifest built with the Software Package Data Exchange (SPDX).
Working with SPDX to build an SBOM
While SPDX isn’t quite the tool envisioned by the US government’s National Telecommunications and Information Administration, it does come close and can be used to address most initial requirements and should become easy. modified to match the rest. In addition, it is the most widely used SBOM tool and can be easily built into most software development environments, with a range of applicable open source tools. Licensing compliance may have spurred the development of SPDX, but because it requires you to understand what software you are using and where it comes from, it should be easy to extend with other verifications, such as digital signatures and hashes, so you can build an SBOM which includes binary files and other software artifacts as well as source code.
SEE: Hiring Kit: Back-end Developer (Tech Republic Premium)
Microsoft has moved its internal manifest tooling from its proprietary formats to SPDX to comply with NTIA requirements and executive order. The result is tooling that generates a JSON SBOM file for each build. It doesn’t just do this for government customers, it does it for all of its software. The core of the SPDX implementation is a mapping of the main NTIA SUM 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 that fields such as vendor name, package version, package checksum, and relationship should be made mandatory, where SPDX treats them as optional, so that Microsoft can provide the most detailed SBOM possible.
Implementing this is a big job for Microsoft. It produces about half a million builds per day, for Windows, Mac, Linux, Android, iOS and more. So producing an SBOM should be automatic, for all official builds (test and development builds that don’t leave the dev lab don’t need an SBOM). It should be part of any CI/CD build pipeline and provide the SBOM alongside the rest of the build artifacts.
The resulting SBOM has both SHA256 and SHA1 hashes for code, which go beyond the NTIA specification, and the resulting files have their own digital signatures for added security. It even keeps track of the build system used, with a signature encoding the build run. Finally, the output of a build is checked against the SBOM and if there are any discrepancies, the resulting software is not released, preventing compromised code from executing in services such as Azure.
Build your own SBOMs for more than secure software
There is a lot of value in understanding the software supply chain, and it is not just a security issue, it can solve problems in building and maintaining business relationships. Having a public SBOM for something as ubiquitous as Word will help improve relationships between suppliers and their customers. Requesting proof of origin for software will soon be part of all contract negotiations, allowing companies to manage risk more effectively. If an SBOM is installed alongside your software, pass it 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 will open source its SPDX tooling, allowing you to use it in any CI/CD tool and in any IDE. The same tool that is in Visual Studio for .NET is in Android Studio for Android or in XCode for iOS. That’s a big win for the entire industry as organizations expand the SPDX platform and provide us with a cross-platform, industry-standard way to understand the increasingly complex world of the software supply chain.