In the past year, more and more businesses have been hacked, causing massive disruptions to supply chains everywhere. These outages didn’t care what sector a business was in—they were ruthless no matter who they targeted. Thus, not only were supply chains halted, but businesses lost both income and the confidence of consumers.
The issue became so prevalent that the president of the United States had to task his administration with developing a cybersecurity executive order that focused on shoring up supply chain security. Part of this executive order stated:
“The security and integrity of “critical software” — software that performs functions critical to trust (such as affording or requiring elevated system privileges or direct access to networking and computing resources) — is a particular concern. Accordingly, the Federal Government must take action to rapidly improve the security and integrity of the software supply chain, with a priority on addressing critical software.”
Clearly, the issue of securing supply chains is of utmost importance. But where does this start? It starts with you, your company, and how your developers work from the very beginning.
Chances are pretty good that your company depends on containers, dependencies from third parties, or even operating systems. But no matter what you build, deploy, or depend on, one thing you can do to help ensure you can confidently back what your company creates is work with a Software Bill of Materials.
What is a Software Bill of Materials?
Let’s make this easy. Say, for instance, your developers are working on a containerized application that will completely revolutionize how your business functions. Your software engineers base this new project on an image they’ve either created or pulled down from DockerHub.
The big question is this: What’s in that image? Do you know every application, dependency, and library? And, more importantly, are those included pieces free from vulnerabilities? That’s something a Software Bill of Materials can help you answer.
Effectively, a Software Bill of Materials is a list of everything found in an operating system, image, or platform. With this in hand, you are better prepared to either know what you’re working with or can better answer when a third party comes to you wanting to know if what you’ve developed is secure from the ground up.
Without that information, you really can’t answer. Sure, you can confidently say, “The software we’ve built in-house is secure,” but you can’t apply that to the images and libraries your projects depend on. These SBOMs can be used for things like pre-IPO or M&A due diligence, customer requests, and government regulations.
Benefits of SBOMs
The benefits of SBOMs are many, including:
- Deeper transparency, which generates loyalty and trust.
- Tighter security.
- Supply chain resiliency.
- Lower costs.
- Less bloat in software code.
- Better software/project end-of-Life management.
- Improved compliance.
The above list alone should have you wanting to start your journey with SBOMs.
How do Create a Software Bill of Materials?
This will depend on what you’re using and your needs. But it’s important to understand that your SBOMs aren’t just for internal use. If you create something (especially if it’s under an open-source license), you should be willing to share the SBOMs with other developers and/or companies. You might even find yourself in a situation where a government entity requests your SBOM.
So how do you generate one? Let’s take a look at 2 different use cases and how an SBOM can be generated.
Let’s start with a use case that has your developers basing a product on Ubuntu Linux 20.04. You need to know every single package installed on the base operating system, so you can then, in turn, audit those packages to make sure they don’t contain vulnerabilities.
With Ubuntu Linux 20.04, you can create an SBOM that will contain every package installed (as well as the version number of said package) with the command:
apt-list --installed
The above command will generate output such as:
xserver-xorg-video-nouveau/hirsute,now 1:1.0.17-1 amd64 [installed,automatic] xserver-xorg-video-qxl/hirsute,now 0.1.5+git20200331-1 amd64 [installed,automatic] xserver-xorg-video-radeon/hirsute,now 1:19.1.0-2 amd64 [installed,automatic] xserver-xorg-video-vesa/hirsute,now 1:2.5.0-1build1 amd64 [installed,automatic] xserver-xorg-video-vmware/hirsute,now 1:13.3.0-3 amd64 [installed,automatic]
With each line, you see the package name, the version number, and how it was installed/upgraded. You could send that data to a file (for later viewing or analyzing) with the command:
apt-list --installed > SBOM
You now have a Software Bill of Materials for the operating system used as the base of your project.
If you’re using Windows as a base, you could generate that SBOM with the command:
C:\> wmic /OUTPUT:InstallList.txt product list BRIEF /format:csv
If your project depends on container images (such as those pulled down from DockerHub), you could employ the Syft tool and issue a command against your image like so:
syft IMAGENAME
Where IMAGENAME is the name of the image to be scanned. Once the scanning is complete, Syft will list out the entire SBOM for the image.
There are other tools (and even third-party services) that can handle the generation of SBOMs for your projects.
Conclusion
It’s imperative that you begin working with a Software Bill of Materials. You need to understand what’s included with the software you use and need to be able to hold yourself and your developers accountable.
At some point, you might wind up using a library, dependency, or container image that includes vulnerable (or malicious) software. Should that happen, you need to be able to show your work and be capable of rooting out and fixing the problem. A Software Bill of Materials is a great place to start.
