“Did you pack your suitcase yourself?”

Know your software stack!

Everyone knows the question at customs when going on holiday: “Have you packed your suitcase yourself? Are you sure no one else was able to put anything in before you shut it down? “. Of course you know for sure that no one has been able to mess with your stuff, but who doesn’t have a little bit of doubt every now and then?

A similar question could be asked by your CIO, executive or accountant if another hack of a municipality, government agency or large company is in the news; “Are we sure that this leak is not in our software stack ?” I fear that you will remain guilty of the answer, especially when you consider that, according to a recent study, 78% of the code of your software consists of open source code and that 81% of it contains at least one vulnerability. We have seen reports in recent months with some regularity about open source software with which there were the necessary problems, xdus new this is not, but still …

Components that are more than 2 years behind

The Synobsys Cyber Security Center recently published the report “THE 2022 OPEN SOURCE SECURITY AND RISK ANALYSIS REPORT” and the findings should give a high priority to anyone who prioritizes a secure software stack the necessary headache. Even in a “closed” industry like healthcare, >93% of the codebase has  open source components. Neatly incorporated into a read.me file or addendum to the contract, many open source components are mentioned by name, sometimes even with the type of license under which it is made available by the community. But not all of them and certainly not what the supplier’s policy is regarding updates and new releases. If you then consider that, in the above research, it regularly turned out that OS components were more than 2 years behind on updates or even contained out-of-date (no longer supported) versions, then the seriousness of the problem must gradually become clear.

Do you know which version(s) of OpenSSL are currently being used in your software stack?

Even though you may not know what kind of unreliable software your organization depends on, you can be assured that criminals do. Without detracting from the quality of open source, it is clear that a new monster has been created; a software supply chain that consists of so many different components that no one knows whether the software stack (commercial and open source) can still be trusted. An example: OpenSSL is an open source component that is widely used by software suppliers. Of the OpenSSL code whose origins go back to 1998(!!) more than 8000 forks have  been made (a copy on which further development has been done) and there are about 1500 outstanding problems. The latest version dates from May 3, 2022 and contains important security fixes. Do you know which version(s) of OpenSSL are currently being used in your software stack and whether the latter fixes have indeed been incorporated into it?  Do you get guaranteed updates from all your software vendors and how do you know they’re sticking to them?

There is really only one solution to this problem: You only purchase applications and services from the cloud. The offering party is responsible for the software stack and you don’t have to worry about that anymore. Of course, agreements must be made with the providers about their patch and release policy.

Unfortunately, for most organizations, it will be years before it gets that far, and in the meantime, this problem is only getting worse; more and more open source code is being used and cybercriminals will increasingly take advantage of the vulnerabilities in all those different components of the software stack. So you will have to take other measures for the software you still use:

1. The management is outsourced to external (specialist) parties. Such a specialized party manages a specific part of the software and that makes it easier to ensure that this software stack is as up-to-date as possible. Think of complex security solutions, monitoring software or complex integration software such as iPaaS environments or API Gateways.
2. You purchase functionality as a service so that you no longer have to take ownership of the software at all. Good examples of this are, for example, monitoring security events or fully outsourcing API and ESB links and all software involved. In the case of security monitoring, you have the benefits of your partner’s highly specialized knowledge and state-of-the-art software stack, and if you work with an integration partner, your developers can focus on functionality while specialists deal with secure integrations and all the issues and software that makes that possible.

It is a given that every software stack is a motley collection of code that is not always clear how up-to-date and secure it is. You will have to make agreements with your suppliers about this, but at the same time you must decide whether some of these responsibilities can be placed elsewhere. And even if you partially succeed, there is still enough left to worry about.