Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm an Analyst and Advisor with KuppingerCole Analysts. We're back. So the hiatus after EIC is over. So we took a few weeks off for the podcast to allow KuppingerCole to publish all these videos, these really interesting videos that we recorded during EIC. But now we're back. It's early July and the topic I want to cover is a topic around the area of cybersecurity, a bigger area of cybersecurity. We will cover that in a second. For that, I welcome Alexei Balaganski. He's a Lead Analyst, I think, at KuppingerCole Analysts. Hi, Alexei.
Well, hello, Matthias. Thanks for having me again. Yeah, absolutely looking forward to talk about cybersecurity, not just as an analyst, but also as a KuppingerCole CTO. So I'm planning to look at this topic at least from two different perspectives.
Right. And the topic that we are talking about is software supply chain security. So we want to look at how to deal with software that we inherit from somewhere. So if we look at that topic from your angle, can you give us an overview what that topic that cyber supply chain or sorry, I start again, software supply chain risk management or software supply chain security actually entails, what is in there and does everybody mean the same things?
Well, to be honest, Matthias, this is like the most difficult thing for me at the moment, because obviously, on the one hand, the topic is so hot at the moment. Just a few days ago, we have learned about the next big vulnerability. This time it's in SSH, in OpenSSH again, which basically affects every Linux system in the world, including our own service, for example. On the other hand, this whole software supply chain security and software supply chain in general is like a topic everyone is talking about because somehow it's really important from different perspectives. And yet I have this feeling sometimes that people are talking various different languages because they are definitely referring to completely different scopes and capabilities and even like basic plain definitions. And I think we should probably start from looking back a little bit and like where did this definition even come from? I mean, it obviously comes from supply chain risks and security in general. Like for example, imagine you are an aircraft manufacturer and for years you've been receiving your titanium supplies from one big Eastern country and now you can no longer do it because of the sanctions. And instead you decide to get your titanium from another country, but from a much less profitable supplier, and now somehow a door in one of your aircraft just kind of blows out mid-flight and you are now in a big trouble. You obviously have a supply chain security issue. I guess the same applies to software supply chain as well. Everyone, every company in the world now is using some kind of third party software for doing their daily business, including obviously companies who also do develop their own software, but also those who just buy it off the shelf. And like even an operating system like Linux or Windows is also third party software. So any risk applying to that kind of software would by that definition belong to the field of software supply chain security. Sounds sensible, right? But on the other hand, it basically means that the entirety of cybersecurity is software supply chain security. And to me, from the pragmatic perspective, it doesn't really help because it doesn't give me any practical recommendations. Like where do I even start fixing my supply chain issues? What's your perspective on that?
I look at it from one angle that is a bit different because I'm talking to lots of our end user organizations that I'm mainly an advisor currently. So they come up with all these new regulations and they have to conform with that. They're talking about NIS2 and they're talking about DORA and what these regulations, I'm not a lawyer, this is my interpretation, what they have added, what has not been in there previously in ISO 27001, that is constant risk management, A. And B, supply chain risk management. So understanding the supply chain in general and to say, okay, software supply chain risk management sounds like, yeah, a subcategory of that. The question is how to make sure that you take the right measures to be compliant or to at least not fall incompliant when it comes to what you just described, is using software that incorporates software that is built somewhere else. And the challenge is even bigger because it's not only a one step approach. So I consume software from somebody. So maybe that component consumes software from somebody which consumes software from somebody. So it's a daisy chain that needs to be understood as well. And that is a real big complexity.
So again, before we even answer any practical questions, we have to consider that there are at least, I can think of three completely different views on this whole problem. The one is the end user problem. Basically, they know nothing or nearly nothing about the actual software development, nor they care or should care much about that. They just want to be compliant with all those new regulations, right? They've been consuming, they've been using third-party software for decades now and they do not expect much to change with this new regulation. And yet they still have to implement new controls, they have to follow new regulations and frameworks, whatever. This is like one perspective. The other perspective is from a point of view of a software development company. Again, they've been, actually that's been their bread and butter for decades, perhaps. They've been developing software. And of course, we all know that nowadays software is like 90 % based on existing third-party building blocks, including open source libraries and projects. Like OpenSSH, for example. And now somehow with all those existing tools and technologies they have starting right from code scanning and software composition analysis and dynamic runtime analytics and looking for vulnerabilities, whatever. All those tools, I mean, they are not new, yet somehow they are all now supposed to be combined in a different kind of chain and they have to comply to a different kind of regulation, right? And finally, there is this kind of analyst perspective. We have to be able to come up with some practical advice. Okay, you ask us how do you quote unquote buy software supply chain security and we have to come up with a sensible answer. And I'm afraid that this time we cannot go the zero trust way and say, no, you cannot actually buy software supply chain security. You have to build your own because it's just a vibe, a feeling, a strategy, a process or anything like that. Because this time, as you rightfully mentioned, the regulations basically say if you don't do it, you will go to jail. And nobody wants that. So we do have to find a practical response, a pragmatic response to all those inquiries. And where do we even start?
Of course, all of us being end users, maybe also we get to the quickest answer there. How can an end user who just does not know what is in there? We have users of Windows PCs, we have users of, and of course of applications on top of Windows PCs. And the same holds true for Mac OS, for iOS, for Android, for any platform that we're using. And to be honest, even we as tech savvy, analysts, nerds, we don't have the full picture of what's going on in there, be honest. And much less has the usual, the "normal" end user. So how can they make sure that they deal with this topic correctly? Is there a way? Is there... the title of this episode is Pragmatic View on that. What is pragmatic for them?
And then again, the most pragmatic view is that obviously they do not want to do it as much as some other experts expect them to do. Because again, this is about software and software to a lot of companies is dark magic. The same as water is coming from a tap, electricity is coming from the wall, and software is coming from the internet. That is all they want to know and they don't want to care much about it, right? But now they have to. And in a way, it all boils down to the same issue of matter of trust. How can we trust that the software we are receiving from a third-party supplier is not just working properly, that it's free of bugs and stuff, but it's actually coming from that supplier, that it actually does what it's expected to do and nothing else. So it doesn't include malware, it doesn't have some hidden features which would steal your sensitive data or anything like that. No malware, no adware, no eavesdropping on your communications and stuff like that. Again, it all boils down to trust. Of course, there are industries where this has been already regulated to death in recent years, from space travel to probably banking and finance. There are tons of tools and regulations in place where you could say, okay, I've analyzed every line of source code, I've analyzed every byte of every binary, I am fairly sure that the software does exactly what it says on a team. The most companies in other industries, it would never work. Again, they are looking for a more pragmatic solution. One trivial solution would be, again, regulations, legislation. If, for example, you know that if you buy software from a vendor X and the software fails to deliver its functionality, if it's broken, if it's infected, whatever, then it's not your problem, it's the vendor's problem. Now, in that kind of world, of course, all your compliance challenges would be automatically resolved because now they're not your compliance challenges, right? You don't go to jail, the head of Microsoft goes to jail, for example. Unfortunately, we are not there yet. So we have to somehow delegate trust and we have to have some tangible tools to do that. One of the technologies people are talking about now is of course the software bill of materials. Basically, every piece of software, every application you get from somewhere else comes with a list of ingredients like the label on your groceries. And again, in the food industry, it took decades to introduce the proper level of regulation, the combination of the supplier's responsibility. So if you are buying a jar of Nutella, you can be pretty sure that it doesn't have arsenic or whatever inside, and that it should not include some industrial colorings and whatever else is prohibited in the EU, for example. So it's partially still regulation, but it's also some means to ensure that you know what's included in that piece of software. But again, if it just comes with a label, label, it's like a PDF file or a JSON document or anything else, how do you apply this at scale? How do you verify those build-up materials? Does it mean that those have somehow to be incorporated into your existing security stacks? For example, as an additional feed of threat intelligence? Because we already know, for example, that for all the domains we are visiting from our offices, we can know whether a domain has a strong and good reputation or a suspicious one. And we can block the suspicious ones. Can we apply the same approach to software builds of material, for example, saying in our company, anything below the threshold X is not allowed? If anyone tries to install a program which comes with an untrusted open source library, it just won't run. Wouldn't it be great? Is it pragmatic enough? What kind of consequences it would provide? For example, in an industry where the safety of your manufacturing process depends on that kind of stability. So many questions. And again, this is just one pretty small step towards this whole software supply chain security journey, if you will. And there are so many more to make.
It reminds me a lot of the steps and the efforts that many organizations have undergone when they first and then later consecutively and again and again deployed cloud services because they of course require their cloud service provider to do things right. And of course we expect them to do things right. And they say they do things right and they have a document, a certificate, an SOC to certificate that says yes, they're doing it right. And that piece of paper that says, yes, they're doing that right, issued by a trusted third party, that is in the end the allowance, the permission to use that cloud service from a regulatory point of view, from a commercial point of view to say, okay, yeah, it sounds good. And they have proven that to somebody and said that somebody has actually certified that to me. So what you said just right now sounds very much like that. Am I right?
You are absolutely right. Again, we have basically already figured it out years ago, like just almost. The same principles should apply here as well. Of course, the problem is basically there are only maybe, let's say, a few hundred cloud providers around the world. So it's pretty easy to regulate them. How do you deal with all the millions, literal millions of software suppliers? Because again, kind of, yes. With the cloud, first of all, you have a contract which very strictly stipulates what are your responsibilities within this relationship and what are the responsibilities of the service provider. We are talking about this whole shared responsibility model, which has been a kind of de facto industry standard for a long time. Then we have certifications, including third-party ones, where we know that, yes, this specific cloud service in this specific geographical area is basically validated by an independent party or government organization. And they say, yes, it's OK for you to use. You are, at least from the compliance perspective, safe enough. It still does not mean that you do not need your own security controls in place. You still do. But at least you know you have tons of regulations, best practices established, third party services, whatever. Even we covered a lot of those. Like for example, just recently we published one Leadership Compass on cloud native application protection platforms, which is just one relatively small but important area of making your cloud services secure. So I guess we have to grow in the same direction with software in general, but we are nowhere near that situation yet. And again, it's much more difficult because of the scale of the entire industry.
Right, when you said, okay, we started with the end user and as you said, the end user shouldn't care about that. He's not even in the situation or he or she is not in the situation to care about that. We've talked about this certification, that approving process, to allow for a corporate user, maybe even for a highly regulated corporate user to prove their compliance or at least to prevent their incompliance. So the elephant in the room then is of course the software vendor. How can we support them as analysts to make things right? How can they be educated to make things right? And which measures are there? And I think that would be an area which analysts can cover, starting with this software bill of materials. But I think there are upcoming categories, markets of software which aim at supporting these. I think it's difficult to cover that in that episode because we're running out of time anyway, but this is really an interesting and a changing topic. And I think to prevent something like that, what happened just a few days ago, there should be a mechanism that really captures this because the effect, the impact of such a vulnerability is just immense. And I should find it when I provide software to third parties.
Again, for the software development industry as a whole, the problem has been more or less, if not solved, but at least figured out sufficiently years ago. We all know that every software product has its life cycle from the design to programming, testing, deployment, distribution, runtime cycle, support, patching, whatever. And finally, like, retirements upgrade. I mean, this lifecycle, we know, we have figured it out years ago, and there are tools, specific tools and solutions for every step of the process. The only problem really is that it all happens within this closed ecosystem of every vendor. They are responsible for maintaining this lifecycle within their own environment. There is no collaboration. There is no kind of crowd wisdom. There is no regulation that would stipulate reaching out and talking to suppliers of your suppliers and so on. Because this is a huge worldwide ecosystem. So for every piece of software, whether it's open source or proprietary or legacy or whatever, there has to be some kind of a continuous lineage established. So yes, we can, for example, go and ask Microsoft to show their source code. But that's not enough. You have to be able to trace that lineage all the way to some tiny obscure legacy piece of code which survives since the days of whatever, Microsoft Basic from the 70s or 80s. Or maybe it's a third party open source tool which has been abandoned 20 years ago and there's like no patches available, but somehow everyone has forgotten about it. We have to dig deeper. And of course, this is not something which a single software vendor, even of that caliber like Microsoft, can figure out on their own. It has to be a collaborative effort. And the only way to do it is to establish a combination of industry standards and protocols and processes and legislation around the world. Because it's something which we have to do for our own good. Because you know this old joke about if the builders would have built our houses just like software developers developed the programs, the first woodpecker would destroy the entire civilization. This is exactly what's happening in the IT industry level and we have to prevent it somehow. So we have to establish a worldwide woodpecker protection society, I guess.
Yeah, absolutely. Absolutely. So what we have done right now is something that nobody should ever do in a podcast episode. We just laid out the problem statement and we just touched a bit upon the actual solution, but we've done that on purpose. Of course, we want to follow up on that topic and the different aspects and maybe the three dimensions that we mentioned that maybe others in upcoming episodes. And the second thing I want to mention, of course, is that cybersecurity is of course in the DNA of KuppingerCole Analysts and there will be of course, the little tiny block of marketing here, there will be the cyberevolution in early December this year, which is our cybersecurity conference in Frankfurt. And of course, software supply chain risk or software supply chain security is a key topic that should be covered, especially because it incorporates in the end the whole world of cybersecurity encapsulated in software. So it's all in there. So I think we will follow up on that and dig deeper into that. For the time being, what would be the final message? Think it over what you mean by software supply chain security?
First of all, I guess we have to excuse ourselves for not actually delivering any real pragmatic advice, at least not this time. The topic is so huge that we have to start digging somehow and probably talk about more idealistic approaches first. But we have to figure out the actual practical steps for everyone in this, like the governments, the software developers, the end users, the people, because we all have to somehow fix this problem from different perspectives. And I hope that sooner or later we will continue the discussion, maybe with me, maybe with some other analysts who would deliver their own practical views from different perspectives. How do you deal with identities, for example, here? That's a totally huge another story. How do you tackle this whole software development lifecycle and operations, how do you approach it from the compliance perspective, and legal one, regulations and stuff. Yeah, I guess we have a lot of things to discuss even before the cyberevolution and of course if you decide to attend or at least watch it remotely there will be real experts with real pragmatic responses there in Frankfurt. So looking forward to that as well.
Absolutely. And call for speakers is open. If you are the expert, please join us there. Reach out to us and let us know. So I'm quite sure, Alexei, that we will meet again very soon. So I'm really looking forward to having you again covering this topic, covering other topics, but this is a big one anyway, meeting you in Frankfurt later this year. And as usual, if there are any questions, comments, if you think that this is a topic where you can really provide your expertise, please leave your comments when you watch this on YouTube in the YouTube comments and any other way that you can reach out to us. We are easy to find on the internet at www kuppingercole.com and let us know what your thoughts are, where you want to continue that discussion. We are really interested in knowing your position on that. This is not a one-way communication. We are really interested in what your thoughts are. For the time being, thanks again Alexei for being my guest today. And looking forward to having you soon in another episode. See you, bye bye.
Thank you and goodbye.
