Software Supply Chain: Risky Digital Ingredients

Software Supply Chain, SBOM – can you eat it? Not so wrong, because we also pay attention to the ingredients when buying food, don’t we? It’s a good thing that today’s packaging contains an ever-increasing amount of detailed information over the past decades. Ingredients, allergy information, colorings and nutritional values – all of this interests us and is considered perfectly standard. In recent years, there have also been additions, such as the Nutri-Score, which, with its traffic light colors and letters, is reminiscent of the energy labels we know from the last time we bought a household appliance. The latter, by the way, was not a creative marketing idea, but is based on the science of nudging – little hints that are supposed to influence behavior and are now perfectly standard.

Now let’s take a look at the packaging of the last digital product we bought. What stands out? It doesn’t matter whether it’s a cell phone, laptop or game console: Nowhere is it apparent before use what you’re actually buying or what’s contained in the product. And let’s be honest, even after buying and unpacking the product, you still don’t know in detail. The question why this should change now is quickly answered when we look back at typical events like Log4j. Suddenly a piece of software is in the press because there is a security problem. And all of a sudden it’s on – everyone wants to know whether they are using the insecure digital element somewhere, whether it is installed as software in a device, for example, or whether it is even in their own, sold product. What if the first concerned customer calls and asks?

Medical devices in focus: What happened in the last few months

My first contact with the topic of software supply chain was the topic of SBOM. The term stands for “Software Bill of Materials”, and at least the “BOM” part of the term is familiar to anyone who has ever played with Lego or shopped at IKEA: It’s a classic bill of materials, a listing of parts, and virtually the table of contents. Whether it’s screws, components or connecting pieces, the BOM shows you what’s included.

Based on this principle and due to numerous incidents with smart, digital medical devices, including hospitals paralyzed by hacker attacks, the U.S. FDA, as the highest health authority in the U.S., was initially on the verge of issuing a regulation. This was supposed to lead to every manufacturer of products that function not purely as physical devices but through integrated software having to deal with the following issues:

• A presentation of the SBOM for the product
• The origin of the components as well as the versions of the software
• Known vulnerabilities
• A plan on how to keep the software up to date

…to name just the most important elements. We know it from cell phones and laptops: updates are important, but unfortunately many manufacturers of products in the medical field do not yet work according to this principle. Ever since insulin pumps were hacked, raising the question of how easily a hacker could kill the user (or patient) of such a product by overdosing, the state of affairs was over – the first drafts of so-called Regulations for Cyber Security in Medical Devices were published and made it clear to manufacturers that from now on they are not only producing medical devices, but are also software companies and IT service providers in regulatory terms.

Transparency about software – actually quite a normal thingh

So the goal is clear: Every new product that is to be approved, and probably soon also products that are already on the market, are to be tested with regard to the security of the software they contain, and thus the risk of an incident is to be contained. Up to this point, everyone will probably agree that this is neither excessive nor senseless. At the same time, the question arises as to how companies that have previously used software in their products more as a means to an end are to master the situation. Actually, the challenge should not be too great, because after all, there are developers in the manufacturing companies who should know what is in the products. And this is where the so-called “white label problem” begins, because many products that are supposedly manufactured by company A actually come from the factory of company B. The latter does not manufacture products to sell under its own name, but rather with a “white label”, unlabeled and as a blank product for company A. In this way, there are thousands of product categories that are dominated by one manufacturer and end up on the market with certain adaptations under a known name, depending on the claim and target group. Whether it’s a credit card, a lighter or shoes: whitelabeling is a billion-dollar business.

