(upbeat music) >> Welcome to theCUBE. I'm Dave Nicholson, and this is part of the continuing conversation about Managing Risk in the Digital Supply Chain. I have with me today Vincent Danen, vice president of product security from Red Hat and Luke Hines security engineering lead from the office of the CTO at Red Hat. Gentlemen, welcome to theCUBE. >> Thank you. >> Great to be here. >> So let's just start out and dive right into this, Vincent, what is the software or digital supply chain? What are we talking about? Yeah, that's a good question. Software supply chain is basically the software that an end user would get from a vendor or in our case, we're talking about open source, so upstream. It is the software that comes in that is part of your package, operating system, applications. It could be something that you get from one vendor, multiple vendors. So we look at in the example of Red Hat, we are one part of the customer's software supply chain. >> So it's interesting that it's coming in from different areas. Do we have a sense for the ratio of kind of commercial software versus open source software that makes up an enterprise today? >> I think that's a really hard thing to answer and I think every enterprise or every company would have a little bit different. Depends if you have an open source vendor that you choose, you may get a significant amount of software from them. Certainly you're not going to get it all. As an example, Red Hat provides thousands of open source packages. We certainly can't provide all of them. There are millions that are out there. So when you're looking at a specific application that you're building, chances are, you could be running that on a managed platform or an enterprise supply platform, but there are going to be packages that you're going to be obtaining from other sources in other communities as well in order to power your applications. >> So, Luke, that sounds like a kind of a vague situation we're looking at in terms of where all of our software is coming from. So what do we need to know about our software supply chain in that context? What do we need to understand? Before we even get anywhere near the idea of securing it, what are some of the issues that arise from that? >> Yeah, so Vincent's touchpoint is a very wide range in ecosystem, multiple sources when we're talking about open source. So essentially awareness is key really. I think a lot of people are really not aware of the sources that they're drawing from to create their own supply chain. So there's multiple supply chains. You can be somebody like Red Hat that the provide software, and then people will leverage Red Hats for their own supply chain. And then you have the cloud provider and they have their own source of software. So I think that the key thing is the awareness of how much you rely upon that ecosystem before we look at the security of the supply chain. It's really understanding your supply chain. >> And just to follow up on that. So can you... I'm sort of checking my own level of understanding on this subject. When you talk about open source code, you're talking about a code base that is often maintained essentially by volunteers, isn't that correct? >> A mix of volunteers and paid professionals where a company has an interest in the open source project, but predominantly I would say it's... Well, I'm not entirely sure, but volunteers make up a substantial part of the ecosystem that is for sure. So it's a mix really. Some people do it because they enjoy writing software. They want to share software. Other people also enjoy working software, but they're in the position that a company pays for them to work on that software. So it's a mix of both. >> Vincent, give us a reminder of reminder of why this is important from a little bit of a higher level. Step back from the data center view of things, from the IT view of things, just from a societal perspective, Vincent, what happens when we don't secure our digital supply chain? What are the things that are put at risk? >> Okay, well, there's a significant number of things that are placed at risk, the security of the enterprise itself. So your own customer data, your own internal corporate data is place at risk if there were a supply chain breach. But further to that for a software provider, and I think that in a lot of cases, most companies today are software providers or software developers. You actually put your own customers at risk as well, not just their data, but their actual... The things that they're working on, any workloads that they may have, an order that they might place as an example. So there's a number of areas where you want to have the security of that supply chain and the software components that you have figured out. You want to be on top of that because there is that risk that trickles down when it comes to an event. I mean, we've seen that with breaches earlier this year, one company is breached multiple companies end up being breached as a result of that. So it's really important. I think we all have a part to play in that I always view it as it's not just about the company itself. So I mean, speaking from a Red Hat perspective, I don't look at it as we're just securing Red Hat, we're securing our customers, and then we're also doing that for their customers as well, because they're writing software that's running on the software that we're providing to them. So there is this trickle down effect that comes, and so I think that every link in that chain, I mean, it's wonderful that it's called a supply chain. It's only as strong as its weakest link. So our view is how do we strengthen every link in that chain? And we're one part of it, but we're kind of looking a little broader, what can we do upstream and how can we help our customers to ensure the security of their part in that supply chain? >> Yeah, I want to talk about that in a broad sense, but let's see if we can get a little bit more specific in terms of what some of the chains look like because it's not just really one chain when you think about it, there's the idea of inherent flaws that can be caught and then there are the things that bad actors might be doing to leverage those flaws. So you've got all of these different things that are converging. So first and Vincent, if you want to toss this to Luke back and forth, it's up to you guys. What about this issue of inherent flaws in code? We referenced this idea of the maintainer community. What are best practices for locking that down to make sure that there aren't inherent flaws or security risks? >> I'll take a stab at it, and then I'll let Luke follow up with maybe some of the technologies that Red Hat provides. And again, speaking to Red Hat as part of that chain. When we're talking about inherent risk, there's a vulnerability that's present upstream. We pull that software to Red Hat. We package it as a component of one of the pieces of software that we provide to our customers. It's our responsibility to pay attention to those upstream potential vulnerabilities, potential risks, and correct them in our code. So that might be taking a patch from upstream, applying it to our software, might be grabbing the latest version from upstream, whatever the case might be, but it's our responsibility to provide that protection for that software to actually remediate that risk, and then our customers can then install the update and apply the mitigation themselves. If we take a look at it from, when we're looking at multiple suppliers where you'd asked earlier about, what part of it is Red Hat and what part of it is self-service open source? When you look at that, the work that Red Hat's doing there as a commercial provider of open source and end user for that little bit that they're going to grab themselves, that Red Hat doesn't provide, it's going to have to do all of those things as well. They're going to have to pay attention to that risk from upstream. They're going to have to pay attention to any potential vulnerabilities and pull that in to figure out, do I need to patch? Where do I need to patch it? And that's something we didn't really touch on was an inventory of the software that you have in place. I mean, you don't know that you need to fix something. You don't even know that it's running. So, I mean, there's a lot of considerations there where you have to pay attention to a lot of sources. Certainly there's metadata, automation, all of these things that make it easier, but it doesn't absolve us of the responsibility across the board to pay attention to these things, whether you're grabbing it from upstream directly or from the vendor. And it's the vendor's responsibility to then be paying attention to things upstream. >> Yeah, so Luke, I want you to kind of riff on that from the perspective that let's just assume that Vincent was just primarily talking about the idea that, okay, we've established that this code is solid and we've got gold copy of it and we know it's okay. There aren't inherent problems in the code as far as we can tell. Well, that's fine. I'm a developer. I go out to pull code and to use. How do I know if it's not been tampered with? How do I know if it's in fact the code that was validated during this process before? What do you do about that? >> So there's several methods there, but I just like to loop back to that point, because I think this is really interesting around, so if you look at a software supply chain, this is a mix of humans and machines, and both have flaws, probably humans a bit more. And a supply chain, you have developers. You have code reviewers, you have your systems administrators that set up the systems, and then you have your machine actors. So you've got your build systems, the various machines that are part of that supply chain. Now the humans, there's a as an attack factor there 'cause typically they will have some sort of identity, which they leverage for access to the supply chain. So quite often a developer's identity can be compromised. So a lot of the time people will have a corporate account that gives them some sort of single sign on access to multiple systems. So the developers are coming and this could be somebody in the community as well. Their account is compromised, then they're able to easily backdoor systems. So that's one aspect. And then there is machines as well. There's the whole premise of machines software not being up to date. So when the latest nasty vulnerability is released, machines are updated, then the machines have their flaws. They can be exploited. So I would say it's not just a technical problem. There is a humanistic element to this as well around protecting your supply chain. And I would say a really good perspective to carry when you're looking to, how do I secure my supply chain is treat it like you would a production system. So what do I mean by that? When we put something into production and we've got this very long legacy of treating it with a very strict security context around who can access that people, okay. How much it's upgraded and it's patched? And we seem to not have this same perception around our supply chain and our build systems, the integrity of those, the access of those, the policy around the access and so forth. So that's one giveaway that I would say is a real key focus that you should have is treat it like a production system. Be very mindful about what you're bringing in, who can access it because it is the keys to the kingdom, because if somebody compromises your supply chain, your build systems and so forth, they can compromise the whole chain because the chain is only as strong as the weakest link. So that's what I draw upon it. And around the verifications, there is multiple technologies that you can leverage. So Red Hat, we've got a very robust sign in system that we use so that you can be sure that the packages that we get you have non-repudiation that they've been produced by Red Hat. When you update your system, that's automatically looked after. And there are other systems as well, there's other new technologies that are starting to get a foothold around the provenance of aspects of your build system. So when you're pulling in from these multiple sources of open source communities, you can have some provenance around what you're putting in as well. And yeah, I don't want to bite share too much on the technologies, but there's some exciting stuff starting to happen there as well. >> So let's look at an example of something, because I think it's important to understand all of these different aspects. Recently, I think actually still in the news, we found that some logging software distributed by Apache that's widely used in people's websites to gather information about... To help from a security perspective and to help developers improve things that are going on in websites. A vulnerability was discovered. I guess, first Alibaba, some folks were reported it directly to some folks at Apache and the Apache Organization. And then of all people, some folks from Minecraft mentioned it in a blog. That seems like a crazy way to find out about something that's a critical flaw. Now we're looking at this right now with hindsight. So with hindsight, what could we have done to not be in the circumstances that we're in right now? Vincent, I'll toss that to you first, but again, if Luke is more appropriate, let us know. >> No, it's a great question, and it's a hard question. >> How did you let this happen, Vincent? How did you let this happen? >> It wasn't me, I promise. (Dave laughs) >> What I mean, it's a challenging question I mean, and there's a number of areas where we focused on a lot of what we perceived as critical software. So it comes to web server applications, DNS, a number of the kind of the critical infrastructure that powers the internet. Right or wrong. Do we look at logging software as a critical piece of that? Well, maybe, maybe we should, right? Logging is definitely important as part of an incident response or just an awareness of what's going on. So, I mean, yeah, it probably should have been considered critical software, but I mean, it's open source, right? So there's a number of different logging applications. I imagine now we're scrutinizing those a little bit more, but looking beforehand, how do you determine what's critical until an event like this happens, and it's unfortunate that it happens. And I like to think of these as learning opportunities, and certainly not just for Red Hat, but for this (talking over each other) >> Certainly this is not... Yeah, this is not an indictment of our entire industry. We are all in this together and learning every day. It just highlights how complex the situation is that we're dealing with, right? >> It really is. And I mean, a lot of what we're looking at now is how do we get tools into the hands of developers who can catch some of these things earlier. And there's a lot of commercial offerings, there's a lot of open source tools that are available and being produced that are going to help with these sorts of situations moving forward. But I mean, all the tools on the planet aren't going to help if they're not being used. So, I mean, there has to be an education and an incentive for these developers, particularly, maybe in some upstream communities where they are labors of love and they're passionate projects they're not sponsored or backed by a corporation who's paying for these tools, to be able to use some of them and move that forward. I think that looking at things now, there is work to be done. Obviously there's always going to be work to be done. Not all of these tools, and we have to recognize this, they're not all perfect. They're not going to catch everything. These tools could have been... I mean, I don't know if they were running these tools or not, they could have been, and the tool simply could not have picked them up. So part of it is the proactive part. We talk a lot about shift left and moving these things earlier into the development process and that's great, and we should do it. It certainly should never be seen as a silver bullet or a replacement for a good response. And I think the really important thing to highlight with respect to this, and I mean, this touches on the supply chain issue as well, companies, especially those who never maybe saw themselves as a software development company really have to figure out and understand how to do appropriate response. Part of that is awareness, what do you have installed? Part of it is sources of information. Like how do I find out about a new vulnerability or a potential vulnerability? And then it's just the speed to respond. We know that a number of companies they have, maybe it's a Patch Tuesday, maybe it's a patch 26th of the month, maybe it's patch day of the quarter, we have to learn how to respond to these things quickly so that we can apply these mitigations and these fixes as quickly as possible to them protect ourselves and protect the end users or customers that we have, or to keep the kids from using some backdoors in Minecraft is the word. >> (laughs) Yeah. Look, this is an immensely important subject. To wrap us up on this, Luke, I'd like you to pretend that you just got into an elevator in a moderately tall building, and you have 60 seconds to share with me someone who already trusts you, you don't have to convince me of your credentials or anything. I trust you. What tools specifically do you need me to be running, tools and processes. You've got 60 seconds to say, Dave, if you're not doing these things right now, you're unnecessarily vulnerable. So ready, and go, Luke. >> So automatically update all packages. Always stay up-to-date so that when an issue does hit, you're not having to go back 10 versions and work your way forward. That's the key thing. Ensure that everything you pull in, you're not going to have 100%, but have a very strict requirement that there is non-repudiation, is signed content, so you can verify that it's not being tampered with. For your developers that are producing code, run static, dynamic analysis, API fuzzes, all of these sorts of tools. They will find some vulnerabilities for you. Be part of communities. Be part of communities, help chop the wood and carry the water because the log for Jay, the thing is that was found because it was in the open. If it wasn't any open, it wouldn't have been found. And I've been in this business for a long time. Software developers will always write bugs. I do. Some of them will be security bugs. That's never going to change. So it's not about stopping something that's inevitable. It's about being prepared to react accordingly in our right and correct manner when it does happen so that you can mitigate against those risks. >> Well, we're here on the 35th floor. That was amazing. Thank you, Luke. Vincent, you were in the elevator also listening in on this conversation. Did we miss anything? >> No, I mean, the only thing I'll say is that it's really helpful to partner with an enterprise open source provider, be it Red Hat or anybody else. I don't want to toot our own horn. They do a lot of that work on your behalf that you don't have to do. A lot of the things that Luke was talking about, those providers do, so you don't have to. And that's where you.. I liked that you talked about, hey, you don't have to convince me that I'm trusted, or that I trust you. Trust those vendors. They're literally here to do a lot of that heavy lifting for you and trust the process. Yeah, it's a very, very good point. And I know that sometimes it's hard to get to that point where you are the trusted advisor. Both of you certainly are. And with that, I would like to thank you very much for an interesting conversation. Gentlemen, let's keep in touch. You're always welcome on theCUBE. Luke, second time, getting a chance to talk to you on theCUBE personally. Fantastic. With that, I would like to thank everyone for joining this very special series on theCUBE. Managing risk in the digital supply chain is a critical topic to keep on top of. Thanks for tuning into theCUBE. We'll be back soon. I'm Dave Nicholson saying, thanks again. (upbeat music)

