You Need a Software Bill of Materials. Cybeats Can Tame the Complexity

How much confidence do you have that you know everything that’s in the software that runs your IoT or medical device? Don’t be too confident—your software could have some risky “ingredients.”

Modern software is not a monolith. Rather, it’s stitched together from bits of code and subroutines from numerous sources, including open source and commercial solutions. Reusing software code like this means developers don’t have to create everything from scratch themselves. It’s a real time and money saver, but it does come at a price.

According to industry studies, the average codebase contains hundreds of open source software components. It’s quite likely that some of those components have vulnerabilities. How would you know what vulnerabilities exist if you don’t even know what components are in your software codebase?

There’s an industry effort underway to track individual components such as libraries, executables or source code that go into a software program. Initiated by the National Telecommunication and Information Administration (NTIA), the effort is an industry-led, multi-stakeholder process to improve software component transparency. The NTIA working group is establishing a shared vision of transparency and a “software bill of materials,” or SBOM.

What is a Software Bill of Materials?

A software bill of materials is effectively a list of ingredients that make up a software program or application. It identifies and lists all software components, information about those components, and the relationship between them. The figure below illustrates this concept. The chart on the left shows the information that is tracked, while the diagram on the right illustrates the relationships of the software components.

As the NTIA working group goes through the SBOM specifications development phases, the members are mindful of the inherent complexity of building and maintaining a verifiable software components list. Issues they are currently working on include how to automatically generate an SBOM and keep it up to date; what standard data format to use for the information; how to securely distribute an SBOM to someone who acquires a software program or application; and how to verify the authenticity of the data in the components list and their inherited dependencies.

The intent is to define specifications that can be used worldwide by both software developers and consumers of software (for instance, device manufacturers). Adoption of SBOM by individuals and companies that are writing open source software will be key to the initiative’s success.

The medical technology industry has been on the forefront of creating a proof of concept initiative. Manufacturers want to understand the role that SBOMs can play in managing the operational and cyber risks associated with medical devices. Working together, device manufacturers and healthcare providers demonstrated the feasibility of SBOMs by generating, sharing, and using data to improve security practices in pre-defined use cases. NTIA is applying the lessons from that PoC to develop industry-agnostic specifications for the applications of software bills of materials.

The need for a Software Bill of Materials

All devices have a software element to them. The developers who write code for IoT, medical, or industrial devices don’t write their full codebase from scratch. Like all other software developers, they go to public code repositories and pick up existing modules, subroutines, engines, and more that can be put together like puzzle pieces to create the final software. Chances are they aren’t fully documenting all of these software components, and they certainly aren’t keeping track when any of them change, such as for a patch or update.

A software bill of materials would establish greater transparency of what code components are in software. This enables device manufacturers to control risk by enabling earlier identification and mitigation of vulnerable systems. It also supports informed purchasing decisions. This is especially important where compliance with software licensing requirements is concerned. Further, it incentivizes secure software development practices by enabling developers to better vet the code they are embedding into their own work.

Perhaps the greatest value of having a verified SBOM is in the realm of cybersecurity and risk mitigation. Once you know precisely what components are in your software, you can get a clear vision of the risk factor this specific bill of materials brings to your environment when it runs. What’s more, the risk factor can change whether or not something in the software bill of materials changes, given that new vulnerabilities are discovered on a daily basis. The only way to know if you are affected is by having this level of transparency and conducting continuous monitoring.

This means of risk assessment is especially relevant when changes are attributed to insider or outsider threats. An insider threat occurs when an internal employee changes something without understanding the full impact of that change on the overall risk; for example, installing an application foreign to the SBOM considered to be shadow IT. An outsider threat occurs when an attacker injects malware into your server or a device and tries to make it look like a legitimate component of your system by replacing or introducing a new software component. Either way, expecting to have one component and actually having another introduces a lot of risk to your system.

Cybeats is taking a lead with solutions to manage SBOMs

We understand the SBOM is quite a complex entity to maintain and connect and resolve all of the layers of dependencies for the software. We intend to be an expert resource to greatly simplify the process for device manufacturers. Cybeats is focused on solutions for generating and maintaining the SBOM; verifying its authenticity; distributing it securely to authorized parties; and using it to maintain a secure environment for the device the software runs on.

The first point of value that Cybeats will deliver around SBOM is the ability to automatically recognize and understand the dependencies of the software components on a bill of materials list. Then we can clearly enumerate the vulnerabilities and security gaps within that SBOM.

We also have to keep in mind that an SBOM is dynamic, and it’s constantly evolving as software patches are applied and new versions are available of the components. In fact, if the components on an SBOM list are not patched and updated, the overall security of that bill of materials will soon begin to degrade. Every device manufacturer should want to keep their device(s) evolved to some predetermined level of security—and this is at the core of what Cybeats does today.

The next thing is the continuous integrity verification of that SBOM. We need to be able to use the bill of materials list to discover if there were illegitimate or unexpected modifications to the software on a device. Here, context is important to understand.

The SBOM gives a static list, but the system that software runs on is continuously working. There is data coming in, data going out, software processes are starting and stopping, operating systems do different things juggling the running applications. This is all to be expected with a device that’s in continuous operation. We need to be able to know the context and apply that on top of the software bill of materials to understand reasons why every single component is there and what is really involved in operations and what is not. Once we know that, we can also detect any attempt to modify any component of the SBOM or to add something that does not belong there.

It's not a trivial task to create a software bill of materials and then share it with customers or partners based on contractual agreements—yet it’s something device manufacturers need to be able to do. In the world of agile development for software, developers are continuously changing things. There is a velocity to the development process and it is all about combination of DevOps, security and CI/CD. All of the changes need to be able to propagate to the right places. If a device manufacturer shares a software bill of materials of version one of its software with its customers, there might subsequently be 20 different versions of the software released over the next two months. This process plays havoc with keeping the SBOM up to date for each customer. This is an area where Cybeats will be playing a major part.

When sharing these software bills of materials with customers and partners, they need to be shared over a secure protocol, and shared only with the proper people and not with anyone else. Consider this: If the end user of a device represents a company that is of national level of importance, we don’t want the SBOM to be shared with the public where anyone can go and see the software components inside a substation automation device.

From a device manufacturer’s perspective, it’s critically important to give permission only to specific customers to see this software bill of materials and to control how they are using and consuming it. It’s also important to control the distribution of the bill of materials, and to ensure its authenticity.

Ideally, the SBOM would be distributed over encrypted channels, and signed by a global authority with a certificate or any other technology that evolves to sign them.

Looking at these concerns, it’s easy to see that matters are quite complex concerning a software bill of materials for devices used in medical facilities, critical infrastructure, manufacturing facilities, and more. Solving these challenges is a monumental task, and Cybeats is on the forefront of the effort because the upsides of deploying a software bill of materials are so great.