THE cloud, or a cloud; your BI application wants everything!
During the Integration Knowledge Session of Enable U last summer, the question...
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:
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.