(upbeat music) >> Welcome to theCUBE. I'm Dave Nicholson, and this is part of the continuing conversation about Managing Risk in the Digital Supply Chain. I have with me today Vincent Danen, vice president of product security from Red Hat and Luke Hines security engineering lead from the office of the CTO at Red Hat. Gentlemen, welcome to theCUBE. >> Thank you. >> Great to be here. >> So let's just start out and dive right into this, Vincent, what is the software or digital supply chain? What are we talking about? Yeah, that's a good question. Software supply chain is basically the software that an end user would get from a vendor or in our case, we're talking about open source, so upstream. It is the software that comes in that is part of your package, operating system, applications. It could be something that you get from one vendor, multiple vendors. So we look at in the example of Red Hat, we are one part of the customer's software supply chain. >> So it's interesting that it's coming in from different areas. Do we have a sense for the ratio of kind of commercial software versus open source software that makes up an enterprise today? >> I think that's a really hard thing to answer and I think every enterprise or every company would have a little bit different. Depends if you have an open source vendor that you choose, you may get a significant amount of software from them. Certainly you're not going to get it all. As an example, Red Hat provides thousands of open source packages. We certainly can't provide all of them. There are millions that are out there. So when you're looking at a specific application that you're building, chances are, you could be running that on a managed platform or an enterprise supply platform, but there are going to be packages that you're going to be obtaining from other sources in other communities as well in order to power your applications. >> So, Luke, that sounds like a kind of a vague situation we're looking at in terms of where all of our software is coming from. So what do we need to know about our software supply chain in that context? What do we need to understand? Before we even get anywhere near the idea of securing it, what are some of the issues that arise from that? >> Yeah, so Vincent's touchpoint is a very wide range in ecosystem, multiple sources when we're talking about open source. So essentially awareness is key really. I think a lot of people are really not aware of the sources that they're drawing from to create their own supply chain. So there's multiple supply chains. You can be somebody like Red Hat that the provide software, and then people will leverage Red Hats for their own supply chain. And then you have the cloud provider and they have their own source of software. So I think that the key thing is the awareness of how much you rely upon that ecosystem before we look at the security of the supply chain. It's really understanding your supply chain. >> And just to follow up on that. So can you... I'm sort of checking my own level of understanding on this subject. When you talk about open source code, you're talking about a code base that is often maintained essentially by volunteers, isn't that correct? >> A mix of volunteers and paid professionals where a company has an interest in the open source project, but predominantly I would say it's... Well, I'm not entirely sure, but volunteers make up a substantial part of the ecosystem that is for sure. So it's a mix really. Some people do it because they enjoy writing software. They want to share software. Other people also enjoy working software, but they're in the position that a company pays for them to work on that software. So it's a mix of both. >> Vincent, give us a reminder of reminder of why this is important from a little bit of a higher level. Step back from the data center view of things, from the IT view of things, just from a societal perspective, Vincent, what happens when we don't secure our digital supply chain? What are the things that are put at risk? >> Okay, well, there's a significant number of things that are placed at risk, the security of the enterprise itself. So your own customer data, your own internal corporate data is place at risk if there were a supply chain breach. But further to that for a software provider, and I think that in a lot of cases, most companies today are software providers or software developers. You actually put your own customers at risk as well, not just their data, but their actual... The things that they're working on, any workloads that they may have, an order that they might place as an example. So there's a number of areas where you want to have the security of that supply chain and the software components that you have figured out. You want to be on top of that because there is that risk that trickles down when it comes to an event. I mean, we've seen that with breaches earlier this year, one company is breached multiple companies end up being breached as a result of that. So it's really important. I think we all have a part to play in that I always view it as it's not just about the company itself. So I mean, speaking from a Red Hat perspective, I don't look at it as we're just securing Red Hat, we're securing our customers, and then we're also doing that for their customers as well, because they're writing software that's running on the software that we're providing to them. So there is this trickle down effect that comes, and so I think that every link in that chain, I mean, it's wonderful that it's called a supply chain. It's only as strong as its weakest link. So our view is how do we strengthen every link in that chain? And we're one part of it, but we're kind of looking a little broader, what can we do upstream and how can we help our customers to ensure the security of their part in that supply chain? >> Yeah, I want to talk about that in a broad sense, but let's see if we can get a little bit more specific in terms of what some of the chains look like because it's not just really one chain when you think about it, there's the idea of inherent flaws that can be caught and then there are the things that bad actors might be doing to leverage those flaws. So you've got all of these different things that are converging. So first and Vincent, if you want to toss this to Luke back and forth, it's up to you guys. What about this issue of inherent flaws in code? We referenced this idea of the maintainer community. What are best practices for locking that down to make sure that there aren't inherent flaws or security risks? >> I'll take a stab at it, and then I'll let Luke follow up with maybe some of the technologies that Red Hat provides. And again, speaking to Red Hat as part of that chain. When we're talking about inherent risk, there's a vulnerability that's present upstream. We pull that software to Red Hat. We package it as a component of one of the pieces of software that we provide to our customers. It's our responsibility to pay attention to those upstream potential vulnerabilities, potential risks, and correct them in our code. So that might be taking a patch from upstream, applying it to our software, might be grabbing the latest version from upstream, whatever the case might be, but it's our responsibility to provide that protection for that software to actually remediate that risk, and then our customers can then install the update and apply the mitigation themselves. If we take a look at it from, when we're looking at multiple suppliers where you'd asked earlier about, what part of it is Red Hat and what part of it is self-service open source? When you look at that, the work that Red Hat's doing there as a commercial provider of open source and end user for that little bit that they're going to grab themselves, that Red Hat doesn't provide, it's going to have to do all of those things as well. They're going to have to pay attention to that risk from upstream. They're going to have to pay attention to any potential vulnerabilities and pull that in to figure out, do I need to patch? Where do I need to patch it? And that's something we didn't really touch on was an inventory of the software that you have in place. I mean, you don't know that you need to fix something. You don't even know that it's running. So, I mean, there's a lot of considerations there where you have to pay attention to a lot of sources. Certainly there's a metadata automation, all of these things that make it easier, but it doesn't absolve us of the responsibility across the board to pay attention to these things, whether you're grabbing it from upstream directly or from the vendor. And it's the vendor's responsibility to then be paying attention to things upstream. >> Yeah, so Luke, I want you to kind of riff on that from the perspective that let's just assume that Vincent was just primarily talking about the idea that, okay, we've established that this code is solid and we've got gold copy of it and we know it's okay. There aren't inherent problems in the code as far as we can tell. Well, that's fine. I'm a developer. I go out to pull code and to use. How do I know if it's not been tampered with? How do I know if it's in fact the code that was validated during this process before? What do you do about that? >> So there's several methods there, but I just like to loop back to that point, because I think this is really interesting around, so if you look at a software supply chain, this is a mix of humans and machines, and both have flaws, probably humans a bit more. And a supply chain, you have developers. You have code reviewers, you have your systems administrators that set up the systems, and then you have your machine actors. So you've got your build systems, the various machines that are part of that supply chain. Now the humans, there's a as an attack factor there 'cause typically they will have some sort of identity, which they leverage for access to the supply chain. So quite often a developer's identity can be compromised. So a lot of the time people will have a corporate account that gives them some sort of single sign on access to multiple systems. So the developers are coming and this could be somebody in the community as well. Their account is compromised, then they're able to easily backdoor systems. So that's one aspect. And then there is machines as well. There's the whole premise of machines software not being up to date. So when the latest nasty vulnerability is released, machines are updated, then the machines have their flaws. They can be exploited. So I would say it's not just a technical problem. There is a humanistic element to this as well around protecting your supply chain. And I would say a really good perspective to carry when you're looking to, how do I secure my supply chain is treat it like you would a production system. So what do I mean by that? When we put something into production and we've got this very long legacy of treating it with a very strict security context around who can access that people, okay. How much it's upgraded and it's patched? And we seem to not have this same perception around our supply chain and our build systems, the integrity of those, the access of those, the policy around the access and so forth. So that's one giveaway that I would say is a real key focus that you should have is treat it like a production system. Be very mindful about what you're bringing in, who can access it because it is the keys to the kingdom, because if somebody compromises your supply chain, your build systems and so forth, they can compromise the whole chain because the chain is only as strong as the weakest link. So that's what I draw upon it. And around the verifications, there is multiple technologies that you can leverage. So Red Hat, we've got a very robust sign in system that we use so that you can be sure that the packages that we get you have non-repudiation that they've been produced by Red Hat. When you update your system, that's automatically looked after. And there are other systems as well, there's other new technologies that are starting to get a foothold around the provenance of aspects of your build system. So when you're pulling in from these multiple sources of open source communities, you can have some provenance around what you're putting in as well. And yeah, I don't want to bite share too much on the technologies, but there's some exciting stuff starting to happen there as well. >> So let's look at an example of something, because I think it's important to understand all of these different aspects. Recently, I think actually still in the news, we found that some logging software distributed by Apache that's widely used in people's websites to gather information about... To help from a security perspective and to help developers improve things that are going on in websites. A vulnerability was discovered. I guess, first Alibaba, some folks were reported it directly to some folks at Apache and the Apache Organization. And then of all people, some folks from Minecraft mentioned it in a blog. That seems like a crazy way to find out about something that's a critical flaw. Now we're looking at this right now with hindsight. So with hindsight, what could we have done to not be in the circumstances that we're in right now? Vincent, I'll toss that to you first, but again, if Luke is more appropriate, let us know. >> No, it's a great question, and it's a hard question. >> How did you let this happen, Vincent? How did you let this happen? >> It wasn't me, I promise. (Dave laughs) >> What I mean, it's a challenging question I mean, and there's a number of areas where we focused on a lot of what we perceived as critical software. So it comes to web server applications, DNS, a number of the kind of the critical infrastructure that powers the internet. Right or wrong. Do we look at logging software as a critical piece of that? Well, maybe, maybe we should, right? Logging is definitely important as part of an incident response or just an awareness of what's going on. So, I mean, yeah, it probably should have been considered critical software, but I mean, it's open source, right? So there's a number of different logging applications. I imagine now we're scrutinizing those a little bit more, but looking beforehand, how do you determine what's critical until an event like this happens, and it's unfortunate that it happens. And I like to think of these as learning opportunities, and certainly not just for Red Hat, but for this (talking over each other) >> Certainly this is not... Yeah, this is not an indictment of our entire industry. We are all in this together and learning every day. It just highlights how complex the situation is that we're dealing with, right? >> It really is. And I mean, a lot of what we're looking at now is how do we get tools into the hands of developers who can catch some of these things earlier. And there's a lot of commercial offerings, there's a lot of open source tools that are available and being produced that are going to help with these sorts of situations moving forward. But I mean, all the tools on the planet aren't going to help if they're not being used. So, I mean, there has to be an education and an incentive for these developers, particularly, maybe in some upstream communities where they are labors of love and they're passionate projects they're not sponsored or backed by a corporation who's paying for these tools, to be able to use some of them and move that forward. I think that looking at things now, there is work to be done. Obviously there's always going to be work to be done. Not all of these tools, and we have to recognize this, they're not all perfect. They're not going to catch everything. These tools could have been... I mean, I don't know if they were running these tools or not, they could have been, and the tool simply could not have picked them up. So part of it is the proactive part. We talk a lot about shift left and moving these things earlier into the development process and that's great, and we should do it. It certainly should never be seen as a silver bullet or a replacement for a good response. And I think the really important thing to highlight with respect to this, and I mean, this touches on the supply chain issue as well, companies, especially those who never maybe saw themselves as a software development company really have to figure out and understand how to do appropriate response. Part of that is awareness, what do you have installed? Part of it is sources of information. Like how do I find out about a new vulnerability or a potential vulnerability? And then it's just the speed to respond. We know that a number of companies they have, maybe it's a Patch Tuesday, maybe it's a patch 26th of the month, maybe it's patch day of the quarter, we have to learn how to respond to these things quickly so that we can apply these mitigations and these fixes as quickly as possible to them protect ourselves and protect the end users or customers that we have, or to keep the kids from using some backdoors in Minecraft is the word. >> (laughs) Yeah. Look, this is an immensely important subject. To wrap us up on this, Luke, I'd like you to pretend that you just got into an elevator in a moderately tall building, and you have 60 seconds to share with me someone who already trusts you, you don't have to convince me of your credentials or anything. I trust you. What tools specifically do you need me to be running, tools and processes. You've got 60 seconds to say, Dave, if you're not doing these things right now, you're unnecessarily vulnerable. So ready, and go, Luke. >> So automatically update all packages. Always stay up-to-date so that when an issue does hit, you're not having to go back 10 versions and work your way forward. That's the key thing. Ensure that everything you pull in, you're not going to have 100%, but have a very strict requirement that there is non-repudiation, is signed content, so you can verify that it's not being tampered with. For your developers that are producing code, run static, dynamic analysis, API fuzzes, all of these sorts of tools. They will find some vulnerabilities for you. Be part of communities. Be part of communities, help chop the wood and carry the water because the log for Jay, the thing is that was found because it was in the open. If it wasn't any open, it wouldn't have been found. And I've been in this business for a long time. Software developers will always write bugs. I do. Some of them will be security bugs. That's never going to change. So it's not about stopping something that's inevitable. It's about being prepared to react accordingly in our right and correct manner when it does happen so that you can mitigate against those risks. >> Well, we're here on the 35th floor. That was amazing. Thank you, Luke. Vincent, you were in the elevator also listening in on this conversation. Did we miss anything? >> No, I mean, the only thing I'll say is that it's really helpful to partner with an enterprise open source provider, be it Red Hat or anybody else. I don't want to toot our own horn. They do a lot of that work on your behalf that you don't have to do. A lot of the things that Luke was talking about, those providers do, so you don't have to. And that's where you.. I liked that you talked about, hey, you don't have to convince me that I'm trusted, or that I trust you. Trust those vendors. They're literally here to do a lot of that heavy lifting for you and trust the process. Yeah, it's a very, very good point. And I know that sometimes it's hard to get to that point where you are the trusted advisor. Both of you certainly are. And with that, I would like to thank you very much for an interesting conversation. Gentlemen, let's keep in touch. You're always welcome on theCUBE. Luke, second time, getting a chance to talk to you on theCUBE personally. Fantastic. With that, I would like to thank everyone for joining this very special series on theCUBE. Managing risk in the digital supply chain is a critical topic to keep on top of. Thanks for tuning into theCUBE. We'll be back soon. I'm Dave Nicholson saying, thanks again. (upbeat music)

