>>Welcome to this cube conversation. I'm Dave Nicholson and we're having this conversation in advance of cube con cloud native con north America, 2021. Uh, we are going to be talking specifically about a subject near and dear to my heart, and that is security. We have a very special guest from red hat, the security lead from the office of the CTO. New kinds. Welcome. Welcome to the cube Luke. >>Oh, it's great to be here. Thank you, David. Really looking forward to this conversation. >>So you have a session, uh, at a CubeCon slash cloud native con this year. And, uh, frankly, I look at the title and based on everything that's going on in the world today, I'm going to accuse you of clickbait because the title of your session is a secure supply chain vision. Sure. What other than supply chain has is in the news today, all of these things going on, but you're talking about the software supply chain. Aren't you tell, tell us about, tell us about this vision, where it came from Phyllis in. >>Yes, very much. So I do agree. It is a bit of a buzzword at the moment, and there is a lot of attention. It is the hot topic, secure supply chains, thanks to things such as the executive order. And we're starting to see an increase in attacks as well. So there's a recent statistic came out that was 620%. I believe increase since last year of supply chain attacks involving the open source ecosystem. So things are certainly ramping up. And so there is a bit of clickbait. You got me there. And um, so supply chains, um, so it's predominantly let's consider what is a supply chain. Okay. And we'll, we'll do this within the context of cloud native technology. Okay. Cause there's many supply chains, you know, many, many different software supply chains. But if we look at a cloud native one predominantly it's a mix of people and machines. >>Okay. So you'll have your developers, uh, they will then write code. They will change code and they'll typically use our, a code revision control system, like get, okay, so they'll make their changes there. Then push those changes up to some sort of repository, typically a get Harbor or get level, something like that. Then another human will then engage and they will review the code. So somebody that's perhaps a maintain will look at the code and they'll improve that a code. And then at the same time, the machine start to get involved. So you have your build servers that run tests and integration tests and they check the code is linted correctly. Okay. And then you have this sort of chain of events that start to happen. These machines, these various actors that start to play their parts in the chain. Okay. So your build system might generate a container image is a very common thing within a cloud native supply chain. >>Okay. And then that image is typically deployed to production or it's hosted on a registry, a container registry, and then somebody else might utilize that container image because it has software that you've packaged within that container. Okay. And then this sort of prolific expansion of use of coasts where people start to rely on other software projects for their own dependencies within their code. Okay. And you've got this kind of a big spaghetti of actors that are dependent on each other and feed him from each other. Okay. And then eventually that is deployed into production. Okay. So these machines are a lot of them non open source code. Okay. Even if there is a commercial vendor that manages that as a service, it's all based on predominantly open source code. Okay. And the security aspects with the supply chain is there's many junctures where you can exploit that supply chain. >>So you can exploit the human, or you could be a net ferrous human in the first place you could steal somebody's identity. Okay. And then there's the build systems themselves where they generate these artifacts and they run jobs. Okay. And then there are the production system, which pulls these down. Okay. And then there's the element of which we touched upon around libraries and dependencies. So if you look at a lot of projects, they will have approximately around a hundred, perhaps 500 dependencies that they all pull in from. Okay. So then you have the supply chains within each one of those, they've got their own set of humans and machines. And so it's a very large spaghetti beast of, of, of sort of dependence and actors and various identities that make up. >>Yeah. You're, you're describing a nightmarish, uh, scenario here. So, uh, so, so I definitely appreciate the setup there. It's a chain of custody nightmare. Yeah. >>Yes. Yeah. But it's also a wonderful thing because it's allowed us to develop in the paradigms that we have now very fast, you know, you can, you can, you can prototype and design and build and ship very fast, thanks to these tools. So they're wonderful. It's not to say that they're, you know, that there is a gift there, but security has arguably been left as a bit of an afterthought essentially. Okay. So security is always trying to it's at the back of the race. It's always trying to catch up with you. See what I mean? So >>Well, so is there a specific reason why this is particularly timely? Um, in, you know, when we, when we talk about deployment of cloud native applications, uh, something like 75% of what we think of is it is still on premesis, but definitely moving in the direction of what we loosely call cloud. Um, is why is this particularly timely? >>I think really because of the rampant adoption that we see. So, I mean, as you rightly say, a lot of, uh, it companies are still running on a, sort of a, more of a legacy model okay. Where deployments are more monolithic and statics. I mean, we've both been around for a while when we started, you would, you know, somebody would rack a server, they plug a network cable and you'd spend a week deploying the app, getting it to run, and then you'd walk away and leave it to a degree. Whereas now obviously that's really been turned on its head. So there is a, an element of not everybody has adopted this new paradigm that we have in development, but it is increasing, there is rapid adoption here. And, and many that aren't many that rather haven't made that change yet to, to migrate to a sort of a cloud type infrastructure. >>They certainly intend to, well, they certainly wished to, I mean, there's challenges there in itself, but it, I would say it's a safe bet to say that the prolific use of cloud technologies is certainly increasing as we see in all the time. So that also means the attack vectors are increasing as we're starting to see different verticals come into this landscape that we have. So it's not just your kind of a sort of web developer that are running some sort of web two.site. We have telcos that are starting to utilize cloud technology with virtual network functions. Uh, we have, um, health banking, FinTech, all of these sort of large verticals are starting to come into cloud and to utilize the cloud infrastructure model that that can save them money, you know, and it can make them, can make their develop more agile and, you know, there's many benefits. So I guess that's the main thing is really, there's a convergence of industries coming into this space, which is starting to increase the security risks as well. Because I mean, the security risks to a telco are a very different group to somebody that's developing a web platform, for example. >>Yeah. Yeah. Now you, you, uh, you mentioned, um, the sort of obvious perspective from the open source perspective, which is that a lot of this code is open source code. Um, and then I also, I assume that it makes a lot of sense for the open source community to attack this problem, because you're talking about so many things in that chain of custody that you described where one individual private enterprise is not likely to be able to come up with something that handles all of it. So, so what's your, what's your vision for how we address this issue? I know I've seen in, um, uh, some of the content that you've produced an allusion to this idea that it's very similar to the concept of a secure HTTP. And, uh, and so, you know, imagine a world where HTTP is not secure at any time. It's something we can't imagine yet. We're living in this parallel world where, where code, which is one of the four CS and cloud security, uh, isn't secure. So what do we do about that? And, and, and as you share that with us, I want to dive in as much as we can on six store explain exactly what that is and, uh, how you came up with this. >>Yes, yes. So, so the HTTP story's incredibly apt for where we are. So around the open source ecosystem. Okay. We are at the HTTP stage. Okay. So a majority of code is pulled in on trusted. I'm not talking about so much here, somebody like a red hat or, or a large sort of distributor that has their own sign-in infrastructure, but more sort of in the, kind of the wide open source ecosystem. Okay. The, um, amount of code that's pulled in on tested is it's the majority. Okay. So, so it is like going to a website, which is HTTP. Okay. And we sort of use this as a vision related to six store and other projects that are operating in this space where what happened effectively was it was very common for sites to run on HTTP. So even the likes of Amazon and some of the e-commerce giants, they used to run on HTTP. >>Okay. And obviously they were some of the first to, to, uh, deploy TLS and to utilize TLS, but many sites got left behind. Okay. Because it was cumbersome to get the TLS certificate. I remember doing this myself, you would have to sort of, you'd have to generate some keys, the certificate signing request, you'd have to work out how to run open SSL. Okay. You would then go to an, uh, a commercial entity and you'd probably have to scan your passport and send it to them. And there'll be this kind of back and forth. Then you'll have to learn how to configure it on your machine. And it was cumbersome. Okay. So a majority just didn't bother. They just, you know, they continue to run their, their websites on protected. What effectively happened was let's encrypt came along. Okay. And they disrupted that whole paradigm okay. >>Where they made it free and easy to generate, procure, and set up TLS certificates. So what happened then was there was a, a very large change that the kind of the zeitgeists changed around TLS and the expectations of TLS. So it became common that most sites would run HTTPS. So that allowed the browsers to sort of ring fence effectively and start to have controls where if you're not running HTTPS, as it stands today, as it is today is kind of socially unacceptable to run a site on HTTP is a bit kind of, if you go to HTTP site, it feels a bit, yeah. You know, it's kind of, am I going to catch a virus here? It's kind of, it's not accepted anymore, you know, and, and it needed that disruptor to make that happen. So we want to kind of replicate that sort of change and movement and perception around software signing where a lot of software and code is, is not signed. And the reason it's not signed is because of the tools. It's the same story. Again, they're incredibly cumbersome to use. And the adoption is very poor as well. >>So SIG stores specifically, where did this, where did this come from? And, uh, and, uh, what's your vision for the future with six? >>Sure. So six door, six doors, a lockdown project. Okay. It started last year, July, 2020 approximately. And, uh, a few people have been looking at secure supply chain. Okay. Around that time, we really started to look at it. So there was various people looking at this. So it's been speaking to people, um, various people at Purdue university in Google and, and other, other sort of people trying to address this space. And I'd had this idea kicking around for quite a while about a transparency log. Okay. Now transparency logs are actually, we're going back to HTTPS again. They're heavily utilized there. Okay. So when somebody signs a HTTPS certificate as a root CA, that's captured in this thing called a transparency log. Okay. And a transparency log is effectively what we call an immutable tamper proof ledger. Okay. So it's, it's kind of like a blockchain, but it's different. >>Okay. And I had this idea of what, if we could leverage this technology okay. For secure supply chain so that we could capture the provenance of code and artifacts and containers, all of these actions, these actors that I described at the beginning in the supply chain, could we utilize that to provide a tamper resistant publicly or DePaul record of the supply chain? Okay. So I worked on a prototype wherever, uh, you know, some, uh, a week or two and got something basic happening. And it was a kind of a typical open source story there. So I wouldn't feel right to take all of the glory here. It was a bit like, kind of, you look at Linux when he created a Linux itself, Linus, Torvalds, he had an idea and he shared it out and then others started to jump in and collaborate. So it's a similar thing. >>I, um, shared it with an engineer from Google's open source security team called Dan Lawrence. Somebody that I know of been prolific in this space as well. And he said, I'd love to contribute to this, you know, so can I work this? And I was like, yeah, sure though, you know, the, the more, the better. And then there was also Santiago professor from Purdue university took an interest. So a small group of people started to work on this technology. So we built this project that's called Rico, and that was effectively the transparency log. So we started to approach projects to see if they would like to, to utilize this technology. Okay. And then we realized there was another problem. Okay. Which was, we now have a storage for signed artifacts. Okay. A signed record, a Providence record, but nobody's signing anything. So how are we going to get people to sign things so that we can then leverage this transparency log to fulfill its purpose of providing a public record? >>So then we had to look at the signing tools. Okay. So that's where we came up with this really sort of clever technology where we've managed to create something called ephemeral keys. Okay. So we're talking about a cryptographic key pair here. Okay. And what we could do we found was that we could utilize other technologies so that somebody wouldn't have to manage the private key and they could generate keys almost point and click. So it was an incredibly simple user experience. So then we realized, okay, now we've got an approach for getting people to sign things. And we've also got this immutable, publicly audited for record of people signing code and containers and artifacts. And that was the birth of six store. Then. So six store was created as this umbrella project of all of these different tools that were catering towards adoption of signing. And then being able to provide guarantees and protections by having this transparency log, this sort of blockchain type technology. So that was where we really sort of hit the killer application there. And things started to really lift off. And the adoption started to really gather steam then. >>So where are we now? And where does this go into the future? One of the, one of the wonderful things about the open source community is there's a sense of freedom in the creativity of coming up with a vision and then collaborating with others. Eventually you run headlong into expectations. So look, is this going to be available for purchase in Q1? What's the, >>Yeah, I, I will, uh, I will fill you in there. Okay. So, so with six door there's, um, there's several different models that are at play. Okay. I'll give you the, the two predominant ones. So one, we plan, we plan to run a public service. Okay. So this will be under the Linux foundation and it'll be very similar to let's encrypt. So you as a developer, if you want to sign your container, okay. And you want to use six door tooling that will be available to you. There'll be non-profit three to use. There's no specialties for anybody. It's, it's there for everybody to use. Okay. And that's to get everybody doing the right thing in signing things. Okay. The, the other model for six stories, this can be run behind a firewall as well. So an enterprise can stand up their own six store infrastructure. >>Okay. So the transparency log or code signing certificates, system, client tools, and then they can sign their own artifacts and secure, better materials, all of these sorts of things and have their own tamper-proof record of everything that's happened. So that if anything, untoward happens such as a key compromise or somebody's identity stolen, then you've got a credible source of truth because you've got that immutable record then. So we're seeing, um, adoption around both models. We've seen a lot of open source projects starting to utilize six store. So predominantly key, um, Kubernetes is a key one to mention here they are now using six store to sign and verify their release images. Okay. And, uh, there's many other open-source projects that are looking to leverage this as well. Okay. And then at the same time, various people are starting to consider six door as being a, sort of an enterprise signing solution. So within red hat, our expectations are that we're going to leverage this in open shift. So open shift customers who wish to sign their images. Okay. Uh, they want to sign their conflicts that they're using to deploy within Kubernetes and OpenShift. Rather they can start to leverage this technology as open shift customers. So we're looking to help the open source ecosystem here and also dog food, this, and make it available and useful to our own customers at red hat. >>Fantastic. You know, um, I noticed the red hat in the background and, uh, and, uh, you know, I just a little little historical note, um, red hat has been there from the beginning of cloud before, before cloud was cloud before there was anything credible from an enterprise perspective in cloud. Uh, I, I remember in the early two thousands, uh, doing work with tree AWS and, uh, there was a team of red hat folks who would work through the night to do kernel level changes for the, you know, for the Linux that was being used at the time. Uh, and so a lot of, a lot of what you and your collaborators do often falls into the category of, uh, toiling in obscurity, uh, to a certain degree. Uh, we hope to shine light on the amazing work that you're doing. And, um, and I, for one appreciate it, uh, I've uh, I've, I've suffered things like identity theft and, you know, we've all had brushes with experiences where compromise insecurity is not a good thing. So, um, this has been a very interesting conversation. And again, X for the work that you do, uh, do you have any other, do you have any other final thoughts or, or, uh, you know, points that we didn't cover on this subject that come to mind, >>There is something that you touched upon that I'd like to illustrate. Okay. You mentioned that, you know, identity theft and these things, well, the supply chain, this is critical infrastructure. Okay. So I like to think of this as you know, there's, sir, they're serving, you know, they're solving technical challenges and, you know, and the kind of that aspect of software development, but with the supply chain, we rely on these systems. When we wake up each morning, we rely on them to stay in touch with our loved ones. You know, we are our emergency services, our military, our police force, they rely on these supply chains, you know, so I sort of see this as there's a, there's a bigger vision here really in protecting the supply chain is, is for the good of our society, because, you know, a supply chain attack can go very much to the heart of our society. You know, it can, it can be an attack against our democracies. So I, you know, I see this as being something that's, there's a humanistic aspect to this as well. So that really gets me fired up to work on this technology., >>it's really important that we always keep that perspective. This isn't just about folks who will be attending CubeCon and, uh, uh, uh, cloud con uh, this is really something that's relevant to all of us. So, so with that, uh, fantastic conversation, Luke, it's been a pleasure to meet you. Pleasure to talk to you, David. I look forward to, uh, hanging out in person at some point, whatever that gets me. Uh, so with that, uh, we will sign off from this cube conversation in anticipation of cloud con cube con 2021, north America. I'm Dave Nicholson. Thanks for joining us.

>>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.