Can Software Bill of Materials (SBoM) Ensure Cybersecurity?
image credit: Photo 188715333 ©
A Bill of Materials (BoM) serves a useful purpose in hardware. In addition to listing components, it also provides a useful system to track the final product through the manufacturing supply chain and coordinate with component vendors.
A different function is currently being discussed for the Software Bill of Materials (SBoM), however. In an age of vulnerable applications and Industrial Control Systems (ICS), can an SBoM help in cybersecurity?
The case for an SBoM in cybersecurity is a strong one.
Modern software is a product of two competing strands of thought - open-source and proprietary. As their names suggest, the former emphasizes sharing and collaboration while the latter is focused on intellectual property and profits. While they are diametrically opposite in their conception of the software ecosystem, both approaches work well with each other and proprietary systems often borrow and reuse open-source software libraries in their code. In fact, the average percentage of open source codebases in proprietary applications reportedly increased from 36% in 2017 to 54% in 2018.
The increased melding of these two styles of software development means that vulnerabilities of source code are also transferred along with their functionalities, making it easier for hackers to target multiple systems at the same time by exploiting security defects in a single component. SBoMs can help cybersecurity analysts simplify the process of identifying and patching the software vulnerability and replicate their efforts at scale.
The Problem with SBoMs
But the devil, as always, lies in the details. The levels of details in this case, to be precise. SBoMs can be at the license level (such as those for operating systems or application software), module levels (such as those that replicate a functionality or feature from a given application), patch levels (such as those that replicate security patches for a software vulnerability), and backport levels (such as those that replicate custom patches developed by an individual customer).
As one moves down these levels, the granularity of information and code multiplies. License level detail does not provide much information to identify problems with an application because it refers to potentially millions of lines of code in an operating system or application. For example, simply listing that a security vulnerability lies in a particular version of Linux or MacOS or Windows could put an entire organization, which runs these operating systems, at risk. Drilling down across levels increases the amount of work and time required. For ICS systems, especially, the task might prove particularly arduous given the level of detail required and lead to long service disruptions as professionals grapple with complex systems.
The complexity of software distribution models further complicates SBoM use. For example, client/server models (in which the clients only run instances of software that resides on an application) and the cloud model (in which the actual application resides on the app cloud but offline processing may be possible in some cases) both make it difficult to identify vulnerabilities at the customer level.
SBoMs also do not solve the vulnerability tracking problem. In the wrong hands, an SBoM could prove to be a useful roadmap to identify an exploitable piece of software and bring down multiple systems across industries and countries. SBoMs can be useful for air happed computers, which are physically isolated from the rest of the network. But such systems are exceptions rather than the norm in a connected world.
Of course, this does not mean that SBoMs are useless. Indeed, increased digitization of industries has made cybersecurity of ICS systems such a pervasive threat that SBoMs are being considered by regulatory agencies across sixteen critical infrastructure sectors to streamline the process of identifying component vulnerabilities. For example, the Food and Drug Administration introduced the concept of Cybersecurity Bill of Materials (CBoM) in its Premarket Cybersecurity Guidance last year. Cross-checking the CBoM against the National Vulnerability Database will provide ready and expedited means to identify and stop malicious code. But getting the level of detail included in this database is paramount.