>>mhm Yes. >>Welcome back to the Cube coverage of Red Hat summit 21 2021. I'm john for host of the Cubans virtual this year as we start preparing to come out of Covid a lot of great conversations here happening around technology. This is the emerging technology with Red hat segment. We've got three great guests steve watt manager, distinguished engineer at Red Hat hurl saying senior software engineer Red Hat and luke Hines, who's the senior software engineer as well. We got the engineering team steve, you're the the team leader, emerging tech within red hat. Always something to talk about. You guys have great tech chops that's well known in the industry and I'll see now part of IBM you've got a deep bench um what's your, how do you view emerging tech um how do you apply it? How do you prioritize, give us a quick overview of the emerging tech scene at Redhead? >>Yeah, sure. It's quite a conflated term. The way we define emerging technologies is that it's a technology that's typically 18 months plus out from commercialization and this can sometimes go six months either way. Another thing about it is it's typically not something on any of our product roadmaps within the portfolio. So in some sense, it's often a bit of a surprise that we have to react to. >>So no real agenda. And I mean you have some business unit kind of probably uh but you have to have first principles within red hat, but for this you're looking at kind of the moon shot, so to speak, the big game changing shifts. Quantum, you know, you got now supply chain from everything from new economics, new technology because that kind of getting it right. >>Yeah, I think we we definitely use a couple of different techniques to prioritize and filter what we're doing. And the first is something will pop up and it will be like, is it in our addressable market? So our addressable market is that we're a platform software company that builds enterprise software and so, you know, it's got to be sort of fit into that is a great example if somebody came up came to us with an idea for like a drone command center, which is a military application, it is an emerging technology, but it's something that we would pass on. >>Yeah, I mean I didn't make sense, but he also, what's interesting is that you guys have an open source D N A. So it's you have also a huge commercial impact and again, open sources of one of the 4th, 5th generation of awesomeness. So, you know, the good news is open source is well proven. But as you start getting into this more disruption, you've got the confluence of, you know, core cloud, cloud Native, industrial and IOT edge and data. All this is interesting, right. This is where the action is. How do you guys bring that open source community participation? You got more stakeholders emerging there before the break down, how that you guys manage all that complexity? >>Yeah, sure. So I think that the way I would start is that, you know, we like to act on good ideas, but I don't think good ideas come from any one place. And so we typically organize our teams around sort of horizontal technology sectors. So you've got, you know, luke who's heading up security, but I have an edge team, cloud networking team, a cloud storage team. Cloud application platforms team. So we've got these sort of different areas that we sort of attack work and opportunities, but you know, the good ideas can come from a variety of different places. So we try and leverage co creation with our customers and our partners. So as a good example of something we had to react to a few years ago, it was K Native right? So the sort of a new way of doing service um and eventing on top of kubernetes that was originated from google. Whereas if you look at Quantum right, ibms, the actual driver on quantum science and uh that originated from IBM were parole. We'll talk about exactly how we chose to respond to that. Some things are originated organically within the team. So uh luke talking about six law is a great example of that, but we do have a we sort of use the addressable market as a way to sort of focus what we're doing and then we try and land it within our different emerging technologies teams to go tackle it. Now. You asked about open source communities, which are quite interesting. Um so typically when you look at an open source project, it's it's there to tackle a particular problem or opportunity. Sometimes what you actually need commercial vendors to do is when there's a problem or opportunity that's not tackled by anyone open source project, we have to put them together to create a solution to go tackle that thing. That's also what we do. And so we sort of create this bridge between red hat and our customers and multiple different open source projects. And this is something we have to do because sometimes just that one open source project doesn't really care that much about that particular problem. They're motivated elsewhere. And so we sort of create that bridge. >>We got two great uh cohorts here and colleagues parole on the on the Quantum side and you got luke on the security side. Pro I'll start with you. Quantum is also a huge mentioned IBM great leadership there. Um Quantum on open shift. I mean come on. Just that's not coming together for me in my mind, it's not the first thing I think of. But it really that sounds compelling. Take us through, you know, um how this changes the computing landscape because heterogeneous systems is what we want and that's the world we live in. But now with distributed systems and all kinds of new computing modules out there, how does this makes sense? Take us through this? >>Um yeah john's but before I think I want to explain something which is called Quantum supremacy because it plays very important role in the road map that's been working on. So uh content computers, they are evolving and they have been around. But right now you see that they are going to be the next thing. And we define quantum supremacy as let's say you have any program that you run or any problems that you solve on a classical computer. Quantum computer would be giving you the results faster. So that is uh, that is how we define content supremacy when the same workload are doing better on content computer than they do in a classical computer. So the whole the whole drive is all the applications are all the companies, they're trying to find avenues where Quantum supremacy are going to change how they solve problems or how they run their applications. And even though quantum computers they are there. But uh, it is not as easily accessible for everyone to consume because it's it's a very new area that's being formed. So what, what we were thinking, how we can provide a mechanism that you can you don't connect this deal was you have a classical world, you have a country world and that's where a lot of thought process been. And we said okay, so with open shift we have the best of the classical components. You can take open shift, you can develop, deploy around your application in a country raised platform. What about you provide a mechanism that the world clothes that are running on open shift. They are also consuming quantum resources or they are able to run the competition and content computers take the results and integrate them in their normal classical work clothes. So that is the whole uh that was the whole inception that we have and that's what brought us here. So we took an operator based approach and what we are trying to do is establish the best practices that you can have these heterogeneous applications that can have classical components. Talking to our interacting the results are exchanging data with the quantum components. >>So I gotta ask with the rise of containers now, kubernetes at the center of the cloud native value proposition, what work clothes do you see benefiting from the quantum systems the most? Is there uh you guys have any visibility on some of those workloads? >>Uh So again, it's it's a very new, it's very it's really very early in the time and uh we talk with our customers and every customers, they are trying to identify themselves first where uh these contacts supremacy will be playing the role. What we are trying to do is when they reach their we should have a solution that they that they could uh use the existing in front that they have on open shift and use it to consume the content computers that may or may not be uh, inside their own uh, cloud. >>Well I want to come back and ask you some of the impact on the landscape. I want to get the look real quick because you know, I think security quantum break security, potentially some people have been saying, but you guys are also looking at a bunch of projects around supply chain, which is a huge issue when it comes to the landscape, whether its components on a machine in space to actually handling, you know, data on a corporate database. You guys have sig store. What's this about? >>Sure. Yes. So sick store a good way to frame six store is to think of let's encrypt and what let's encrypt did for website encryption is what we plan to do for software signing and transparency. So six Door itself is an umbrella organization that contains various different open source projects that are developed by the Six door community. Now, six door will be brought forth as a public good nonprofit service. So again, we're very much basing this on the successful model of let's Encrypt Six door will will enable developers to sign software artifacts, building materials, containers, binaries, all of these different artifacts that are part of the software supply chain. These can be signed with six door and then these signing events are recorded into a technology that we call a transparency log, which means that anybody can monitor signing events and a transparency log has this nature of being read only and immutable. It's very similar to a Blockchain allows you to have cryptographic proof auditing of our software supply chain and we've made six stores so that it's easy to adopt because traditional cryptographic signing tools are a challenge for a lot of developers to implement in their open source projects. They have to think about how to store the private keys. Do they need specialist hardware? If they were to lose a key then cleaning up afterwards the blast radius. So the key compromise can be incredibly difficult. So six doors role and purpose essentially is to make signing easy easy to adopt my projects. And then they have the protections around there being a public transparency law that could be monitored. >>See this is all about open. Being more open. Makes it more secure. Is the >>thief? Very much yes. Yes. It's that security principle of the more eyes on the code the better. >>So let me just back up, is this an open, you said it's gonna be a nonprofit? >>That's correct. Yes. Yes. So >>all of the code is developed by the community. It's all open source. anybody can look at this code. And then we plan alongside the Linux Foundation to launch a public good service. So this will make it available for anybody to use if your nonprofit free to use service. >>So luke maybe steve if you can way into on this. I mean, this goes back. If you look back at some of the early cloud days, people were really trashing cloud as there's no security. And cloud turns out it's a more security now with cloud uh, given the complexity and scale of it, does that apply the same here? Because I feel this is a similar kind of concept where it's open, but yet the more open it is, the more secure it is. And then and then might have to be a better fit for saying I. T. Security solution because right now everyone is scrambling on the I. T. Side. Um whether it's zero Trust or Endpoint Protection, everyone's kind of trying everything in sight. This is kind of changing the paradigm a little bit on software security. Could you comment on how you see this playing out in traditional enterprises? Because if this plays out like the cloud, open winds, >>so luke, why don't you take that? And then I'll follow up with another lens on it which is the operate first piece. >>Sure. Yes. So I think in a lot of ways this has to be open this technology because this way we have we have transparency. The code can be audited openly. Okay. Our operational procedures can be audit openly and the community can help to develop not only are code but our operational mechanisms so we look to use technology such as cuba netease, open ship operators and so forth. Uh Six store itself runs completely in a cloud. It is it is cloud native. Okay, so it's very much in the paradigm of cloud and yeah, essentially security, always it operates better when it's open, you know, I found that from looking at all aspects of security over the years that I've worked in this realm. >>Okay, so just just to add to that some some other context around Six Law, that's interesting, which is, you know, software secure supply chain, Sixth floor is a solution to help build more secure software secure supply chains, more secure software supply chain. And um so um there's there's a growing community around that and there's an ecosystem of sort of cloud native kubernetes centric approaches for building more secure software. I think we all caught the solar winds attack. It's sort of enterprise software industry is responding sort of as a whole to go and close out as many of those gaps as possible, reduce the attack surface. So that's one aspect about why 6th was so interesting. Another thing is how we're going about it. So we talked about um you mentioned some of the things that people like about open source, which is one is transparency, so sunlight is the best disinfectant, right? Everybody can see the code, we can kind of make it more secure. Um and then the other is agency where basically if you're waiting on a vendor to go do something, um if it's proprietary software, you you really don't have much agency to get that vendor to go do that thing. Where is the open source? If you don't, if you're tired of waiting around, you can just submit the patch. So, um what we've seen with package software is with open source, we've had all this transparency and agency, but we've lost it with software as a service, right? Where vendors or cloud service providers are taking package software and then they're making it available as a service but that operationalize ng that software that is proprietary and it doesn't get contributed back. And so what Lukes building here as long along with our partners down, Lawrence from google, very active contributor in it. Um, the, is the operational piece to actually run sixth or as a public service is part of the open source project so people can then go and take sixth or maybe run it as a smaller internal service. Maybe they discover a bug, they can fix that bug contributed back to the operational izing piece as well as the traditional package software to basically make it a much more robust and open service. So you bring that transparency and the agency back to the SAS model as well. >>Look if you don't mind before, before uh and this segment proportion of it. The importance of immune ability is huge in the world of data. Can you share more on that? Because you're seeing that as a key part of the Blockchain for instance, having this ability to have immune ability. Because you know, people worry about, you know, how things progress in this distributed world. You know, whether from a hacking standpoint or tracking changes, Mutability becomes super important and how it's going to be preserved in this uh new six doorway. >>Oh yeah, so um mutability essentially means cannot be changed. So the structure of something is set. If it is anyway tampered or changed, then it breaks the cryptographic structure that we have of our public transparency service. So this way anybody can effectively recreate the cryptographic structure that we have of this public transparency service. So this mutability provides trust that there is non repudiation of the data that you're getting. This data is data that you can trust because it's built upon a cryptographic foundation. So it has very much similar parallels to Blockchain. You can trust Blockchain because of the immutable nature of it. And there is some consensus as well. Anybody can effectively download the Blockchain and run it themselves and compute that the integrity of that system can be trusted because of this immutable nature. So that's why we made this an inherent part of Six door is so that anybody can publicly audit these events and data sets to establish that there tamper free. >>That is a huge point. I think one of the things beyond just the security aspect of being hacked and protecting assets um trust is a huge part of our society now, not just on data but everything, anything that's reputable, whether it's videos like this being deep faked or you know, or news or any information, all this ties to security again, fundamentally and amazing concepts. Um I really want to keep an eye on this great work. Um Pearl, I gotta get back to you on Quantum because again, you can't, I mean people love Quantum. It's just it feels like so sci fi and it's like almost right here, right, so close and it's happening. Um And then people get always, what does that mean for security? We go back to look and ask them well quantum, you know, crypto But before we get started I wanted, I'm curious about how that's gonna play out from the project because is it going to be more part of like a C. N. C. F. How do you bring the open source vibe to Quantum? >>Uh so that's a very good question because that was a plan, the whole work that we are going to do related to operators to enable Quantum is managed by the open source community and that project lies in the casket. So casket has their own open source community and all the modification by the way, I should first tell you what excuse did so cute skin is the dedicate that you use to develop circuits that are run on IBM or Honeywell back in. So there are certain Quantum computers back and that support uh, circuits that are created using uh Houston S ticket, which is an open source as well. So there is already a community around this which is the casket. Open source community and we have pushed the code and all the maintenance is taken care of by that community. Do answer your question about if we are going to integrate it with C and C. F. That is not in the picture right now. We are, it has a place in its own community and it is also very niche to people who are working on the Quantum. So right now you have like uh the contributors who who are from IBM as well as other uh communities that are specific specifically working on content. So right now I don't think so, we have the map to integrated the C. N. C. F. But open source is the way to go and we are on that tragic Torri >>you know, we joke here the cube that a cubit is coming around the corner can can help but we've that in you know different with a C. But um look, I want to ask you one of the things that while you're here your security guru. I wanted to ask you about Quantum because a lot of people are scared that Quantum is gonna crack all the keys on on encryption with his power and more hacking. You're just comment on that. What's your what's your reaction to >>that? Yes that's an incredibly good question. This will occur. Okay. And I think it's really about preparation more than anything now. One of the things that we there's a principle that we have within the security world when it comes to coding and designing of software and this aspect of future Cryptography being broken. As we've seen with the likes of MD five and Sha one and so forth. So we call this algorithm agility. So this means that when you write your code and you design your systems you make them conducive to being able to easily swap and pivot the algorithms that use. So the encryption algorithms that you have within your code, you do not become too fixed to those. So that if as computing gets more powerful and the current sets of algorithms are shown to have inherent security weaknesses, you can easily migrate and pivot to a stronger algorithms. So that's imperative. Lee is that when you build code, you practice this principle of algorithm agility so that when shot 256 or shot 5 12 becomes the shar one. You can swap out your systems. You can change the code in a very least disruptive way to allow you to address that floor within your within your code in your software projects. >>You know, luke. This is mind bender right there. Because you start thinking about what this means is when you think about algorithmic agility, you start thinking okay software countermeasures automation. You start thinking about these kinds of new trends where you need to have that kind of signature capability. You mentioned with this this project you're mentioning. So the ability to actually who signs off on these, this comes back down to the paradigm that you guys are talking about here. >>Yes, very much so. There's another analogy from the security world, they call it turtles all the way down, which is effectively you always have to get to the point that a human or a computer establishes that first point of trust to sign something off. And so so it is it's a it's a world that is ever increasing in complexity. So the best that you can do is to be prepared to be as open as you can to make that pivot as and when you need to. >>Pretty impressive, great insight steve. We can talk for hours on this panel, emerging tech with red hat. Just give us a quick summary of what's going on. Obviously you've got a serious brain trust going on over there. Real world impact. You talk about the future of trust, future of software, future of computing, all kind of going on real time right now. This is not so much R and D as it is the front range of tech. Give us a quick overview of >>Yeah, sure, yeah, sure. The first thing I would tell everyone is go check out next that red hat dot com, that's got all of our different projects, who to contact if you're interested in learning more about different areas that we're working on. And it also lists out the different areas that we're working on, but just as an overview. So we're working on software defined storage, cloud storage. Sage. Well, the creator of Cf is the person that leads that group. We've got a team focused on edge computing. They're doing some really cool projects around um very lightweight operating systems that and kubernetes, you know, open shift based deployments that can run on, you know, devices that you screw into the sheet rock, you know, for that's that's really interesting. Um We have a cloud networking team that's looking at over yin and just intersection of E B P F and networking and kubernetes. Um and then uh you know, we've got an application platforms team that's looking at Quantum, but also sort of how to advance kubernetes itself. So that's that's the team where you got the persistent volume framework from in kubernetes and that added block storage and object storage to kubernetes. So there's a lot of really exciting things going on. Our charter is to inform red hats long term technology strategy. We work the way my personal philosophy about how we do that is that Red hat has product engineering focuses on their product roadmap, which is by nature, you know, the 6 to 9 months. And then the longer term strategy is set by both of us. And it's just that they're not focused on it. We're focused on it and we spend a lot of time doing disambiguate nation of the future and that's kind of what we do. We love doing it. I get to work with all these really super smart people. It's a fun job. >>Well, great insights is super exciting, emerging tack within red hat. I'll see the industry. You guys are agile, your open source and now more than ever open sources, uh, product Ization of open source is happening at such an accelerated rate steve. Thanks for coming on parole. Thanks for coming on luke. Great insight all around. Thanks for sharing. Uh, the content here. Thank you. >>Our pleasure. >>Thank you. >>Okay. We were more, more redhead coverage after this. This video. Obviously, emerging tech is huge. Watch some of the game changing action here at Redhead Summit. I'm john ferrier. Thanks for watching. Yeah.