(upbeat music) >> 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, 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 the 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. 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, is it 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 they are, again, if it's a static environment, a lot of them rely on NVD database, which typically it's going to 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, mitigations built in. It's just going to tell you, this is the package, and this is the known vulnerabilities associated with that package. It's not going to tell you whether there were compiler time flags, that may be 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, 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 going to 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, SPDX project. There are other projects like CycloneDX. But I think all organizations are going to need to, those of us who deliver software, we're going to 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 materials is going to give you, a granular picture of your software, and then what the chain of, providence if you will or? >> Well, an S-bomb depending on the format, an S-bomb absolutely can provide a chain of providence. But another thing when we think about it, from the security angles, so there's the providence, 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 everyday. But, it saves you a step potentially. 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. Signatures are in many ways of more important piece for defining providence and getting trust. >> Got it. So I was talking to Asiso the other day, and 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. That leads one to the conclusion, okay, automation is potentially an answer to address that problem, but the same time, people have said to me, sometimes we put too much faith in automation. some say okay, hey Kirsten help me square the circle. I want to automate because I lack the talent, but it's not, it's not sufficient. 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's 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 configed data for your apps it's just as important. 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. We were forced into digital, without a lot of thought. Some folks, it's a spectrum, some organizations are 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've 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 softwares as both organizations and individuals? >> Yeah. So again, I think there's going to be, and there's already, 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? This is not just with your vendor, but also with your internal supply chain. So trust and verify remains key. That's been a concept that's been around for a while. Cloud native doesn't change that, but it may change the tools that we use. And we may also decide what are our trust boundaries. Are they where are we comfortable trusting? Where do we think that zero trust is 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 the everything is code including security, is it does create auditability in new ways. If you're managing your infrastructure, and get Ops like approach your security policies, with a get Ops like approach, it provides visibility and auditability, and it enables your dev team to participate in new ways. >> So when you're talking about zero trust I think, okay, I can't trust users, I got to trust the verified users, machines, employees, my software, my partners. >> Yap >> Every possible connection point. >> Absolutely. And this is where both attestation and identity become key. So 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. They're now using Tekton 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, 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 SPIFFE 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. You can't just think about shifting security left. And I know you mentioned earlier, a lot of teams don't have SecOps, but there are solutions available, that help assess the behavior and 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? >> Am glad you brought up the SolarWinds to Kirsten what they're doing. And as I remember after 911, everyone 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, unfortunately, that something hit that we never saw before. To me it was Stuxnet, like we'd never seen anything like this before, and then boom, we've entered 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, S-bombs 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 that attestation of a supply chain, of a pipeline that's happening. So I think as a 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 theCUBE, the leader in tech coverage. (soft music)

