(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)

(upbeat music) >> Welcome to the Q3 "AWS Startup Showcase", I'm Lisa Martin. We're going to be talking about new breakthroughs in DevOps, Data Analytics and Cloud Management Tools, with WhiteSource Software, at least for the DevOps track. I'm excited to welcome Susan StClair, Director of Product at WhiteSource software to the program. Susan, it's great to see you! >> Oh, very excited to be here, Lisa, thank you. >> We've got a lot of stuff to talk about today, but ultimately, the theme that Susan's going to talk to us about us is, winning developer's trust is key to scaling-up open source security for the enterprise. We're going to unpack that. You talk about, that winning that trust is key, shifting left won't work without developers buy-in. Susan, help us understand this. >> Yeah, sure, so- on some of the topics we have later but you look at the rate of applications of being the pool of how fast that is, and you look at development teams of hundreds and you have the OpSec teams of five or ten, and they just can't do it all, so, really, you need to leverage everybody who's part of the application to really be able to make sure that you're developing and deploying and releasing a secure application. So, that's the Shifting Left. Unfortunately, I think what's happened is, because application security is overwhelmed and because they're like, "Oh, we have all of these developer teams over here, and it's their code, and they should fix it." And they just kind of dumped application security on them and the poor development teams are like, "but that's not what I do, I don't have any expertise in there." So if you really, truly, want a Shift Left to work, you do need to build that buy-in, you do need to build the trust with your extended team, for lack of a better word. And, really start to look at things that are important to them. So automated tools, making sure that they work with their tools sets and their processes. Looking at automation, not just in terms of scanning but also remediation. You just really need to start to work with them and think about application releases in a different mindset. >> And your recommendation here is also to build that trust gradually, and to let developers control the pace- >> Absolutely >> And the level of automation. Talk to me about why it's important to give the developers that control? >> Yeah, sure. Again, I think nobody likes to be told what to do, I certainly don't, don't tell me how to do my job. So, I think, that because historically application security and development have really been at odds. It has been somewhat of a confrontational relationship, so, I think as you're starting to build that trust, you do need to go slow. Where does it make sense to add in auto-remediation solution like WhiteSource, right? Where does it make sense? We don't want to do it everywhere, we don't want to overwhelm development teams with this. So, really start to look, let them control the pace, build that trust, build that. This is a good thing for everybody. And, again, I think with tools like WhiteSource, the solution software, you can pick and choose, it's not an all or nothing. We're going full automation, full remediation, one-stop-shopping, I mean you can kind of control the pace as you start to build that trust between the various teams. >> Is that differentiator for WhiteSource the ability for this auto-remediation tool to let them control that? >> Yeah, it definitely is, and I know it just rolls off the tongue, doesn't it? Just rolls off the tongue. >> It really does. (both laughing) >> Say it ten times fast >> I'm afraid to. >> Exactly, exactly. So, no, it actually, absolutely is a differentiator for us. And again when we look at, looking at our customer base and enterprise and we look at, even maybe smaller teams that trust is really made us successful and the key to that trust is really that controlling the pace with auto-remediation. And, some of the other automation pieces to the solution. >> And speaking of customers, you guys have 23% of the Fortune 100 as customers, give me an example of one of your favorite customers that you think really shows the value that WhiteSource is giving to those developers by giving them that control. >> Yeah, sure. So I feel like we're like the big company or bigger company that nobody has heard of outside of this space. But, not naming names, but large financial customers and really shifting application security, open-source application security, to the hands of the development teams. So they've actually, again, small application team, they've really pushed it out to the development teams as part of a repo-integration for scanning, for ticket creation, for auto-remediation, and that's really, let them scale beyond, just one or two teams to thousands of repos, for example. I mean, that is, in my opinion, a huge use case or huge validation of that this works. This isn't just somebody talking about how cool their software is and it's not based in reality. >> A stat that I read about WhiteSource offer that I wanted to get your feedback on, is that, "WhiteSource goes beyond traditional detection, providing dependency and trace analysis and that this helps organizations eliminate upto 85% of security alerts." That's a big number. Talk to me about how you guys do that and the advantages that delivers. >> Yeah, sure, so I think like the one of the challenges with, historically, with open-source solutions, is that they scan and they get this result, and you could have hundreds and thousands of insecure libraries and you're like, "Holy moly, where do I even start?" It's just completely overwhelming. And then you dig into little deeper and again starting to build that trust with development teams, and the development teams comes back to you and says, "Well, hey, guess what? Yeah I know that library is insecure, but I'm not using that part of that library." So, it's really kind of a false-positive. So, what this dependency tracing does and how it helps with prioritization, is it says, "Okay, we see this particular library, this vulnerable open-source library, and it is in your execution path, we can see that you're using it." So then, you're able to say, "Okay, I should definitely fix this, because we're using it, or maybe not." Maybe, again, it's part my backlog yes, we should always keep up-to-date, and be completely secure. But having that ability to prioritize where to start and having the alerts based on that really reduces the noise. And again, it builds the trust between the teams. >> So, we talked from the beginning about shifting left isn't going to work without developers buy-in, the idea of using auto-remediation tools to let developers control that pace, the OpSec folks, the Dev folks, we also have for, I believe, it's the fifth consecutive year now, a huge gap in cybersecurity skills. I think I've seen some reports estimating that there needs to be another three million professionals in the next five years to help fill that gap and at the same time we're seeing the security landscape changing dramatically. Talk to me about how the cybersecurity skills gap is affecting developers, OpSec folks, and what your seeing as a tool that can help remediate some of that. >> Sure, yeah, no, that's, I mean that is the challenge. And I would even say that there seems to those skills gap on the development side too. But, I think that in terms of some of the challenges with that, so you have to look at ways, how can we be smarter about things. So, we don't have people, large teams where they know everything about application security and open-source security that we can really rely on to drive remediation, but, also to use these tools that all of us bought that do different things, that aren't correlated but to kind of provide that glue. So, where WhiteSource, I think is trying to address this is, again, if I don't have the people, and I don't have the skillsets, first of all automation, right? So, the more that we can automate, the better. But, not just again, automating on the scanning side, I think that's certainly a part of it, but again, looking at how we can help development teams that are maybe not security experts, and keeping them up-to-date and giving them, again, automatic remediation so that they can fix things without having a really depth that you would expect in a cybersecurity professional. >> I'm sure they appreciate that, not having to have that depth, because there really isn't, in terms of developers, there isn't the time. Speed is always of the essence there. One of the things too that I know, is there's lot of tools being used, you mentioned that. How can WhiteSource Software help the developers to better utilize some of the tools that they have or not just be buying tools to check boxes? >> Yeah, sure. So, yeah it's sad fact, I think, within our industry, probably more than just our hours, but really a lot of decisions, purchasing decision are based on the, "Well, I need to scan because somebody told me to and I that I had to, and I'm going to check the box. I'm not really interested in fixing anything, I just need to check that box." And, I think, historically, when it comes to tool selection, again, because application security is really focused on that check-the-box because they need to do that for a compliance or governance reason, they really haven't taken into heart the teams that would actually be using them and having to make the magic happen. So, they would prioritize things that, again, maybe OpDev wouldn't, so, again does it work with my tools? As a developer, I live in my IDE, I live in my code-repo, I live in my ticketing system, security doesn't typically care anything about that. So, I think with WhiteSource, again, providing the tools that the OpSec team needs. So again, the compliance reports and the policies and all this stuff we love. Also providing, again, the way to easily fit into developer workflows, that's how we're helping to move beyond, okay, we're checking the box but we do want to actually fix something and we want to move the target along. So we're really, I think, helping address that need as well. >> I know you guys did a DevSec Ops Insights Report recently, unpack that a little bit with some of the key findings that have come out of that. >> Yeah, no, that's great, so it's very interesting. First of all I think we in the industry we talk a lot about DevSecOps and that security is part of the DevOps process and everything is good. But when you actually talk to people, I think, two things, one, it's very much a work in progress, absolutely, and a lot of that is part of the tooling. I think, too, like what we've found as a part of this survey, is that the developers, are often, they feel forced to, okay, I'm shifting left, you're telling me I own security, but you're also telling me that I need to get this application out the door. I need this to compete. So, they're really being forced into hard choices of which one to prioritize, and that really comes down to a culture thing. What is more important to you. Being secure or being competitive? And how do you weigh that? So, I thought that was actually very interesting, I think that we tend to give OpDev teams a bad rap but they're really doing the best they can and they need clear guidance and there needs to be a security culture for them to operate in. >> Right, that's a really big one that you just hit on, that cultural impact. It's hard to change. In the last 18 months, we've all been through so much change, personally and professionally. We've seen this massive acceleration in digital transformation, so probably more pressure on developers who need to be able to be productive from work, from anywhere environments, that that cultural change, is really critical. I'm curious if you have some feedback from customers that have done it successfully or are in the process of doing it successfully that you can share? >> Yeah, change is hard, no matter where it's at. Absolutely. So, I think, like where we've seen the most successful of our customers, around this specifically, it truly is both a top-down and bottom-up approach. From a top-down, you can't just give lip-service that application security is important. You can't just say, "Oh, again from a compliance check-the-box, point-of-view, we scan, and we're looking, and, oh look, we have these statistics. You have to really have to live it. And what I mean by that is, when you're developing new applications it's just as important as the feature list. Security bugs are just as important as any other type of bugs. So again, it goes into the workflow of the application development teams and you don't make them make these hard trade-offs all the time between security and release. And then, from the bottom-up, again, you need to be where your teams are at. You can't ask them to go into another tool, or another thing, or another this and that. They have things to do. You have to be where they are. And you, have to give targeted, actionable, not things they have to go research, a guidance, and automate as much as you can. Again, both on the scanning as well as on the remediation side. >> Meet them where they are and facilitate that automation. Susan, thank you so much for joining me today, talking about- >> My pleasure. >> How WhiteSource Software is helping that, and also for the challenge of saying auto-remediation 10 times in a row, fast. (Susan laughing) I might practice that later. But it's been great talking to you. >> That will be my home work. Likewise. >> Exactly! Thank you so much for joining me. >> My pleasure. >> This has been our coverage of the "AWS Startup Showcase", New Breakthroughs in DevOps, Data Analytics and Cloud Management tools. For Susan StClair, I'm Lisa Martin. Thanks for watching. (gentle music)

