Right. Well, thank you very much, Christopher, for the introduction. And again, thanks for all the attendees on, on site and virtual for being here with us. We are continuing the discussion on the zero trust in real life topic, if you will, as a subject. And of course we'll have more detailed, more specialized, more technical presentations further in the strike, but let's just kind of start with a short overview. So supply chain security, what's it all about on one hand, it's really hot buzzword nowadays, like everyone is talking about the supply software supply chain security after those well known incidents, like the solar winds, the CA bridge, maybe even that recent event with the colonial pipeline in the us, which could have led to a massive fuel shortage and panic in the quote unquote real world after a cyber security event. So supply chain security is a very tangible, very real problem, especially even more real nowadays with all the recent events, be it the trade wars with China or the real wars between Russia, Ukraine, or any other tensions around the world.
It all has very real influence on the availability of our products being produced, the cheap shortage, we all know, or food shortage, many people around the world experience. It's all kind of like direct consequences of poor or insufficient supply chain security. So it war real wars are fought about the subject and these wars are continuously going into the cybersecurity software if you will, world as well. So what is software supply chain security? There is so many different and somewhat conflicting definitions. I've chosen one for two small reasons. So supply chain security, software supply chain security, just a set of processes, technologies, and tools to help any company to identify, mitigate, or analyze and mitigate risks associated with any digital artifacts, any software artifacts influence in the real world business processes. And I really wanted to highlight two things in this definition. First of all, software supply chain security is not at all just about open source libraries. There is this per pervasive myth around going around. So yes, it's important, but no it's by far not the biggest risk are in this subject, probably even the smallest one. And the second one is that software supply chain security does not apply just to software vendors because well, even if not every company produces their own software, at least every company uses third party software nowadays. And those third party tools can be just as well compromised, breached used for an attack.
So what are the risks in this area? Well, again, we have to start with the open source libraries because it's the most talked about subject nowadays, and yes, we know that those attacks have increased dramatically recently, one report from the last year list over almost sevenfold growth in those attacks related to open source libraries, lock for shell, probably the most well known nowadays. But again, this doesn't stop here. And those use those cases of solar colonial Microsoft CAA. They show that even the commercial software, any kind of third party software can be compromised and caused your software supply chain risks. Another topic which many people kind of forget to talk about nowadays is this whole politically motivated cyber crime. If you will, activism, protests, where cyber warfare, again, out of some companies, some countries have already learned that hard lessons on their own. Be it almost every it company in, in a country like Russia or Ukraine now, or just even those companies based somewhere else.
But Haven perceived ties with Russian government. For example, the most recent case is, well, if not official band, but like a strong recommendation, not to use any tools from antivirus vendor Kaki, for example. And finally, the last thing, like almost no people talk about regards to software. Supply chain security is legal, the legal landscape. We had the wonderful presentation by mark streams here yesterday. And again, for many people, the vote shrimps two just represent a piece of paper, but he's a real person, a real lawyer from Austria fighting to repel those kind of privacy harm and regulations between EU and the USA, which existed before have been repelled earlier. And to probably be introduced again soon to fail again, sooner or later, because they are completely incompatible with the basic rights here in Europe, though, all those challenges can suddenly apply to you as well.
And you have to start in advance. You have to prepare early to be able to mitigate those risks. And in a sense, okay, I have to click through some animations in a sense, the goal of software supply chain security is very conflicting because we have two parties. On one hand, we have a software vendor who of course claims that. Yeah, of course, they're absolutely interested to have their product completely free of any box and vulnerabilities, but in the end, it's all about compliance and basically covering up your behind against current and potential legal repercussions of a third party company being compromised through your software. On the other hand, we have the actual organizations, businesses who have to protect themselves from any kind of cybersecurity risks, including those from south party vendors. And somehow they have to not just trust those vendors claims. They have to be able to validate and verify those claims.
And in the end, we are slowly going to the magic word trust, which will appear in this presentation and for the presentations many times later today. So from the software supplier perspective, this is basically what they have been doing for years. I mean, or as long as you are developing software, but sell them to someone else or as a cloud service or just for yourself, you have to secure your whole software development lifecycle, starting with a design phase, of course, covering all the dependencies, all the, your own source code infrastructure interfaces like APIs, containers, whatever on runtime monitoring, basically everything around software security is also also applies to software supply chain security, but unfortunately it just does not end there. This is the whole point secure software still does not automatically mean trustworthy software and you have to have additional tools and means in place to be able to demonstrate if your software is secure to the any sort party.
And this is probably like the crux of all the recent developments in this area, because yes, there is this wonderful thing called software bill of materials, for example, which I believe is a really important first step towards this goal to demonstrate that your software is indeed, at least in some aspect trustworthy, but it's definitely just a small first step. It's definitely not enough to cover the whole area. And I believe we will probably observe the growth of additional regulations first to the industry level. And then on the government level, who knows maybe in three or five years or software supply chain security will be the next GDPR.
And from the end user perspective, they actually have the same problems, but they have, they have their own internal security stack. They have to do all those things, which we normally identify in every cybersecurity model. But of course they have to think about not just their own software, but how to secure, procure third party tools, how to deploy them, how to run them, how to operate them securely. But again, for, from the normal business perspective, it's all just about their normal software security. You still have to make an inventory of your software tools. You still have to secure the procurement processes. You still have to deploy the tools properly and securely follow the guidelines, observe the recent developments and threat intelligence. And so on. This is just business as usual, if you will. So what, what, why exactly is this additional thing that hidden add on which everybody's talking about? If you already know how to do all this for years? Like why are we still failing it properly? Demonstrating software, supply chain security? Well, first of all, because it's really complicated. There is this formal approach established decades ago. I, I, I won't even try to go through the slide because it's definitely not my area of expertise. I'm just wanted to show it to it is complicated, involves a lot of parties, processes structures way before you even start thinking in terms of technologies and tools.
So yes, there is a lot of effort involved to establish trust between vendors and businesses. But what if I told you that there should be, there is already an alternative why bother establishing trust when you could just say, I won't trust anyone. And this is exactly where we come to the second magic buzzword of the day zero trust. So yes, and again, you don't have to do anyone trust to, to, to try to, to make everyone trustworthy. You just say, I don't believe you. Or first of all, prove that your software is secure. The SBO is fine, but you have to do more. But even after you show that your software is secure, we still bond trusted. We will only deploy it in our secured isolated area. We will limit lateral movements. We will enforce this privilege, not just for users accessing your software, but also for your software, accessing everything else in our company.
Again, this is by definition, zero trust. And I really had an interesting discussion with Martin Cooper, our boss here at co call. And I felt like, okay, so, so where exactly do these buzzwords overlap? Well, they overlap completely because we are talking about the same thing. It just, we have to refocus our thinking about this from a really high level perspective because the tenures of zero trust are here. We know how to implement them, have lots of practical point implementations in different areas of our internal cybersecurity. We just have to expand the same approach towards software procurement in software operations as well. So yes, zero trust incorporates everything. The idea of zero trust is not limited just to the network or identity or infrastructure or even applications themselves. Zero trust encompasses everything. And it sort of orchestrates our, that they all operate properly and securely in the current.
So where do we start kind of thinking in this terms, practically, obviously we have to start with securing our own software development life cycle. And again, on the left hand, you can say that these are the same technologies through the same approaches, which every software developer already use or at least expected to, to, to, to use. But we have to emphasize that the software development lifecycle does not end at the moment where you basically compile your project and deliver it to a customer. Actually it could have, it starts the second part of the SDLC, the, the life cycle. And this is where the customer, the business has to take over. And again, apply all those technologies, which already exist for how the infrastructure for applying continuous security, intelligence and so on, but they have to do it according to the tenants, according to the architecture of zero trust.
Again, there isn't much to change. It's just kind of the matter of mindset. And we'll probably discuss all those things. The technology technologies involved in tools in the later presentations, where people who are much bigger experts in the subjects than me, they'll show you all the details. I believe my goal is just kind of to, to, to, to make you start thinking about this from a different perspective. And again, kind of zero trust network access probably was already discussed earlier today. And it's like, it's the first thing people usually buy as zero trust. Oops. Yeah. Sorry.
This is how we see zero trust network access implemented nowadays. What should we change in this architecture to actually make it so compatible with software supply chain security, almost nothing. We just have to add a few more errors. We have to ensure that not only users access your applications securely or, or secure network, but also with applications do the same securely when they need to access your infrastructure or data or anything else. So you just have to throw in a few more errors into this diagram and it's basically reusing the same existing technology. You just have to look a little bit more outside of the box and the same,
The same idea applies to cloud as well. So yes, the cloud nowadays is a wonderful vehicle to deliver you the security. The question is who will be watching the Watchman with all those wonderful tools, SA zero trust CASBES and stuff deliver from the cloud. Can you trust them? What else do you need kind of to deploy? What, what do you have to change in the procurement and deployment operations of all these cloud security tools to make sure that not only the cloud secures you, but you also kind of, you secure yourself from the cloud so that you eliminate implicit trust. To be honest, I am not qualified to give you a specific answer to that. I can give you some general observations. So yes, obviously you have to differentiate between clouds who offer you secured by design architecture versus the rest of them. You have to implement those ubiquitous data encryption and masking for every process inside and outside of every cloud.
Maybe you have to consider embedding zero trust somehow as a technology directly into your applications. So if you have a distributed Microsoft based project deployed in the cloud, and obviously every Microsoft have to be operating according to the zero trust approach, but it's, again, this is just a start. There are so many interesting developments happening and you will hear about them in the later presentations as well. This is just kind of zero trust does everything and you have to apply it everywhere consistently. And there is so much more as well on those things are listed on the slide are basically quick win, which you can either deploy or even reuse if you already have them to ensure that everything within your software supply chain operates securely by design even small things like enforcing MFA help. But of course your ultimate goal is to make sure that everything operates automated and orchestrated across all those paths, which lead to your sensitive data or to your critical applications and between them.
And I would like to end with just kind of somewhat funny observation. I believe that zero trust is seen by many people. It's like something radically complicated and different, which you have to rip and replace and spend a lot of effort implementing. I believe no zero trust, basically sway of cybersecurity. You don't have to build a new house to kind of make your energies flow and kind of follow those rules. Maybe you just remove a couple of things or rearrange your furniture or put a nice wave in the corner. So there is always more than one way to reach harmony and zero trust is just kind of general guideline follow those guidelines. They are really easy. There is nothing complicated about them and make sure you reuse as many existing investments as possible. And with that, thank you very much. I.