(upbeat music) >> 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, 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 the 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. 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, is it 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 they are, again, if it's a static environment, a lot of them rely on NVD database, which typically it's going to 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, mitigations built in. It's just going to tell you, this is the package, and this is the known vulnerabilities associated with that package. It's not going to tell you whether there were compiler time flags, that may be 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, 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 going to 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, SPDX project. There are other projects like CycloneDX. But I think all organizations are going to need to, those of us who deliver software, we're going to 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 materials is going to give you, a granular picture of your software, and then what the chain of, providence if you will or? >> Well, an S-bomb depending on the format, an S-bomb absolutely can provide a chain of providence. But another thing when we think about it, from the security angles, so there's the providence, 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 everyday. But, it saves you a step potentially. 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. Signatures are in many ways of more important piece for defining providence and getting trust. >> Got it. So I was talking to Asiso the other day, and 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. That leads one to the conclusion, okay, automation is potentially an answer to address that problem, but the same time, people have said to me, sometimes we put too much faith in automation. some say okay, hey Kirsten help me square the circle. I want to automate because I lack the talent, but it's not, it's not sufficient. 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's 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 configed data for your apps it's just as important. 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. We were forced into digital, without a lot of thought. Some folks, it's a spectrum, some organizations are 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've 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 softwares as both organizations and individuals? >> Yeah. So again, I think there's going to be, and there's already, 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? This is not just with your vendor, but also with your internal supply chain. So trust and verify remains key. That's been a concept that's been around for a while. Cloud native doesn't change that, but it may change the tools that we use. And we may also decide what are our trust boundaries. Are they where are we comfortable trusting? Where do we think that zero trust is 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 the everything is code including security, is it does create auditability in new ways. If you're managing your infrastructure, and get Ops like approach your security policies, with a get Ops like approach, it provides visibility and auditability, and it enables your dev team to participate in new ways. >> So when you're talking about zero trust I think, okay, I can't trust users, I got to trust the verified users, machines, employees, my software, my partners. >> Yap >> Every possible connection point. >> Absolutely. And this is where both attestation and identity become key. So 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. They're now using Tekton 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, 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 SPIFFE 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. You can't just think about shifting security left. And I know you mentioned earlier, a lot of teams don't have SecOps, but there are solutions available, that help assess the behavior and 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? >> Am glad you brought up the SolarWinds to Kirsten what they're doing. And as I remember after 911, everyone 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, unfortunately, that something hit that we never saw before. To me it was Stuxnet, like we'd never seen anything like this before, and then boom, we've entered 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, S-bombs 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 that attestation of a supply chain, of a pipeline that's happening. So I think as a 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 theCUBE, the leader in tech coverage. (soft music)

(upbeat music) >> 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, 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 the 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. 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, is it 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 they are, again, if it's a static environment, a lot of them rely on NVD database, which typically it's going to 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, mitigations built in. It's just going to tell you, this is the package, and this is the known vulnerabilities associated with that package. It's not going to tell you whether there were compiler time flags, that may be 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, 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 going to 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, SPDX project. There are other projects like CycloneDX. But I think all organizations are going to need to, those of us who deliver software, we're going to 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 materials is going to give you, a granular picture of your software, and then what the chain of, providence if you will or? >> Well, an S-bomb depending on the format, an S-bomb absolutely can provide a chain of providence. But another thing when we think about it, from the security angles, so there's the providence, 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 everyday. But, it saves you a step potentially. 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. Signatures are in many ways of more important piece for defining providence and getting trust. >> Got it. So I was talking to Asiso the other day, and 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. That leads one to the conclusion, okay, automation is potentially an answer to address that problem, but the same time, people have said to me, sometimes we put too much faith in automation. some say okay, hey Kirsten help me square the circle. I want to automate because I lack the talent, but it's not, it's not sufficient. 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's 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 configed data for your apps it's just as important. 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. We were forced into digital, without a lot of thought. Some folks, it's a spectrum, some organizations are 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've 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 softwares as both organizations and individuals? >> Yeah. So again, I think there's going to be, and there's already, 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? This is not just with your vendor, but also with your internal supply chain. So trust and verify remains key. That's been a concept that's been around for a while. Cloud native doesn't change that, but it may change the tools that we use. And we may also decide what are our trust boundaries. Are they where are we comfortable trusting? Where do we think that zero trust is 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 the everything is code including security, is it does create auditability in new ways. If you're managing your infrastructure, and get Ops like approach your security policies, with a get Ops like approach, it provides visibility and auditability, and it enables your dev team to participate in new ways. >> So when you're talking about zero trust I think, okay, I can't trust users, I got to trust the verified users, machines, employees, my software, my partners. >> Yap >> Every possible connection point. >> Absolutely. And this is where both attestation and identity become key. So 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. They're now using Tekton 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, 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 SPIFFE 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. You can't just think about shifting security left. And I know you mentioned earlier, a lot of teams don't have SecOps, but there are solutions available, that help assess the behavior and 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? >> Am glad you brought up the SolarWinds to Kirsten what they're doing. And as I remember after 911, everyone 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, unfortunately, that something hit that we never saw before. To me it was Stuxnet, like we'd never seen anything like this before, and then boom, we've entered 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, S-bombs 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 that attestation of a supply chain, of a pipeline that's happening. So I think as a 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 theCUBE, the leader in tech coverage. (soft music)