(techy music) >> Hello, everyone, I'm John Furrier, here in theCUBE Studios in Palo Alto for a special CUBE Conversation. Breaking news here in Silicon Valley and at Cisco Systems. News around Cisco partnering with Amazon Web Services, and here to talk about it is Fabio Gori, senior director of cloud solutions marketing at Cisco. Good to see you, welcome to theCUBE. >> Hello, John, how are you doing? >> So, big news, Cisco and AWS collaborate to accelerate innovation. A first kind of its kind of announcement. Love the pioneering aspect of this announcement. Obviously Amazon Web Services is the leading cloud provider who's been into hybrid cloud lately because they've been talking about that as their connection point into the enterprise. You guys are the leader in the enterprise at networking and other services. I don't even know how much market share you have these days, but you guys pretty much own the enterprise. Everyone kind of knows that. This deal with Amazon, you guys are doing the first hybrid Kubernetes on AWS. Talk about the announcement, what's the, why is this so important to Cisco? >> So, you named it, the solution name is actually a bit of a mouthful, but you mentioned the three keywords: is hybrid, is Kubernetes, is AWS, and this is the first solution of this kind that really integrates these two environments in a way that will be exceptionally beneficial for organizations that want to accelerate their innovation path, which ultimately means delivering applications faster without having to worry about constraints in terms of where to develop, where to deploy. This will really set them free to take their decisions. >> You know, one of the things we've been speculating on theCUBE a lot around cloud... There's been tons of debates, hybrid cloud, private cloud, multi-cloud, public cloud. All this stuff's been going on. One thing that's been very clear is the public cloud has demonstrated speed, agility, faster time to value, and for app developers that's been great. Cloud native, if you're born in the cloud it's just a great environment. If you've been on-premise and you had that legacy and/or existing pre-cloud environment, that trend has been more toward cloud operations, so not so much everything's moving to the cloud, although, you know, Andy Jassy would love to see everything move to Amazon, and that's his goal, but stuff stays on-prem, it's going to be for a while, but the cloud operations on-premise is essentially cloud but on-premise. So, that's this new hybrid dynamic. This is what enterprises have been re-imagining their infrastructure on. This is where a lot of the energy has been. How does that, that your solution for Kubernetes with Amazon, solve that problem? Does it help customers get to the cloud faster? Is it an operating model? Explain the nuance of how customers-- >> It's fundamentally all of that. If you think about it, and your introduction is spot-on, is customers really want to use the public cloud, right? The services in the public cloud, why? Because it gives them speed. I think that's a big change that we've seen since, I would say a few quarters, right, where people started really trading off speed and innovation for cost, right? Originally it was like, "I want to shut down my data center. "The cloud is going to be cheaper." Well, it's not about cheaper, it's faster, and people want to develop new digital experiences, which boils down to building applications faster. So, what ultimately they want to do is making the infrastructure on-prem looking like a bit more like the public cloud. Now, it's never going to be just like the public cloud with all the bells and whistles and innovation, but it's got to be such that you can actually take the best innovation of the public cloud, Kubernetes first, to the on-prem, rather than the other way around, right? That's our North Star, that's our belief, and Kubernetes is clearly a big winner in the container market. The way to develop new applications is based on containers. Kubernetes is the orchestrator right now in the marketplace. Every single big cloud provider has launched Kubernetes-based services in various forms, and so the enterprises are now looking at businesses of every size. They are trying to figure out how to really develop this capability on-prem, because in the end, as you know, it's never kind of black and white, right? We're still working with mainframes, long life to the mainframes. Going to be around for 20 years, probably. We're going to have traditional databases, ERP systems and the like for a very, very long time. What do you do, right? Everything that you develop new in the cloud needs to ultimately connect back to the existing systems because that's what you need. >> So, the simplicity of this is interesting. I want to just rewind that for a second. So, you're taking the best of Amazon, the container service, and alas, a container service with Kubernetes, bringing, making that available on-premises through the Cisco container platform-- >> Correct. >> So, this is the linchpin, so it's almost like-- >> Correct. >> You're not trying to take Cisco and say, "Oh, we're cloudified." >> Correct. >> You're taking the Cisco environment, which everyone runs, and some people think it runs great and-- >> Correct. >> They're not going to change that overnight, (chuckles) but you now enable them to take what they're doing here and make it compatible with the cloud and on-ramp to the cloud? >> So, the idea is fundamentally not so much taking EKS on-prem, that's not the thing, but the idea is having a container platform that fundamentally gives you pretty much a transparent way of interacting with the other side, and when I say transparent I really mean the linchpin of the solution, which is around the identity and authentication, right? What we've done that really differentiates this, that makes this so unique right now is that we have integrated IAM, you know, identity and authorization, sorry, and authentication in common. So, you're going to use the same set of keys on both sides, which of course is a developer dream because you don't have to use different type of keys in authentication models if you're a user. It's the same thing, and it's a dream for IT operation, because of course this is much simpler, as well as for the CSO and the security team. This makes it extremely secure, reduces the risk so that you have really a very consistent, integrated kind of solution, which is good-- >> So, there's engineering involved on Cisco's side. Can you elaborate on-- >> Actually, it's been a collaboration between the two sides, so-- >> Okay, explain, explain the partnership. >> So, absolutely, it's actually a collaboration. So, we've been collaborating to build this integrated architecture, right? It is a Cisco solution, but developed in collaboration with AWS, right, and so what we've been doing is fundamentally looking at how EKS was going to available to the container platform-- >> Mm-hm. >> Right, so that you'll be able to fundamentally orchestrate your containers in the most efficient way, regardless of where the containers actually end up being, which is actually what we're hearing from customers. Customers want to just take the containers that are coming from the developers and be free to develop whatever they want. Sorry, to deploy whatever they want. >> So, the containers are key here. So, the container service-- >> Yeah. >> And Kubernetes, which orchestrates containers, works across with the identity layer allows for, what, seamless interaction? Is that the key for developers is that I can... Take me through a quick use case. Explain it with an example. >> I don't know, you may take a new application in the banking, on the banking side, or you can take some new artificial intelligence kind of applications, or machine learning. What you fundamentally can do now is deciding, well, first of all what kind of tools you want to use. Do you want to use the AWS cloud with all the development tools, do you want to use yours? It doesn't matter, at the end there is an endover between the developers and the IT operations team, and the IT operations team, now with this solution, can fundamentally, quickly and easily provision clusters wherever they want, right, and they do it on the basis of their specific parameters, their specific goals, what do you want? It could be cost, it could be security, it could be reliability. Whatever it is, right? >> Mm-hm. >> It doesn't matter, this is not about the religion of whether it's public cloud or on-prem. It's just using the best of both worlds and deploying wherever it makes sense. >> You know, Andy Jassy and I always talk when we, at re:Invent. He always comes back to the same refrain, he always hits the same notes: "We listen to our customers, we're driven by the customers. "They take us where we want to go." >> Yeah. >> I know Cisco's been very customer-centric as well. How is the customers' reaction? What have they been telling you around why the solutions to develop... I mean, because we know Shadow IT's been going on with Amazon-- >> Yeah. >> For, you know, almost a decade. They put their credit card, they sneak up on Amazon, build some stuff, and look how easy, and then bring back to the IT department saying, "Hey, look what I did in the cloud, now you implement it." "Whoa, we've got network policies." So, there's been kind of that kind of tension, kind of R&D, if you will-- >> Yeah. >> But it's still happening. That kind of goes away here with this kind of announcement. How is the customer needs been profiled as you look at the announcement? What's the key reasons why they want this solution, and why did Amazon glob onto it, because they're not going to do something unless-- >> Yeah. >> It's a customer need. >> Yeah. >> Talk about that. >> Well, I would say, you know, it's really meeting the customer where they are, right, and again, we have two environments that, you know, have been inspired by different kind of criteria, right? There's a lot about application modernization, there's a lot about security, all about compliance on-prem. Of course the cloud is also very secure. I think we're over these kind of artificial discussions, but as AWS will say, it's a shared responsibility model, right? They guarantee the security of the cloud, and you're responsible for the security in the cloud, and so ultimately what people want to have is how can we actually integrate these two worlds in a consistent fashion, right, so that I have a consistent environment. That's really the keyword here, consistent environment where I have comomino networking between these things, wherever they are, comomino securing them, including authentication, identity and authentication, comomino monitoring this application, because the alternative is building another silo, and that's what people don't want to do. >> Mm-hm. >> Right? If I add another silo I may add innovation, but it comes to a very high cost. >> Yeah. >> People want to add innovation without disruption. They want to have this consistency and just extend the way they do things, of course going into a devops model and getting faster and faster, because that's the way to compete. >> Now, I think IT operations is an area, with the development enablement you guys have had, and with the work you guys have been doing DevNet and DevNet Create, this notion of programmability-- >> Yeah. >> You're right in line with the wave that everyone wants to ride, which is lower the cost of mundane tasks and/or scripts and things of that nature, command line interface, that's kind of like a hodge podge, make the network programmable and automate, and make the developer freer to do better things seems to be the trendline, so with that in mind, does this fit that horizontally scalable vision of the cloud? Do you see this having impact into say network sales, application, where's the key impact points for the customer, what impacts them? >> It's a huge impact, right, and depends whether you're taking like a tactical view of things, like literally application by application, or classes of application, or you're really thinking about where is this trend kind of taking you, right? Now, if you take the former kind of approach, then you're starting kind of identifying a whole bunch of different issues, like again, for instance the security one. The networking one is huge, right? People go, I don't know, Office 365 and they get disappointed. Why, because all the traffic gets tromboned through the data center because that's how things were. >> Choked them. >> Right? Now you're completely changing the application on top, and you discover that the infrastructure underneath hasn't been designed to accommodate those kind of traffic flows-- >> Yeah. >> Right, and so you're starting solving problem by problem. The fact of the matter is with the rise of the cloud the infrastructure and the processes in IT need to change altogether. Its infrastructure, its processes with of course the rise of devops, its relentless automation, right, potentially driven by, you know, more and more machine learning, and you know, AI kind of capabilities unfold. >> Just talk about that, because this is a big discussion, because I'm interviewing a lot of CIOs or CXOs or senior IT practitioners, and the ones that are successful are the ones who recognize the wave. Some people take different steps, they'll experiment, they'll do some tests. Some will just go all in and revamp, but they all recognize the one point. They've got to re-architect and re-imagine-- >> Yeah. >> The It infrastructure-- >> Yeah. >> Up and down, and the cloud is a big force and function-- >> Yeah. >> A role of data, programmability, automation. Now new concepts in some cases. Containers we all have been around for a while, but how do you guys talk to your customers, because this is something-- First of all, do you believe in that, and two, what do you talk to your customers about when you're saying, "Look, the hard truth "is how we got here is not how we go forward." >> Absolutely, well, you know, there are different ways. You can either boil the ocean, or for instance you take a solution like this. If you take a solution like this, you can actually sit down and discuss how to build a solution and architect a solution like this in collaboration with AWS. It took establishing four key principles, right? The first one has got to be hybrid, right, which means you need to strive to build this consistent environment between the two domains. Second, it has to be production-grade. We're speaking with customers adopting Kubernetes. They're saying that they get to a point where they need to integrate 20 opensource tools. Now, I wonder whether that's going to take you anywhere over the long term once you scale, you know, your operation. Can you actually do it with that kind of approach? Third, and this is a big one, you have to be able to manage this new hybrid reality, managing not just the new apps, but the old apps as well, and fourth, it's got to be extensible. You're starting from, like-- >> Yeah. >> Containers and authentication, how about everything else, right? How about cloud management and orchestration? How about application performance management, because now apps are getting everywhere, and of course, you know, that's probably the next episode of theCUBE that we can do together, they're going to the edge. >> (chuckles) Yeah. >> So, it's getting very, very complicated. So, even with a simple, well, "simple" example like this, you're starting seeing some principles that you need to establish, and that should inspire how you actually transform your infrastructure and operation. The worst thing that you can do is taking a tactical approach and just going step-by-step, and then, you know, move by move. >> Well, let's definitely do that CUBE. A couple of segments we'll have to do more of a deep dive with some slides. Certainly the edge is going to be a big point, but I want to ask you the impact to your customer base, because I think this is a game-changing announcement. I mean, Amazon Web Services, they don't do a lot of Barney deals. They don't do, you know, a lot of deals that look good on paper. They're very specific about how they do their business development, so it's a huge win for them, I think, and for you guys, but I think Cisco customers are going to be impacted, so please explain the impact to Cisco customers. What does it mean to me, I'm a Cisco customer. I've got routers, I've got switches, I've got UCS servers. I got all kinds of stuff in there. How does this impact my life, what changes, do I throw away gear, do I buy new gear, do I buy software? How do I buy the service, am I buying Amazon, do I have to now... Explain all that, how does the customer engage with the solution, and what's the impact to their environment? >> Well, that's a very big question. (laughs) Let me frame it a little bit, right? First of all, how are they impacted? They're impacted by the cloud altogether, right, and very often they're using multiple clouds, so we know it's multiple services, so they need to start thinking in terms of those principles that we said before. From a company standpoint, of course we've been well known over the last 30, 35 years, right, not to leave everybody behind. We're trying to, of course, accommodate the change of the infrastructure, and for instance, how do you move from CLI to more programmability through, for instance, you know, the rise of IBN, which is the intent-based networking where you have more policy-based models that help you fundamentally automate in the network, whether it's about, you know, connecting your data centers or connecting your branches, you have to fundamentally adopt more and more automation into your strategy, and so what we're doing is we're fundamentally helping customers making this kind of transformation. You mentioned DevNet, I think that's like the tip of the iceberg of also a new Cisco wave, right, where it's all about, if you want, transforming the talent that's been working with us in the company and outside the company, and having them taking it to the next level where instead of, you know, going classic CLI you're more and more kind of thinking in an automated fashion, because you have to get fast. The only thing that really matters is getting faster. >> I noticed you guys aren't just... Give you guys a lot of props here because you guys have a lot of meat on the bones with this announcement. Simplifying container orchestration with the Cisco hybrid solution for Kubernetes on AWS. You know, Linux Foundation wants to see it that way, Amazon's that way, but you guys have a lot of code up and running on the Sandboxes, and for the folks watching, developer.cisco.com/aws. developer.cisco.com/aws. You already got Sandboxes up already. >> Absolutely. >> Five labs for cloud native, you got the EKS-- >> Yep. >> Cloud thing up and running. >> Yeah, and we'll continue adding more and more material. The cloud is a different world, right? People want to experiment it, and by the way, if you think about how we're packaging and pricing the solution, you can actually start in a very modular way, right? You can just go with the software if you want, or you can buy the software and the hardware underneath. You can go with one, three, or five years. You can get demos of the solution. If you want, it's a different way of experimenting Cisco, but we're there. I mean, we made the change. We're totally for adding a softer motion to an already strong kind of hardware component that has been traditionally our strength, and if you think about it, having the full stack we can do some magic. If you buy Cisco software, like this solution, and then you put in Cisco hardware, such as HyperFlex and ACIR data center infrastructure-- >> Yeah. >> That a lot of customers are using you get fundamentally greater performance, you get a single number to call-- >> Yeah. >> Which is actually great. >> You know, it's interesting Fabio, and I talked with Lou Tucker years ago and then, well, continue to talk to him every year, as well as Susie Wee, and we see this on the cloud native, born on the cloud side, IT doesn't exist in a lot of these cloud native companies because the developers do all the IT, so you guys are seeing a surge in DevNet and DevNet Create where the Cisco ecosystem, your customers are turning into developers naturally-- >> Absolutely. >> And so we've seen that shift at Cisco-- >> Yeah. >> And that has happened internally. You guys recognize that the developer ecosystem, not the cloud native, but the application developers and-- >> Yeah. >> That your command line interface guys-- >> Yeah. >> And gals are turning into developers because-- >> Absolutely. >> Slinging code these days is pretty straightforward. >> Absolutely, if you look at our, actually my friend Susie Wee and how she is pitching this change. She talks about DevNet ops, others talk about DevSec ops. Whatever that is, you know, whatever kind of terminology you're using, it boils down to the same concept. You have to automate the way that you manage the infrastructure, right? >> Mm-hm. >> Infrastructure needs to become more responsive and faster. You can open five or six trouble tickets just to provision, you know, a container to a developer that's not going to carry it in the future. >> Yeah, it's kind of against them. >> It's got to be fast. >> Yeah, and then, you know, making the network programmable is the devops movement that's coming 2.0. >> Absolutely. >> And you guys are aware of, I know you are. It's interesting to see how Amazon relates to that. When you talk about that to AWS, what's the conversation like? Do they like, they obviously get it, and they're smart, they must get it immediately. >> I mean, absolutely, the reason why we're having this collaboration is very simple. I mean, they get the same requests from the customer. We're fundamentally speaking to the same people. Yeah, there may be differences sometimes, you know, the developer versus the IT operation, but in the end it boils down to the request, "Hey, you know, the public cloud is fantastic, "but I also want to have a solution for on-prem," right? "I have my needs," and if you're not totally burned into the cloud you have to, you want to have investment protection. You want to have, you know, your on-prem environment for whatever reason, right, and it's not about religion, it's about economics, it's about, you know, viability of certain solutions and the likes. >> Well, great news, congratulations. Fabio, great announcement with Amazon Web Services, good deal, hybrid cloud. Now, you guys, also at Cisco, you guys aren't married to one cloud, so I've got to ask the hard question. With impact to Google, Microsoft, you guys have relationships. How does this match up from an integration standpoint with other clouds? Is it deeper, is it more coming on the other clouds? Can you just kind of give us a description of the evolution of Cisco with the other clouds in this hybrid architecture? >> You know, I want to stay true to one of the principles that we mentioned and we orbited around this conversation, right, for the last 15 minutes, and that is we're customer-centric, right? Customers want to use the clouds that they want to use, we're there to help them, right? Now, AWS is of course, if you look at the share it's a pretty big market leader, but we will work with all the providers that our customers want to use. That's actually the North Star that we have. Now, if you look at the kind of, if you want, products or stacks or architectures, you will see that there is a huge degree of commonality across all of this, right? So, we're using kind of the same baseline software, but configuring slightly different ways for a, different way, for a simple reason, right, because the clouds are different, and not just the clouds are different, the cloud providers are different. So, we're paying full respect, you sit down, you discuss objectives, and then you actually go after those goals. >> Yeah, you just got to get out there and do those... You got to just do the work and integrate in. >> So, you have to expect a slight degree of integration-- >> Yeah. >> Because of the nature of the cloud business and the cloud providers, but I think when you look from a customer standpoint, what they want and what they're asking Cisco to do, they want to have commonalities. >> Mm-hm. >> Right? They want to have the same mean of networking, the same mean of securing these environments. They want to have the same way of extracting analytics, especially for application performance, and they want to have comomino managing and orchestrating all of these resources because the alternative is fundamentally getting lost into different tools and different clouds that by design cannot work in other environments, and so that's what customers want, and that's what we're pursuing as a company. >> Fabio, talk about the announcement in terms of just summarizing it real quick. You talked to a lot of customers, you've been doing press tours all day today, analysts, financial Wall Street, all the whole nine yards. Now you're here on theCUBE. What's the summary, what's the big walkaway looking back now after the announcement? Talk about the impact, what is this about? What is actually happening in your mind? How are people reacting to it, how big will this be? >> You know, I have two things in mind when I give myself that kind of question, right? The first one is I have this concept in my mind of making Kubernetes the engine of your innovation, right? This is about really transforming this new container orchestration technology that sounded esoteric until (chuckles) a few months ago into the cornerstone of the innovation, right? We've been talking about hybrid for a long while, but we believe that it's about mostly taking the best of the public cloud and making it work on-prem, rather than going the other way around, that's for sure, and I would say in general is this is a big first step into closing that gap between the infrastructure and the applications, which is kind of by definition closing the public cloud, but when it comes to the on-prem world we're still pretty far away, right, and so clearly there's a lot of competition in the marketplace, and we want to win that battle to close this gap, and closing that gap means fundamentally enabling customers to innovate and developing their new digital experience faster, and that's actually the nature of their business. >> Yeah, and they get value. >> It's not an IT conversation anymore, it's a business. >> And the value extraction and creation from new applications, and I think you've got to give credit to the Kubernetes community, because what's great about Kubernetes and then watching that evolve. We were there-- >> Yeah. >> theCUBE present at creation when it started, you know, hanging around OpenStack and all the different activities around the Linux Foundation before it went there, was that you had containers obviously happening, but the industry got behind kind of a defacto standard. >> Yeah. >> We've seen this before, TCPIP sounds like one of those things that just became a defacto standard and then it became a standard-- >> Well, another example with Linux itself, right? I mean, once, you know, big companies started going behind it and offering enterprise cloud support we saw really very, very rapid ramp-up. I think we're seeing the same with Kubernetes. I think now there are a bit less doubts about where the world is going. This is a clearly a winner, and people, I think, are now-- >> Yeah, and it's clear you guys are getting behind it. It's just Amazon doesn't do deals, like I said, unless it's a serious thing, so congratulations. You guys are getting behind Kubernetes. >> Yeah. >> Congratulations. >> Yeah, thank you for that. >> All right, Fabio Gori. Here inside the studio with Cisco, breaking down the hot news, game-changing news, Cisco's partnering with AWS with Kubernetes to really bring a level of industry standard and seamless integration between on-premises and the cloud, and excited to keep bringing you more action. Coming up we're going to be at the CNCF event, Kubcon, check us out there and also Amazon re:Invent, theCUBE will have multiple sets there. I'm John Furrier here in Palo Alto for this CUBE Conversation, thanks for watching. (techy music)