 Hello everyone, my name is Dave Vellante and we're digging into the many facets of the software supply chain and how to better manage digital risk. I'd like to introduce Kirsten Newcomer who is the Director of Cloud and DevSecOps strategy at Red Hat. Hello Kirsten, welcome. Hello Dave, great to be here with you today. Let's dive right in. What technologies and practices should we be thinking about that can help improve the security posture within the software supply chain? So I think the most important thing for folks to think about really is adopting DevSecOps. And while organizations talk about DevSecOps, right, or and many folks have adopted DevOps, they tend to forget the security part of DevSecOps. And so for me, DevSecOps is both DevSec, how do I shift security left into my supply chain and SecOps, which is a better understood and more common piece of the puzzle, but then closing that loop between what issues are discovered in production and feeding that back to the development team to ensure that we're really addressing that supply chain. Yeah, I heard a stat. I don't know what the source is. I don't know if it's true, but it probably is that around 50% of the organizations in North America don't even have a SecOps team. Now, of course that probably includes a lot of smaller organizations, but they don't have a SecOps team. They're not doing DevSecOps. But so what are organizations doing for supply chain security today? Yeah, I think the most common practice that people have adopted is vulnerability scanning. And so they will do that as part of their development process. They might do it at one particular point. They might do it at more than one point. But one of the challenges that we see, first of all, is that that's the only security gate that they've integrated into their supply chain, into their pipeline. So they may be scanning code that they get externally. They may be scanning their own code. But the second challenge is that the results take so much work to triage, right? This is static vulnerability scanning. You get information that is not in full context because you don't know whether a vulnerability is truly exploitable unless you know how exposed that particular part of the code is to the internet, for example, or to other aspects. And so it's just a real challenge for organizations who are only looking at static vulnerability data to figure out what the right steps to take are to manage those. And there's no way we're going to wind up with zero vulnerabilities in the code that we're all working with today. Things just move too quickly. Is that idea of vulnerability scanning and almost like sampling where you may or may not find the weakest link? I would say that it's more comprehensive than that. The vulnerability scanners that are available are generally pretty strong. But again, if it's a static environment, a lot of them rely on NVD database, which typically is gonna give you the worst case scenario. And by nature, can't account for things like, was the software that you're scanning built with controls, you know, mitigations built in, right? It's just gonna tell you this is the package and this is the known vulnerabilities associated with that package. It's not gonna tell you whether there were compiler time flags that maybe mitigated that vulnerability. And so it's almost overwhelming for organizations to prioritize that information and really understand it in context. And so when I think about the closed loop feedback, you really want not just that static scan, but also analysis that takes into account the configuration of the application and the runtime environment and any mitigations that might be present there. I see, thank you for that. So, you know, given that this digital risk and software supply chains are now front and center, we read about them all the time now. How do you think organizations are responding? What's the future of software supply chain gonna look like? That's a great one. So I think organizations are scrambling. We've certainly at Red Hat, we've seen an increase in questions about Red Hat's own supply chain security and we've got lots of information that we can share and make available. But I think also we're starting to see this strong increased interest in security bill of materials. So I actually started working with automation and standards around security bill of materials a number of years ago. I participated in the Linux Foundation, as PDX project. There are other projects like Cyclone DX. But I think all organizations are going to need to, those of us who deliver software, we're gonna need to provide S-bombs and consumers of our software should be looking for S-bombs to help them understand to build transparency across the projects and to facilitate that automation. You can leverage the data in a software package list to get a quick view of vulnerabilities. Again, you don't have that runtime context yet but it saves you that step perhaps of having to do the initial scanning. And then there are additional things that folks are looking at, attested pipelines is going to be key for building your custom software. As you pull the code in and your developers build their solutions, their applications, being able to vet the steps in your pipeline and attest that nothing has happened in that pipeline is really going to be key. So the software bill of material is going to give you a granular picture of your software and then what, the chain of provenance, if you will? Well, an S-bomb, depending on the format, an S-bomb absolutely can provide a chain of provenance but another thing when we think about it from the security angle, so there's the provenance, right? Where did this come from? Who provided it to me? But also with that bill of materials, that list of packages, you can leverage tooling that will give you information about vulnerability information about those packages. At Red Hat, we don't think that vulnerability info should be included in the S-bomb because vulnerability data changes every day. But it saves you a step potentially, right? Then you don't necessarily have to be so concerned about doing the scan. You can pull data about known vulnerabilities for those packages without a scan. Similarly, the attestation in the pipeline, that's about things like ensuring that the code that you pull into your pipeline is signed, right? Signatures are in many ways a more important piece for defining provenance and getting trust. Got it. So I was talking to a CISO the other day and I was asking her, okay, what are your main challenges? Kind of the standard analyst questions, if you will. She said, look, I got great people but I just don't have enough depth of talent to handle the challenges. I'm always sort of playing catch up. And so that leads one to the conclusion, okay, automation is potentially an answer to address that problem. But at the same time, people have said to me, sometimes we put too much faith in automation. Some say, okay, Kirsten, help me square the circle. I want to automate because I lack the talent but it's not sufficient. How do I, what are your thoughts on automation? So I think in the world we're in today, especially with cloud native applications, you can't manage without automation because things are moving too quickly. So I think the way that you assess whether automation is meeting your goals becomes critical. And so looking for external guidance such as the NIST secure software development framework, that can help. But again, when we come back, I think look for an opinionated position from the vendors, from the folks you're working with, from your advisors on what are the appropriate set of gates. And we've talked about vulnerability scanning but analyzing the config data for your apps is just as important, right? And so I think we have to work together as an industry to figure out what are the key security gates? How do we audit the automation so that I can validate that automation and be comfortable that it is actually meeting the needs? But I don't see how we move forward without automation. Excellent, thank you. So given, I mean, we were forced into digital without a lot of thought. Some folks, it's a spectrum, some organizations in better shape than others, but many had to just dive right in without a lot of strategy. And now people have sat back and said, okay, let's be more planful, more thoughtful. So as you, and then of course, you got the supply chain hacks, et cetera. How do you think the whole narrative and the strategy is going to change? How should it change the way in which we create, maintain, consume software as both organizations and individuals? So again, I think there's going to be, and there's already a need, request for more transparency from software vendors. This is a place where S-bombs play a role. But there's also a lot of conversation out there about zero trust. So what does that mean in, you have to have a relationship with your vendor that provides transparency. So that you can assess the level of trust. You also have to, in your organization, determine to your point earlier about people with skills and automation, how do you trust but verify, right? This is not just with your vendor, but also with your internal supply chain, right? So trust and verify remains key. That's been a concept that's been around for a while. CloudNative doesn't change that, but it may change the tools that we use. And we may also decide what are our trust boundaries, right? Are they, where are we comfortable trusting? Where do we think that zero trust is a more applicable place, a more applicable frame to apply? But I do think back to the automation piece. And again, it is hard for everybody to keep up. I think we have to break down silos. We have to ensure that teams are talking across those silos so that we can leverage each other's skills. And we need to think about managing everything as code. What I like about that everything as code, including security, is it does create auditability in new ways, right? If you're managing your infrastructure and a GitOps-like approach, your security policies with a GitOps-like approach, it provides visibility and auditability and it enables your dev team to participate in new ways. So when you talk about zero trust, I think, okay, I can't trust users. I got to trust them very much. Users, machines, employees, my software, my partners. Yeah. Every possible connection point. Absolutely. And this is where both attestation and identity become key, right? Being able to, I mean, the SolarWinds team has done a really interesting set of things with their supply chain after they were in response to the hack they were dealing with, right? They're now using Tecton CD chains to ensure that they have attested every step in their supply chain process and that they can replicate that with automation. So they're doing a combination of, yep, we've got humans who need to interact with the chain and then we can validate every step in that chain. And then workload identity, right, is a key thing for us to think about too. So how do we assert identity for the workloads that are being deployed to the cloud and verify whether that's with Spiffy Spire or related projects, verify that the workload is the one that we meant to deploy and also runtime behavioral analysis. I know we've been talking about supply chain but again, I think we have to do this closed loop, right? You can't just think about shifting security left. And I know you mentioned earlier, right? A lot of teams don't have SecOps but there are solutions available that help assess the behavior in runtime and that information can be fed back to the app dev team to help them adjust and verify and validate where do I need to tighten my security? I'm glad you brought up the SolarWinds to Kirsten what they're doing. I remember after 9-11, I was afraid to fly but it was probably the safest time in history to fly. And so same analogy here, SolarWinds probably has learned more about this and its reputation took a huge hit. But if you had to compare what SolarWinds has learned and applied at the speed at which they've done it with maybe some other software suppliers, you might find that they've actually done a better job. It's just unfortunate that something hit that we never saw before. To me it was stuck snap like, we've never seen anything like this before and then boom, we ventured a whole new era. I'll give you the last word, Kirsten. No, just to agree with you and I think again as an industry, it's pushed us all to think harder and more carefully about where do we need to improve? What tools do we need to build to help ourselves? Again, SBOMs have been around for a good 10 years or so but they are enjoying a resurgence of importance. Signing, image signing, manifest signing, that's been around for ages but we haven't made it easy to integrate that into the supply chain and that's work that's happening today. Similarly, the attestation of a supply chain, of a pipeline, that's happening. So I think as an industry, we've all recognized that we need to step up and there's a lot of creative energy going into improving in this space. Excellent, Kirsten Newcomer, thanks so much for your perspectives, excellent conversation. My pleasure, thanks so much. You're welcome and you're watching The Cube, the leader in tech coverage.