 Welcome back, we're winding down the Cube's coverage of Red Hat Summit 2022. We're here at the seaport in Boston. It's been two days of little different Red Hat Summit. We're used to, you know, eight, 9,000 people. It's a much smaller event this year. Fewer developers are actually, in terms of the mix, a lot more suits this year, which is kind of interesting to see, you know, that evolution and a big virtual audience. So, and I love the way the keynotes we've noticed are a lot tighter. They're pithy, on time. They're not keeping us in the hall for three hours. So, we appreciate that. Kind of catering to the virtual audience. Dave Vellante here with my co-host, Paul Gillan. As I say, things are winding down. There was an analyst event here today. That's ended, but luckily we have Jim Mercer here. He's a research director at IDC. He's going to share maybe some of the learnings from that event today and this event overall. We're going to talk about Dev SecOps. Kirsten Newcomer is director of security, product management, and hybrid platforms at Red Hat. Folks, welcome. Thank you for seeing me. Thank you, great to be here. Yeah, so it's, you know, security's everywhere, right? You and I have spoken about, you know, the supply chain hacks. We've done some sort of interesting work around that and reporting around that. I feel like, you know, SolarWinds created a new awareness. You know, you see these moments, it's stucks net or want to cry, and now SolarWinds is very insidious. But security, Red Hat, it's everywhere in your portfolio. Maybe talk about the strategy. Sure, absolutely. We feel strongly that it's really important that security be something that is managed in a holistic way, present throughout the application stack, starting with the operating system and also throughout the life cycle, which is partly where Dev SecOps comes in, right? So Red Hat has kind of had a long history here, right? I think SE Linux in Red Hat Enterprise Linux for mandatory access control, that's been a key component of securing containers in a Kubernetes environment. SE Linux has demonstrated the ability to prevent or mitigate container escapes to the file system. And we just have continued to work up the stack as we go. Our acquisition of Stack Rocks a little over a year ago, now known as Red Hat Advanced Cluster Security, gives us the opportunity to really deliver on that Dev SecOps component, both to Kubernetes native security solution with the ability to both help shift security left for the developers by integrating in the supply chain, but also providing a SecOps perspective for the operations and the security team and feeding information between the two to really try and do that closed infinity loop. And then an additional investment more recently in SIGStore and some technologies. Interesting, yeah, SIGStore, go ahead. But shift left, explain to people what you mean by shift left for people might not be familiar with that. Fair enough, so tradition, for many, many years, right? Security, IT security has been something that's largely been part of an operations environment and not something that developers tended to need to be engaged in with the exception of, say, static source code, static analysis tools. We started to see vulnerability management tools get added, but even then they tend to come after the application has been built. And I even ran a few years ago, I ran into a customer who said my security team won't let me get this information early. So shift left is all about making sure that there are security gates in the app dev process and information provided to the developer as early as possible, in fact, even in the IDE, Red Hat Code Ready dependency analytics does that, so that the developers are part of the solution and don't have to wait and get their app stalled just before it's ready to go into deployment. You've also been advocating for supply chain security, software supply chain, first of all, explain what a software supply chain is and then what is unique about the security needs of that environment? Sure, and the SolarWinds example, as Dave said, really kind of has raised awareness around this. So just like we use the term supply chain, most people given kind of what's been happening with the pandemic, they've started hearing that term a lot more than they used to, right? So there's a supply chain to get your groceries to the grocery store, food to the grocery store, there's a supply chain for manufacturing, where do the parts come for the laptops that we're all using, right? And where do they get assembled? Software has a supply chain also, right? So for years and even more so now, developers have been including open source components into the applications they build. So some of the supplies for the applications, the components of those applications, they can come from anywhere in the world, they can come from a wide range of open source projects, developers are adding their custom code to that, all of this needs to be built together, delivered together. And so when we think about a supply chain and the SolarWinds hack, right, there are a couple of elements of supply chain security that are particularly key. The executive order from May of last year, I think was partly in direct response to the SolarWinds hack, and it calls out that we need a software bill of materials. Now again, in manufacturing, that's something folks are used to. I actually had the opportunity to contribute to the software package data exchange format, SPDX, when it was first started, I've lost track of when that was. So but in SBOM is all about saying what are all of those components that I'm delivering in my solution, it might be an application layer, it might be the host operating system layer, but at every layer. And if I know what's in what I'm delivering, I have the opportunity to learn more information about those components to track, where does log for shell, right, when the log for J or spring for shell, which followed shortly thereafter, when those hit, how do I find out which solutions that I'm running have the vulnerable components in them and where are they? The software bill of materials helps with that, but you also have to know where, right? And that's the ops side. I feel like I missed a piece of your question. No, it's not a silver bullet, though, to your point and log for J very widely used, but let's bring Jim into the conversation. So Jim, we've been talking about some of these trends. What's your focus area of research? What are you seeing as some of the mega trends in this space? So yeah, I mean, I focus in DevOps and DevSecOps, and it's interesting just to talk about trends. Kirstin was mentioning the open source, and if you look back five, six, seven years ago, and you went to any major financial institution, you asked them if they use an open source. It's true. What do you think is that, right? Everything's, we wrote it all here, right? It's all from our developers, which were well done. Yeah, right, exactly. But the reality is they probably used an a little open source back then, but they didn't realize it, right? It's exactly true. However, today, not only are they not a versed open source, they're seeking it out, right? So we have survey data that kind of indicates, a survey that was run kind of in late 2021 that shows that 70% of those who responded said that within the next two years, 90% of their applications will be made up of open source. In other words, in other words, the content of an application, 10% will be written by themselves, and 90% will come from other sources. So we're seeing these more kind of composite applications, right? Not everybody's kind of, if you will, at that 90%, but applications are much more composite than they were before, right? So I'm pulling in pieces, but I'm taking the innovation of the community, right? So I not only have the innovation of my developers, but I can expand that, right? I can take the innovation of the community and bring that in and do things much quicker. I can also not have my developers worry about things that may be just kind of common stuff that's out there that might have already been written. In other words, just focus on the business logic. Don't focus on how to get orders or how to move widgets and those types of things that everybody does, because that's out there in open source. I'll just take that, right? I'll take it, somebody's perfected it, right? Better than I'll ever do. I'll take that in, and then I'll just focus and build my business logic on top of that. So open source has been a boom for growth, and I think we've heard a little bit of that in the last two days, right, from Red Hat, right? But talking about the software building materials, right? And then you think about now I'm taking all that stuff in, I have my first level open source that I took in, it's called Component A, but behind Component A is all these transitive dependencies. In other words, open source also uses open source, right? So there's this kind of this, if you will, web or nest, if you want to call it of transitive dependencies that need to be understood. And if I have five, six layers deep, I have a vulnerability in another component, and I'm over here, well, I guess what, I picked up that vulnerability, right? Even though I didn't explicitly go for that component. So that's where understanding that software building materials is really important. I like to explain it as, during the pandemic, we've all experienced, there was all this contact tracing, right? It was a term that all came to mind. The software building materials is like the contact tracing for your open source, right? Anything that I've come in contact with, just because I came in contact with it, even though I didn't explicitly go looking for COVID, if you will, I got it, right? So in the same regard, that's how I do the contact tracing for my software. That 90% figure is really striking. 90% of open source use is really striking, considering that it wasn't that long ago that one of the wraps on open source was it's insecure, because anybody can see the code, therefore anybody can create, can see the vulnerabilities. What changed? I'll say what changed is kind of first, the understanding that I can leapfrog and innovate with open source, right? There's more open source content out there. So as organizations had to digitally transform themselves, and we've all heard the terminology around, well, hey, you know, with the pandemic, we've leapfrog of five years of digital transformation or something along those lines, right? Open source is part of what helps those teams to do that type of leapfrog and do that type of innovation, right? If you had to develop all of that natively, it just takes too long, or you might not have the talent to do it, right? And to find that talent to do it. So it kind of gives you that benefit. The interesting thing about what you mentioned there was, you know, now we're hearing about all these vulnerabilities, right, and in open source, right, that we need to contend with because the bad guys realize that I'm taking a lot of open source and they're saying, geez, that's a great way to get myself into applications, right? If I get myself into this one open source component, I'll get into thousands or more applications, right? So it's a fast path into the supply chain and that's why it's so important that you understand where your vulnerabilities are and the software. I think the visibility cuts two ways, though. So when people say it's insecure because it's visible, in fact, actually the visibility helps with security. The reality that I can go see the code, that there is a community working on finding and fixing vulnerabilities in that code. Whereas in code that is not open source, it's a little bit more security by obscurity, which isn't really security and there could well be vulnerabilities that a good hacker is going to find, but are not disclosed. So one of the other things we feel strongly about at Red Hat, frankly, is if there is a CVE that affects our code, disclose that publicly. We have a public CVE database and it's actually really important to us that we share that. We think we share way more information about issues in our code than most other users or consumers of open source and we work that through the broad community as well. And then also for our enterprise customers, if an issue needs to be fixed, we don't just fix it in the most recent version of the open source, we will backport that fix. And one of the challenges, if you're only addressing the most recent version, that may not be well tested. It might have other bugs. It might have other issues. When we backport a security vulnerability fix, we're able to do that to a stable version, give the customers the benefit of all the testing and use that's gone on while also fixing. Kirsten, can you talk about the announcements? Because everyone's wondering, okay, now what do I do about this? What technology is there to help me? Obviously, in this framework, you got to follow the right processes, skill sets, all that, not to dismiss that, that's the most important part. But the announcements that you made at Red Hat Summit, and how does the Stack Rocks acquisition fit into those? Sure, so in particular, if we stick with DevSecOps a minute, but again, I'll do, it's not just, again, for me, DevSecOps is the full life cycle and many people think of it as just that shift left piece, but for me, it's the whole thing. So Stack Rocks ACS has had the ability to integrate into the CICD pipeline before we bought them, that continues. They don't just assess for vulnerabilities, but also for application misconfigurations, access priv requests and helm charts, deployment, YAML. So kind of the big, there are two sort of major things in the DevSecOps angle of the announcement or the supply chain angle of the announcement, which is the investment that we've been making in Sigstore, you know, signing, getting integrity of the components, the elements you're deploying is important. It's, I have been asked for years about the ability to sign container images. The reality is that the signing technology in Red Hat signs everything we ship and always have, but the signing technology wasn't designed to be used in a CICD pipeline, and Sigstore is explicitly designed for that use case to make it easy for developers, as well as, you know, you can back it with Fulcio, you can back it with an OIDC-based signing, keyless signing, throw away the key, or if you want that enterprise CA, you can have that backing there too. And you can establish that as a protocol where you must? You can, you can, right, so our pattern. So that would have helped with SolarWinds. Absolutely. Right, because they were putting in malware and then taking it out, seeing what happened. But that's my question was, could Sigstore help? I always evaluate now everything, and I'm not a security expert, but would this have helped with SolarWinds? A lot of times the answer is no. It's a combination. So a combination of Sigstore integrated with TectonChains. So we ship Tecton, which is a Kube-native supply chain pipeline. As OpenShift Pipelines, we added chains to that. Chains allows you to attest every step in your pipeline. And you're doing that attestation by signing those steps so that you can validate that those steps have not changed. And in fact, the folks at SolarWinds are using TectonChains. They did a great talk in October at KubeCon North America on the changes they've made to their supply chain. So they are using both TectonChains and Sigstore as part of their updated pipeline. Our pattern will allow our customers to deploy OpenShift Advanced Cluster Manager, Advanced Cluster Security and Quay with security gates in place and that include a pipeline built on Tecton with TectonChains there to sign those steps in the pipeline, to enable signing of the code that's moving through that pipeline, to store that signature in Quay and to validate the image signature upon deployment with Advanced Cluster Security. So, Jim, your perspective on this. So Red Tats, I mean, you care about security, security is everywhere, but you're not a security company. You follow security companies. There's like far too many of them. CISOs all say my number one challenge is lack of talent, but I have all these tools to deal with. You see new emerging companies that are, you know, doing pretty well and then you see a company that's highly respected like an octa screw up the communications on a pretty benign hack actually when you peel the onion on that. It's just this mess and it doesn't seem like it's going to get any simpler. Maybe the answer is companies like Red Hat kind of absorbing that and taking care of it. What do you see there? I mean, maybe it's great for business because you've got so many companies. Yeah, there's a lot of companies and there's certainly a lot of innovation out there and unique ways to make security easier, right? I mean, one of the keys here is to be able to make security easier for developers, right? You know, one of the challenges with adopting DevSecOps is if DevSecOps creates a lot of friction in the process, right? It's hard to really, you know, I can do it once but I can't keep doing that, right? And get the same kind of velocity, right? So I need to take the friction out of the process. And one of the challenges a lot of organizations have and I've heard this from the development side but I've also heard it from the infosex side, right? Because, you know what, I take inquiry for people in infosex and they're like, how do I get these developers to do what I want, right? You know, part of the challenge they have is like, you know, I got these teams using these tools, I got those teams using those tools. And it's a similar challenge that we saw on DevOps where there's just too many, if you will, too many dang tools, right? So, you know, that is a challenge for organizations is they're trying to kind of normalize the tools. Interestingly, we did a survey, I think around last August or something and one of the questions was around, you know, where do you want your security, right? Where do you want to get your DevSecup security from? Do you want to get it from individual vendors, right? Or do you want to get it from like, you know, your platforms that you're using and deploying? Great question, Kubernetes. What would they say? The majority of them, they're hoping they can get it built into the platform. That's really what they want. They want it, and it's, you know, and you see a lot of the security vendors are trying to build security platforms. Like we're not just a SaaS tool, we're DAS, we're this, you know, whatever, right? You know, and they're building platforms to kind of be that end to end security platform. Trying to solve that problem, right? To, you know, make it easier to kind of consume the product overall, you know, without a bunch of individual tools along the way. But certainly, tool sprawl is definitely a challenge out there. Just one other point around the six store stuff, which I love, because, you know, that goes back to the supply chain and talking about digital provenance, right? Understanding where things, how do I validate, you know, that what I gave you is what you thought it was, right? And, you know, what I like about it with Tecton Chains is because there's a couple things. Well, first of all, you know, I don't want to just sign things like after I built the binary. Well, I mean, I do want to sign it, but I don't want to just sign things once, right? Because all through the process, you know, think of it as a manufacturing plant, right? I'm making automobiles, right? If I check the quality of the automobile at one stage and I don't check it to the other, you know, things have changed, right? How do I know that I did something wasn't compromised, right? So with six store kind of tied in with Tecton Chains, you know, it kind of gives me that view. And the other aspect I like about it is, you know, kind of this kind of transparency in the law, right? To understand, right, exactly. So I could see what was going on. So there is some this kind of like public scrutiny, like if something bad happened, you could go back and see what happened there and it wasn't as you expected, right? As with most discussions on this topic, we could go for an hour. Right, I know. Yes, that's really important. And thank you guys for coming on, sharing your perspectives, the data. Our pleasure. Keep up the good work, Kirsten. Yeah, thanks so much. It's on you. Yeah. The IDC survey said it, they want it. That's right. They want it in platforms. You're up. That's right. That's right. All right, good luck to both of you. Great, thank you both so much. All right, and thank you for watching. We're back to wrap right after this short break. This is Dave Vellante for Paul Gillin. You're watching The Cube.