The compromise of SolarWinds’ system management tool raised a lot of interesting issues for anyone using a CI/CD (continuous integration and continuous delivery) build process for their software. How can we ensure that the software we distribute to our users is the software we intend to build? Are all the dependencies for our code the ones we intended to have? If we’re using third-party modules, are they still what we expect?
It’s a complex problem, made more complex by the layered and nested foundation of dependencies we’ve placed under all our code. Modern development relies on code from repositories all over the world, developed by countless teams and individuals we will never meet. Even so, we trust their code to be what it says—a trust that we pass on to our users.
It’s all deeply intertwingled, as Ted Nelson would have put it. A network of software development goes far beyond our desks and our repositories. What do we do to ensure trust in our code?
Why a software bill of materials, and why now?
The U.S. administration has responded to the SolarWinds compromise with an “Executive Order on Improving the Nation’s Cybersecurity” that requires the National Institute of Standards and Technology to develop and publish guidelines to enhance the security of software supply chains, the networks of modules and components that come together to build our code. Those guidelines are now available. They require software to ship with a software bill of materials (SBOM) that details the components that ship with your code.
SBOMs aren’t new. Many companies, Microsoft included, provide them to their users using proprietary manifests. Without standardization, formats vary and often aren’t machine-readable. Microsoft was working with the Consortium for Information and Software Quality in its Tool-to-Tool SBOM working group to develop a standard for SBOM schema. The U.S. executive order added urgency to this process, and the working group has moved to merge its work with the Linux Foundation’s more mature Software Package Data Exchange (SPDX) format.
Microsoft has been using its own tool to generate component manifests for its software with its own report formats. As a result of joining the SPDX standards process, Microsoft’s internal tool has been updated to use this alternate format, rolling it out across its own development and build pipelines.
Tools like this need to be widely available, easy to use, and work across all the platforms you’re likely to use for your code. They need to plug into common development tools or into CI/CD pipelines to ensure that information about code is captured where it’s developed and where it’s compiled.
Generating an SBOM twice may seem like overkill, but if your CI/CD pipeline has been compromised, a comparison of the SBOM at a merge with one at a build can help identify possible issues before code ships. A well-designed SBOM tool will deliver the digital signatures and hashes needed to add additional authentication to a build process to help identify not only if it has been compromised, but where and when that compromise occurred.
Use Microsoft’s tool in your own builds
Microsoft’s internal SBOM tool is now open source, with binaries and source code available on GitHub. The project is moving fast and adding new detectors to help identify code and where it comes from—as well as what dependencies it brings to your code base. That last point is key. You may know what you’re installing from NuGet or npm, but you have far less insight into the code it depends on. You might think you’re shipping something innocent, only to discover that one tiny dependency is running a cryptominer on your clients’ hardware, sending cryptocurrency to criminals on the other side of the world. Suddenly not only are your customers running insecure, risky code, but you’re now liable for that risk and for any resulting issues.
Installing Microsoft’s SBOM tool is simple enough. The GitHub readme has scripts that download the latest binaries for Windows using PowerShell, and for Linux and macOS using curl. A NuGet package works with the SBOM tool API, which you can add to .NET projects. This uses GitHub’s own package repository, which you need to add your project file’s PackageReference. Once you’ve updated your code’s .csproj, run dotnet restore to install the package for your project.
The current version of the Microsoft SBOM tool is a command-line application. Once downloaded and installed, it’s ready to use. You will need to create some files for the application to run. The most important is a list of the files that need to be included in your SBOM. This can be generated from a directory listing of your application source directories, as well as from modules called by your code. You can even supply it a list of Docker images to be scanned to generate a list of any container-level dependencies outside your code and build process.
Under the hood, one of the key components in the SBOM tool is Component Detection, a tool that can be run stand-alone or inside Visual Studio. It supports most common software ecosystems, scanning code for modules and, where possible, building a dependency graph that can show what modules are being installed and where from. Again, this is an open source tool, and if an ecosystem you use isn’t supported, there’s the option of using its extension support to add your own scans.
Script SBOM scans for CI/CD
As it’s a CLI tool, Microsoft’s SBOM tool is scriptable; you can embed it in your CI/CD pipeline, generate an SBOM as part of a build, and scan your source files for dependencies and components. The resulting SBOM is an SPDX JSON document. Although it’s human-readable, you may prefer to write a simple JavaScript application to parse the data and display it in a browser, or even use it as a feed into a security information and event management or similar security tool to report on differences between versions of an application. At its simplest, it can identify new components and dependencies that may need investigating. In more complex applications, you could generate a list of possibly risky components that require additional investigation by a security team.
One useful feature is support for layered builds that wraps SBOMs from different components of a modular application. Here each component’s build generates its own SBOM from its own dependency tree. When the application is packaged in a final build phase, the tool generates a combined SBOM for the entire application, ready to share with customers. Individual SBOMs are referenced in the final manifest, allowing them to be checked against the final build’s SBOM to ensure that unwanted software isn’t being packaged alongside your code.
SBOMs are an important tool for modern software development, and in the current security environment, they should be thought of as essential. Automating construction of SBOMs is important as the depth of the dependency chain can be near impossible for developers to fathom. By including tools to identify modules and components and scan containers, Microsoft’s free SBOM tool goes a long way to meeting regulatory requirements while letting you get ahead of customer demands by proactively offering an SBOM and component manifest as part of every install.
