Hello, everyone. Welcome to this Cocker Cole webinar, which we are running in co collaboration with duo security. My name's Mike Small, and I'm a senior Analyst at Coppinger Cole. And my co-presenter today will be Richard arch deacon, who is an advisory C I S O at Cisco duo. And the subject today is protecting the business from software supply chain, cyber threats. So starting off with a, a couple of housekeeping issues. First of all, everyone is muted centrally, and there's no need to unmute yourself. The, if you've got any questions, please, will you put them into the question box, which you should find in the go to webinar panel and we'll then work our way through these questions and answer them at the end of the presentations during the session, we will run some polls and hopefully we'll be able to see these and discuss some of the results. Don't worry if you miss something because we are recording the webinar and the recording will be made available within the next 20 hours. And we also provide the slide decks for you to download. So here's our first poll. So do you have any processes in place for any of the following? Do you have a way of defining the risk criteria for different kinds of suppliers, understanding the critical software dependencies and single points of failure, monitoring, supply chain risks and threats, managing suppliers over the whole life cycle of a product or service.
So please will you complete the poll and when that is finished, we'll continue with the webinar.
Okay. So the poll has now been completed. Thank you for taking the time to participate in it. It, so the agenda that we're going to go through today is I'm going to give the Analyst view of supply chain cyber risks. And this will be followed by a view from the industry by Richard arch deacon. And then hopefully we'll have lots of questions from you participants. And we'll attempt to answer these to the best of our ability. So let's get onto supply chain, cyber risks. And in effect, if we go back in history, there was a time when there was a company called Leo, which came from lions tea shops, which was a grouper, which was a restaurant chain in London in the late 1940s, early 1950s. And this chain of tea shops was able to commission not only the creation of the software to run their business, but also the hardware that is not the way things are today.
We are all depending on a complex set of software and hardware, which is needed to run our business. And this comes from a whole set of diverse sources. And this has led to the growth of various risks. Now, some of those risks are to do with the common supply chain problems, and we've all seen this, which the supply chains that were first of all affected by COVID and then by the problems to do with the ship that got stuck in the sues canal. And now we have further problems which are coming from the fact that there's a war in Europe, but in fact, there is also an increasing problem as organizations have become so dependent upon their it, that the chain of supply of that it has in fact, itself becomes subject to cyber risks. And what you can see on here is an extract from the European initial report on the threat landscape for cyber supply chains.
And indeed lots of you will have heard about the solar winds, which was the example, which illustrates the point that if as a, as a cyber adversary, you can break into that supply chain. It gives you an automatic leverage. It gives you an improvement on your performance because you can leverage the supply chain to spread your malware and do your dirty work. Now, this report identifies that 62% of the attacks took advantage of the fact that organizations that are using software are in fact, implicitly trusting in their supplier and not taking sufficient precautions against it. And that 66% of those incidents focused on the supplier's code. So in effect, organizations need to update their view of cybersecurity to take account of the fact that the supply chain or the software supply chain provides a cybersecurity risk.
And so how does this work well in effect how in effect, how an attack will work is this that you depend upon receiving something from a supplier, and this is some kind of a service. It could be software, but it could also be software as a service, or indeed it could even be hardware. And increasingly there are concerns in the world of IOT that the supply of the chips could be compromised now in effect, what the cyber adversary has to do is to attack the supplier. And they will typically do this using one of the various forms, which usually include social engineering, planting, malware exploiting a technical vulnerability, which is then able to give the attacker access to the intellectual property, the development systems and the code base of the software supplier. Now. So when the software supplier then provides the customer with the, the update or the new piece of software, if you have implicit trust in that relationship, then that gives the opportunity for the, for the malware or the impact of the cyber adversaries to impact on your organization.
And that is what happened with the solar winds and many of the other supply supply chain attacks that have been reported in the press. So what can you do about this? Well, the first thing is you really need to understand what your risk is. So risk is not something that is constant. Every organization has their own personal risks. And what is a risk for your organization might not be to say as a risk for another organization. And it's really important for you to understand what your risk is. And you can look at this to begin with, from a couple of perspectives. The first thing is that the applications that you are using come from a whole variety of sources that, although, for example, the solar winds was a, an off the shelf software. You also have your own in-house development and that in-house development is a form of supply chain and attacking your in-house development could have the same effect.
A lot of organizations are outsourcing their development to third parties because they don't have the ability to do the app development that they want. So if you are outsourcing it to a third party, that in turn is a source of risk and a way something that could be attacked. Another major area is open source. And as the log four J thing illustrated that a lot of the software that is widely used is created and maintained by a very small number of pro bono developers. And this in turn leads to a problem. And indeed you may well be using managed services or cloud. And each one of those is a vector. Now that if that were not bad enough, in fact, your business application that you think is the only thing that you are really concerned about in fact is the top of a sort of an iceberg that this will depend upon common services.
And often these come, some may come from the, the actual application vendor, other, maybe ones that are used, and these will use common utilities, which in turn, the whole thing may depend upon a set of standard libraries. And ultimately everything depends upon the infrastructure. And so all of that iceberg, the majority of it is hidden under the application and you, you, each one of those things could potentially be attacked. And each one of those things needs to be trusted. And the reason why it's like that makes perfect sense, because if you are writing an application program, then you don't want to have to write and rewrite all the things that people have written before to do simple things like sort and so forth. And the result of this dependency of course, was the log four J which was a standard utility that was widely used.
Now it's is always a, a temptation amongst cybersecurity professionals to focus on the cyber aspects of the risk. But what I would like to do is to look at this from a perspective of the business, but in effect to talk about where these risks come from, that you can say that the software developers could put back doors into their software. And while I was a software developer, and I know that it was often a temptation to say, well, we might need to maintain this software. So let's actually give ourselves a little way of getting in to see what's happening a software back door. Then you may find that you have malware planted in your software master by the cyber adversaries who have got a, got, got attacked to your systems. And there was the example of that, where effectively, this is what, what happened some years ago when the RSA secure ID was attacked, then during the distribution phase, it could be tampered with, if it goes through some system that allows people to change the components as they go along.
If however, you are using a software as a service, then the service infrastructure could be something that was compromised. And you yourself find yourself, your organization with a problem that if you do not have an understanding of what components you are using, if you are not managing them, then those common components could contain bugs, vulnerabilities, or malware that you're not aware of. And so this becomes a vulnerability management problem as well. And the result of all this in business terms, which is important because this is what allows you to explain to the rest of the business, why you need to spend money and do things is that this could lead to compliance failures, to fraud, loss of intellectual property and destruction of your business, continuity through either making your system ceased to work or denying access through things like run somewhere. So all of these are problems that you need to manage.
And so the key elements of managing this can be fit within the famous N cybersecurity loop, the cybersecurity system, which says, you need to identify what your assets are. You need to protect them. You need to detect risks. You need to respond to them and recover. And so, first of all, the whole of the development process is a risk that you need to manage. And you can only manage if you know what you have. And that means you need to have some kind of configuration management database or a software bill of materials or a component list, which says which libraries, which versions and all the software that you are using, you need to have a procurement process, which means that you assess your suppliers in terms of their riskiness and establish how you are going to manage what those suppliers risks to you are. And indeed, during the deployment of things, you may find that you introduce risks because you don't deploy it in the way that the, the people, the pro providers, the suppliers advised you to do.
And so the supplier will say, well, it's only, it's only secure if you use the deployment approach that I've told you about. And then finally you need all of the systems to do with vulnerability assessment. And at this point, we're not just looking at vulnerabilities in the, the, the infrastructure, but you also need to be aware of the fact that during code and incoding, you can introduce, you can introduce vulnerabilities things like cross cross site scripting. And for example, sequel injection are things that should have been developed should have been dealt with at the development phase. But you, if they aren't, you need to be able to make sure that your process is capable of detecting them now, who is responsible for this. And one of the challenges is that there is a division of responsibilities and you need to take account of this so that you understand who is responsible for what the supplier is responsible for the things to do with stuff you can see on the left, the coding errors, making sure that the software master is protected, providing a distribution system, which is capable of being proven to deliver the software that it it's expected.
And if they are providing a service infrastructure, that that is in fact, something that they provide, there is a shared set of responsibilities that the, the software supplier should be removing those vulnerabilities that they can, but you also need to be aware of everything that's that's provided. And often there is some kind of a, a breakdown in communications that if a, an off the shelf software depends upon some open source who is responsible for that. And often this is not clear. And it's really important that you clarify with your supplier who is responsible for the versions of those things. And then finally your responsibility is for deployment and making sure that it is correct configured properly. And the whole service that you are using is configured correctly. And this really boils down to the fact, the two words that matter are ensure and ashore. You need to ensure that you meet your responsibilities and assure that the supplier meets theirs.
And in, in basically this means that you need to understand what your risks are, which systems, which data, what the risks to those things are that you then specify appropriate levels of security for those things, where you are developing software yourself, that you use appropriate secure development life cycle methodologies, that you have a catalog of software dependencies. You understand what software you have and what it depends upon that you implement secure configuration of your systems and that you manage your vulnerabilities. Now, from the point of view of the suppliers, you need to assure that the suppliers meet theirs. And so that could be done through auditing the vendor through asking the vendor to provide independent certification for making sure that the vendor will specify what their sub sub dependencies are. Their subcontractors are that they identify any open source content, and that they make sure that their contractual clauses are clear about what and who is responsible for what?
So in summary, these are some of the kinds of things that you should be looking for from your perspective. This software composition analysis is important to be able to show you understand the, the dependencies you have, that you are properly scanning what you have for vulnerabilities to remove them, and that you are managing your security posture. Now, in terms of assuring the suppliers and their products, the steps that you can take throughout the life cycle include that you should make sure that your procurement processes take account of this, not just cost that you screamed of. You look at where they are. You look at how they look after their staff, how they employ their staff, what certifications they have, what kinds of agreements they have at their own supply chain that you can look for independent certification of that processes, whether they comply with standards like ISO 27,001, whether their people are properly certified, and whether they, they will submit their software for evaluation under what was used to be called common criteria, which is now ISO 15, 4 0 8.
And from the point of view of independent certification of software, as a service look for all of these different kinds of certifications. So with that, we can say that supply chain or supply chain provides a significant cyber risk and vendor security will impact on your security. And that there is this application iceberg, which leads to there being complex dependencies that you may not be aware of. You need to identify your risks and set appropriate requirements for the security to deal with these and consider these risks. When you are selecting the vendors that you then need to make, ensure that you meet your responsibilities and assure that the vendors meet theirs. So that is my part of the presentation. And we now come to the second poll. So in this poll, we are asking you, what capabilities do you already have in place? Proactive technology, refresh process, a well integrated technology stack. Do you have a timely incident response process from disaster recovery? And do you have accurate technology threat department de detection? So we'll give you a few mean moments to respond to this, and then we will pass on. So thank you for taking the time to respond.
Thank you. So thank you very much for responding to this. So the next step of this webinar is the term Richard arch deacon, who is the advisory C I S O of Cisco duo. Security is going to give his perspective from the industry. And at this point we will hand over control to Richard.
Thank you very much, Mike, for that, that interesting introduction. I hope you can all hear me and that you can now see me and apologies for that problem with getting, getting off mute. First of all, I'd like to thank Mike for his introduction in which he went into quite a bit of detail. I'd also like to thank him for referring back to Leo, which was of course, the first commercial use of computing in the world. And it always amuses me that the first company to use a computer, I think it was for payroll calculations was the 1940s equivalent of Starbucks. Very strange, but that is, that is a brilliant story. So thank you for bringing that up, Mike. So what I'd like to do is talk a little bit about how we are looking at this supply chain industry and relate some of the conversations and concerns I'm having with CSOs.
I'm an advisory CSO. I'm part of our strategy group. And my role is to try and understand the trends in security and see how best we can work with C as to make their lives better, easier, and make CSO successful. So what I'd like to do is, is talk about a number of topics. One is, is why we think this is a concern, put it in context of overall supply chain. Talk about software builds and material, which I think is something we have to focus on and then see how we respond with some form of programmatic approach.
I'd like to start off with this quote, which is one that I got from a, a seaside I've known for many years, whose was head of security, risk and compliance in one of the big Swiss financial organizations, household name. And I always thought that this was really quite an interesting observation that we could learn to trust immediate suppliers, but beyond them, we need to. And that's because we can't see what is going on beyond our immediate suppliers, not only to ordinary suppliers that we deal with, whether that's a software or services or people, but just generally, but also specifically to those who are going to be providing us with software. So I think that's what we have to bear in mind. How do we deal with the, not the immediate supplier, but the one beyond that. And that could well be the concern of the CSO. And I think Mike came up with very many very good examples.
So I'm some, one of the polls. Then you'll why we put this. We did a survey of over five CSOs around the world. It was an anonymous survey and we asked them what made the most important change to their organization. And if we looked to the left, I'm not going to go through this chart because it's a lot of detail, but where it's blue, it says that's where we'll get the best margin and improvement in securing our organizations. So this was for the CSOs around the world. They said, this is really where we need to improve in order to get better benefit. And as you can see, there's the tech refresh, integrated tech, and then the response in recovery. And I think that this brings out a number of really important points. One is the drive towards constantly refreshing our technology and making sure it's integrated.
So bringing together technologies from different areas, as well as being able to respond more quickly. And I think this goes in with the theme that we're talking about today, and that we will have this constant churn of new technology coming through updates the whole time, as well as more complex integration going through by third parties, it's too difficult for CSOs to integrate all the solutions they have. They need to have them integrated by others. And so there's going to be this other aspect of joining together often using third party software and software, that's beyond the first level of your partnership. So this is I think, where we look at the benefits of what's the changes that are going on in the world of security, but also we have to try and understand what the impact will be when we start look at this change of software.
One other fact, which really very interesting rounds and this research is available is looking at visibility over systems and maintaining business continuity. And remember, this is not our data. This is the data from CSOs around the world. And what you find is that there's a huge move upwards when CSOs get to see more than 80% of their assets, this of course sounds like common sense. If you can't see something, if you have no visibility, how do you control it and how do you manage it and how do you put around the recovery requirements and how do you make sure it doesn't have the vulnerabilities that are to impact on your organization? We know that, but what I thought was surprising was this percent figure where or more is where you really start to make a marginal difference. So it's that visibility and over all of our assets and which we're one element, greater visibility and greater ability to react and control is very important.
Mike mentioned various standards that are around, and I think we've got the, the, the next one, which I brought up here, which looks at cyber risk in supply chain management. And I always like to start off with a standard for two reasons. One is that it gives us guidance as to what we need to do to make our organizations more secure. And secondly, it gives us guidance as to what questions might be asked about us by other parties. And so if we look at some of the, the key recommendations and, or, or observations on this, this standard, it mentions around knowing your critical suppliers and the supply chain, but also looking into key suppliers in terms of the resilience of your organization, how your organization will be impacted and how to build up collaboration with those key suppliers. So this is not a one off relationship with suppliers.
We have to work on this together in order to make sure that we can support the resilience of the organization. And as I think me like me today, we've got plan for the life cycle of this. This is not a one off activity it has to continue on. So we also have to establish this as a formal program within the organization, not the reaction to an incident. This has to be embedded into not only the way we manage security, operationally, our continuity, our resilience, our SLDC. It has to be put in across the whole organization, how we understand the dependence we, we have on the different components of the software that's coming into our organization.
But at the same time, we've got to remember the basics because what we're talking about now is going to be just one element of our security. And what I've just done here is I've used something from the world economic forum, which gives 10 principles that we need to look at. And one of these, these principles is the whole idea of supply chain management and making sure that you're adopt a zero trust approach. That means making sure you control access into your software or any of your assets from third parties. So maintaining that authentication, making sure that you have content driven authentication in order to bring about tighter control over third parties. And I've seen this in my past experience in years gone by on that simple plant maintenance type of activity. If you had an open kind access in what could happen, if the credentials were compromised, this applies to software as much as anywhere else. And so we have to make sure that we still carry through the basics that we need around security and that we still control access to all of our, our resources from third parties, especially around our software. So adopting the zero trust aspect is still very important for what we set up to do.
So we've discussed a number of factors there we've discussed, or I tried to discuss why it's important and why it's becoming significant and why CISOs are worried about it. And I know Mike mentioned a lot of the attacks, but I think that we can see that it's also a fundamental part of our business and the resilience of our business and our ability for our business to change and manage software updates and uni integrated solutions because the, the organization is going to demand them more and more. One of the topics that is becoming now talked about a lot is this idea of the software bill of materials, about how we understand what is in our software when it gets supplied to us. So if we just sort of talk about what might well be in the software bill of materials, these are referred to as S for one of a better expression.
So first of all, why do I think they're going to become important last year? I think it was during may an executive order was issued by the us government for organization supplying the federal government. And I think that where that kind of standard or requirement gets published. So the rest of the industry starts to, and it was the executive order you reading through it. I picked various requirements coming and in that they start to look at guidance, standards, procedures, or criteria around a number of factors, how to trust the codes, the source code, the supply chain. So it's now becoming really front and center's demand government for potential vulnerabilities so that you looking for those gaps and also providing software bills and material for any of the products, either by giving it to them directly, or by putting it on a public website and having these vulnerability disclosure programs.
Now we're used to vulnerability disclosure disclosure programs. We've had Microsoft Tuesday for years, but I think what I thought was interesting about this was this idea of publishing software builds and material, and making them open to organizations so that they can see and understand exactly what they need in order to maintain the security of their, their software. So giving details to the organization of what is in your software. So we can see this as becoming really a requirement going forward. So from the industry point of view, this is going to be, I think, an increasing obligation upon us.
So what is a software bill of material? This is some of the art art way of looking at it. It's, it's going to be some kind of artifact, which you can identify it as being part of the, the technology environment and software that you bring in. But it's not going to just be one item. It's going to be a whole series of different artifacts that come together, pieces that come together in order to create the, the picture that you need to have. So it's almost like those picture puzzles. How do you bring all those different pieces together? And each of those different pieces will have what we call a metadata, which will be data about it, so that you can identify the important elements such as who supplied component. That will us a better ability to what we have with our environment.
And I show you an example at Cisco, we do, we publish these openly go federal requirement, executive order. We've put these on a website you at download. And our new initiative is to look at SBOs, which will go through the six stages that I mentioned. They generate validate side share, but in a binary format. And this is where we think the future is going. You can download these anyway, but how do we actually get them in a, that is consumable in an easy way that will enable you to apply them in your organization. So if we just look at this, I took one sample there of, of what, what they call open source in one of the, any connect products. Again, you can go and look at this, it's openly vague. And I took out the table of contents and you can see it has about 33 different component pieces that you wanted, that you need to look at.
And this, I show you was one of the smaller ones. There were much, much bigger ones. So you now have the details that you need in order to understand that piece of software, but you then have to start to look at it in more detail. So what happens next? Well, to sort of reiterate some of the elements that Mike was mentioning, you get the, these software bill of materials. You then have to look at your exposure, whereas is it within your overall environment? And I think Mike pulled out the fact that it could come from many different environments, your software, whether it's cots, inhouse card, whatever it is. And so do you have a proper inventory of that? And this is you could argue as basic issues for cybersecurity professionals. How do we know what we've got, whether applications or devices or data it's always been an issue in almost every company organization I've to then the risk element, what risk does it pose and what risk is there to this particular vulnerability?
Is there some form of attack out in the world or not? Is it on one of our extremely important applications or not? And then as I think Mike also pointed out, where does it all fit together? Where does it fit in terms of the stack? Some of it might be on your hardware might be a third party app, your own application. So for example, you might have an SS component and you can have different SSL components in each of those layers of how do you identify, how do you identify, which needs to be remediated? So there's a lot about context and context is key, or context is key defined the context, then patching it, what really needs to be patched. And as Mike mentioned, is it our responsibilities? It, the vendor responsibilities. I a very clear that very important what's full vulnerability businesses. You can't just patch VE across a patch patch straight away. It's always far more complicated, so of partial.
And if we look at our supply chain, do we have full logs on what each version of the component was, where it was used and between dates. So we have to understand those logs as well. So there's a lot about recording that data that we've got on our own environment and then matching against the vendor environment and understanding the components they're used exploit these context and the action. So we are looking at software bills and material. How do we distribute them more effectively? They distributed now you can get of, but so incorporate into organization are vendors are working on standards to, and that across finally, I just wanted to refer back to the recent log for J vulnerability. And Mike mentioned this and our chief risk officer was cool before the Senate to did a very good briefing and the very positively, but one of the points he made is that whilst bills and materials are part of what we need for the assessment and risk conversation, we're not the only, that's not the only solution.
We all have to go back to making sure we have zero trust environments and SDLC done, and proper code reviews and structured code reviews periodically, depending upon risk. So just one component in we anywhere to start. I think what we should try and do is, is to start to put together a program, put together a program, which sets the standards, understands where we need to, to work, understand the businesses and operating model. Look at basic hygiene, make sure we got our cyber hygiene, right? Look at our standards correctly, make sure we got the, identify the right components, then try and look at what incidents might happen and then work with third parties. And this doesn't just to software in case just a summary to out a summary, we have what resilience means to the organization. And we have to identify with stakeholders across the organization. We understand. So we understand the, our third parties, know the components and make sure that our, our basics are in place. The basic cyber hygiene treated as a program and all context is key. So those, those are some of the, the, the thoughts that I've would like on deck links, where you see some of listening to, to you, Mike.
Okay. Thank you very much. Indeed. Richard. So that was very interesting. So now we're going to have the final poll, which is, do you have established channels for the following internal it security communications around software dependencies, external communications with suppliers around software risks and so to soft communications with critical software suppliers. So this poll is now open. So we are be very grateful for you to take time to, to respond to this. So I believe we've now finished that poll. So now we're coming to the questions and answers part. Now I'm hoping that we, we might get some, some feedback from the polls, but Oscar will, will let us know about that. So we can see that we are sharing the poll results. Right. Well, I'm not sure what time. Okay. So I, do you have any comments on those Richard?
I think there was an even split wasn't there between looking at suppliers, but there was no, there was very little in terms of the interactive working with suppliers on this, this next poll. I think that we're looking at probably a few and even split across the top three issues around technology refresh into the greater technology and response. But I think that people are, are looking more at needing to focus on disaster recovery processes, which is when everything does go wrong. How do you actually fall back to your whole new environment? How do you bring in a new complete software stack for example, to keep running. But it is interesting to see that this whole issue of constantly upgrading technology and keeping it refreshed to see as being part of what people are doing, but only about a third of people. And we see this increasingly in becoming almost the norm going forward. So we'll have to understand and manage that, especially as it's seen as being one of the ways to improve security and get the best module to. So that would be my response to that.
Yes, that's fascinating. So it's really your, your, your, your survey that was run by Cisco was really very interesting that the top thing was about technology refresh. And I don't think people would have realized that that was so important.
Yeah. Important in terms of giving you the margin best module increase in security. That's what we're looking at. If you want improve your security, look at that area.
Yeah, yeah. That, that's interesting. So we've now got some questions and the first question, which has come from Al LA Carney, why is that their talk about zero trust, but when it comes to authenticating, businesses are expected to blindly trust their identity provider. I'm not really sure to what extent this is related to supply chains, but in a sense, an identity provider is a kind of a supply chain, I guess. So is that something you have an opinion of?
I always look at security being about only making sure the right people access your right assets. If we get it down to that, we really we've really got security. It's very difficult. Zero trust enables us to do more than that. And authenticate people who have been given the rights to access through some form of IDP. I think we've gotta remember identities can be compromised, whether it's at the IDP level or elsewhere, and the old idea of the name and password now being proof of who you are, is I think being seen now is not really that, that significant because so many passwords get compromised and so many user properly. So even if you have all of that running perfect, you still need to have that better authentication, not just only what the user level, but around the context as well, when and where people are logging into and then restricting what they log into. So I think that that the zero trust approach always goes to minimize risk by steps, by reducing the easy and open access and what might be. So that's where I think that zero trust fits it.
Yeah. I think there is so much talk of zero trust. It's almost worth bringing that out again. So zero trust is often described as never trust, always verify. I think that really applies to the supply chain and the cyber supply chain. What, what's your view of this Richard
Forum you've would go with that within the strongly authenticated access that you limit, where third parties can come in and that you make sure that wherever possible you validate them by using a broader context. So for example, if you have somebody and I'm just talking now, generally, in terms of the supply chain, if you have a supplier who comes in to update some of your equipment or update some of your software or something like that, make sure you restrict what they can do, where they can go and who they are. So I think it is absolutely fundamental. I think it's also a very positive enables to think a lot more about how we can open up the organization to specific trusted suppliers in order to support and make the go the organization more resilient. And I'm seeing, for example, in the security environment where CSOs are actually outsourcing a lot of their security functions to other parties, because they can't get the resources and they can do the security because they're adopting the zero trust approach. So it's giving them more flexibility. It's actually improving the business cause they get more and better security people. So there's some very practical reasons why we should adopt it and not only around just updating our software and making, making sure those who work on our software come and control, but also just generally with all suppliers, will we throughout.
Okay. Thank you. Well, you, you made a point about software bill of materials, and I'd also mentioned this, is that where you think an organization should start. Do you think they've all got software bills of material? What, what's your view on this?
I, I think that with software getting so complex, and I think you brought out the multiple different, different component pieces that might well be in the software. I think we're seeing a drive towards this, both of them being provided. And I gave examples about how we publish these software bills, materials. So people can go and get hold of them. And I think being transparent is very important, but how we're also working through to try and, and there's no standard on this yet by how to distribute them in a binary format so that people can ingest them into some form of analysis tool more easily. So I think that we're, we're at a stage where we do have them, people can get them, but I think there's going to be further development going on that we need to watch this space and we need to have to marry that at what we're doing in terms of our SDLC and understanding how we maintain our, our software and get a full, full observability across all those different components. So we can immediately react. Should there be any vulnerability or make a considered reaction. So to go back to, to that, that, that slide ahead where context is key, we've got the SBO, you have to understand the context, we're gonna get them fed in, in different ways. We've gotta understand the context. So I think that's, that's the important factor.
Okay. So I think one of the, one of the big benefits of a, a webinar like this is for people to be able to take away a clear action plan. So what would you say is the thing that everyone should do, having listened to this webinar? What's the top sets of actions that you think they should take?
I think it's, it's to establish a programmatic view view. I tried to, to, to bring this out, to put out the different steps, understand the organization, set up some standards, make sure you've got the basic hygiene and start to understand your components and then work out how you would respond in the case of an incident. So my, my, my first step would be step back, see where you are and see how you're going to create an ongoing program and not be, not be reactive about this. Once you've got the program in place, you can start to become proactive and make your organization I'm a little bit more secure. So that's how I would do it. Start a program, look at from end to end. Don't just try and be reacted to whatever's happening now.
Yeah. Okay. Have a program. Don't just be reactive. That's good advice. Now I see that there are no more questions. So if anybody else has a burning question, please, will you feed it in through the chat? And if I don't see any questions in the immediate future, then I think we will have come to the end. So I think that's really been a very interesting perspective on software supply chain, cyber risks, and what organizations should do about it. And we've had some really excellent input from Cisco J from Richard arch deacon. And I'd like to thank Richard very much for his thoughts and his inputs. And thank everyone for participating in this webinar. And with that, I'll say thank you very much to everyone. I wish you the best for the future and come to the next webinar and attend our conferences that you have seen advertised. Thank you very much, everyone. Thank you, Richard.
