Without Transparency, Software Supply Chains Can Fall Apart at the Seams
When purchasing a car, if you wanted to find an itemized list of every nut, bolt or auxiliary component, you’d be able to do so. Manufacturers cannot market a vehicle without accounting for each and every part used in its development. Without this piece of due diligence, product recalls would be impossible to roll out when parts are identified as being faulty.
If you were to buy a piece of candy, you can find out exactly what’s in it by examining its ingredients and nutritional information at the back of the packet. Visibility is something that we’ve grown accustomed to when it comes to food. Besides being the law, we wouldn’t tolerate eating something without knowing what’s inside. We’ve come to expect a certain level of transparency.
Yet for many years, and even with all we know about cybersecurity and information security risks, there has been limited visibility into what makes up a piece of software, its supply chain and the third-party components. While we as retail customers could tell you what ingredients make up a piece of candy, many organizations are unable to record and summarize all the software they produce, consume and operate. This lack of transparency is a major problem.
Today’s software solutions are made up of parts from many different vendors, often referred to as the software supply chain. Without visibility, software supply chains fall apart at the seams. Unless there is a certain level of transparency, software supply chains are vulnerable to security and compliance risks. When issues or breaches occur, it can be very difficult to find solutions when all items are not accounted for properly.
SBOMs hold the key to greater transparency
One solution to this issue is to use a software bill of materials (SBOM). The software bill of materials provides a list of all software components within a given device or system. Items listed within an SBOM include libraries, drivers, firmware, license information, dependencies, and operating systems. An SBOM should also include the supply chain relationships between those components, whether open-source or proprietary, free or paid. This type of information is critical when analyzing software for vulnerabilities. Given the obvious similarities, an SBOM is often depicted as a nutrition label or ‘ingredients list’ for software. This comparison is something we examined in more detail in a previous blog post.
Using SBOMs to tighten supply chain security is something that has been endorsed by government bodies all over the world. In May ‘21, US President Joe Biden issued an Executive Order (EO) on strengthening the nation’s cybersecurity infrastructure. This order followed a string of high-profile cyber-attacks. The executive order pointed to software bill of materials (SBOMs) as a way of ensuring the safety and security of software supply chains across US critical infrastructure.
Why it’s important to share your SBOM
Using and sharing an SBOM is in the best interest of not just your product but the entire software supply chain.
In its two-page SBOM overview, the NTIA stated the following:
“Software vulnerabilities are the by-product of both the human process of developing software and the increasingly frequent target of attacks into the software supply chain. If users don’t know what components are in their software, then they don’t know when they need to patch. They have no way to know if their software is potentially vulnerable to an exploit due to an included component – or even know if their software contains a component that comes directly from a malicious actor.”
If there is one thing that everyone in the cybersecurity community can agree on it’s that you can’t secure what you do not know. One of the key reasons for using SBOMs is to provide manufacturers with greater transparency of what’s going on ‘under the hood’. Knowing the components of software installed on a device can save hundreds of hours in the risk analysis, vulnerability management, and remediation processes.
Transparency helps markets thrive. Earlier, we highlighted how nutritional information is shared openly on food labeling. Nutritional labels don’t guarantee people will eat healthy. However, it does give customers the information they need to make healthy choices. Similarly, an SBOM won’t automatically solve all security problems, but it does empower teams to solve cybersecurity issues faster and easier.
Why medical device manufacturers shouldn’t fear SBOMs
In a recent Forbes’ article, Daniel Riedel shared three reasons why software developers are tentative about sharing SBOMs. Developers’ fears include:
-
-
-
-
-
-
-
-
-
-
- That the transparency offered through using SBOMs will make it easier for hackers to attack.
- That building the SBOM itself will extend software delivery times.
- That the package listing all the software in an organization will be unmanageably large.
-
-
-
-
-
-
-
-
-
Being transparent with the SBOM isn’t going to create a roadmap for attackers. Instead, it creates a roadmap for an organization and its customers to be able to respond to threats quickly. Modern best practices in software development require solutions to be assembled a piece at a time. Adding an SBOM component to that process and building it into a DevOps continuous integration and continuous delivery pipeline isn’t a lot of additional work. And if it’s large, that’s not necessarily a bad thing. SBOMs are designed to be machine-readable so the size of an SBOM doesn’t really matter.
A software bill of materials (SBOM), like any other security feature, won’t solve all our problems. But greater transparency in the software supply chain supports more secure software development, enables more informed decisions around software selection and allows organizations to respond much more quickly and efficiently to new vulnerabilities. The benefits far outweigh any concerns that developers might have. Using SBOMs and creating a more transparent environment holds the key to strengthening the entire software supply chain.