Accordingly, the obligation to provide transparency and security applies to many manufacturers of the medical technology focused on here, but the chips, sensors and software parts contained in them are usually bought in. Thus, the responsibility cascades downwards and we realize that a manufacturer of such a piecemeal product is now suddenly also in the responsibility – although he produces his products for all kinds of industries. It therefore follows that any industry that supplies medical technology in any form will now also have to contend with the issue and perhaps consider whether its technology is actually suitable for this. At first, this sounds logical and feasible, but for many of the products of our time, it is not possible – because using the example of a Bluetooth chip, it quickly becomes clear that this chip could also be in an absolutely non-medical product such as a pair of headphones. So who is responsible in the end? Ultimately, it is probably the manufacturer of the marketed product who must now test the suitability more closely than ever before. Another appropriate example is the automotive industry, which has had to comply with UNECE R 155 for some time now due to changes in approval procedures for vehicle development – cybersecurity in the vehicle, which also makes sense in today’s completely digitalized vehicles. Here it even gets a little thicker, because the next standard UNECE R 156 regulates the security of update processes when the vehicle is supplied with new software overnight in the parking lot. After all, no one wants the electronic parking brake to trip on the freeway on-ramp.

And this brings us full circle, because medical technology is also to be supplied with security patches in the same way as a cell phone or a Windows PC, with the buzzword TPLC, the so-called “Total Product Lifecycle”. This includes all kinds of other issues such as communication with customers, constant testing of the security of software components and, in extreme cases, the recall of products that are no longer secure. Thus, one can imagine these industries as being similarly closely timed in terms of processes in the future as the apps on the cell phone or a software product on the PC. But that’s not all: Next up is the call for cyber security labeling, a printed list of ingredients that is visible on the packaging and suitable for consumers. This should enable customers to see on the box of an iPad in the store whether they are allergic to a certain piece of software in the device – but how this can and should look in concrete terms is still the subject of research. On the other hand, it is widely accepted that certain software should not be installed on everyday devices ex works. But what does that mean for us as business people?

Concrete procedures, tips and a look ahead

Basically, I advise customers to first make a structured note of what is obviously in their own products. We usually start by talking to product managers or compliance managers, who know surprisingly little about the details of this. On the other hand, many developers and programmers have been wishing for years that they were put more in the center of attention – instead of just hearing the eternally repeated announcement about lower costs and faster development times. Now it’s the turn of these experts and the clear recommendation is to simply talk to these people. It is not uncommon that even weaknesses, problems and solutions are known, but were never asked for or ignored as concerns because the business was only about sales. So, the first step to survey the quantity structure of software in your own products is not that hard!

Next, management should understand that the assets that have found their way into products through programming and digitization now represent a new, relevant risk class. Together with quality management and controllers or risk analysts, you can now translate what it means to use a 10-year-old open source library and how useful it suddenly is to use the more up-to-date alternative that is always patched with security. Today, every, absolutely every product and every category of usable technology is dissected and analyzed not only by the often quoted hackers, but also by security experts – regardless of whether it is a car at the end of the production line or a company that manufactures pacemakers: The hardware itself, the product and the casing are just the trappings; now it’s a matter of dealing with the innards and being ready for all the demands that have been explained here. The company’s risk appetite will therefore change and the “Total Product Lifecycle”, or TPLC for short, will become a new dimension of planning for management and product managers as well as their developers. Of course, this will also change the TCO factor, i.e. the total cost of a product from conception to discontinuation.

So what’s next? At the end of March, the American FDA set an end date for the transitional period for the approval of medical devices. As of October of this year, cybersecurity with its SBOM and TPLC components will be mandatory – and manufacturers who submit for approval without appropriate evidence of processes, plans and methods will simply be rejected. Incidentally, the European Medical Device Regulation, MDR for short, has helped to ensure that software can now be classified as a medical device – which should finally make it clear that digitization in product development is causing numerous changes and that the industries mentioned here as examples are only the beginning of products being able to obtain market approval only with an actively managed software supply chain.

Philipp Schneidenbach

Philipp Schneidenbach ist Experte auf den Gebieten Enterprise Architecture, Governance, Risk und Compliance. In seiner derzeitigen Position bei Materna vereint er die Erfahrung aus mehr als 25 Jahren Beratung und Linienverantwortung in verschiedenen Industriezweigen und Märkten. Als Autor, Researcher und Speaker engagiert er sich unter anderem in Organisationen und Berufsverbänden wie der IEEE, ISACA und MoreThanDigital.