 Okay, welcome back to Docker Mainstages, the CUBE coverage of DockerCon 2022. I'm John Furrier, host of theCUBE. We're here with a special segment with Sneak. We've been partnering with Docker going back to the early days, cloud native container, vulnerability scanning within Docker desktop in 2020. We've got Mick McCulley-Field, strategy to sneak. Mick, thanks for coming on theCUBE. Thanks for having me, glad to be here, excited to have this conversation. Yeah, love the background, got a big football fan myself and love that little mention there. Love the Sneak logo too, good plug there. But I want to get into that of the security. You guys, one of the first conversations was when shift left was hot, when it just started to come and it's never going away. But now there's been a huge focus and an increase of concerns around vulnerabilities within and within the supply chain of security software. So in open source software. So what are you guys doing now? Cause this is a new focus in the industry. Everyone's talking about it. Your company's making changes to mitigate that risk. What do you guys have? Yeah, that's, it's a great question. And shift left is definitely a big focus of ours, right? It's what sort of our core foundation is what we based our whole approach to. Software supply chain definitely has made its way to the top of the spectrum as far as conversations. And I think it plays very well into our focus. You know, one of the things that I believe a lot of organizations are focused on is trying to get ahold of an understanding of a lot of the implicit trust and risk associated with everything that goes into building any sort of modern application. And that's all of the components that are being used everything from the open source to the containers that are consumed to the process and to all of the ecosystem and tooling that's consumed. A lot of the trust layers in there it's extremely important to understand what that is. What's the risk, right? And from a sneak perspective, taking that intelligence and trust and giving it back to the developers when they're making these decisions is our focus. Like that whole concept of taking all of that security expertise and pushing it back to the individuals making those decisions. I think it's probably one of the more powerful ways that you can start to implement some more security controls and get some trust and understand your risk process throughout that software supply chain. Okay, so you said trust three times. I'm going to come back to that because shifting left is all about empowering developers but what good is shifting left if you got to stop and then go back and research something that wasn't in your pipeline or something else happened. So open source obviously is growing like a weed it's continuing to exponentially grow and more people are doing it commercialization as well. But the word trust is not zero trust. You're hearing people use the word zero trust security. That's different, right? They're talking about developers looking for trusted code. So it's interesting. You've got hackers and zero trust and you got developers and trust and you got software in between. This is kind of the core issue here, isn't it? It is because of that using, I mean, there's huge advantages with all of these new approaches, right? Leveraging the open source and the containers and the software packages and these ecosystems to automate a lot of those software processes. But doing so means that you've got this implicit trust that's there. And so taking and trying to identify and share those details with the developers when they're making those decisions but it doesn't stop there, right? Like that's one of the other important aspects of this is what organizations have to do is to not only provide that and help those individuals when they're making those decisions but then constantly understand if that posture changes at any given time, right? And knowing where it's happening, what it is and how do I prove and have some of the providence details of the origination of the information? How can I trust to make sure that the security was accounted for all the components that I'm actually leveraging and using and then making sure that you have that visibility throughout the entire life cycle. That's probably one of the other important areas. So it's not only sort of giving that information and details and trying to take advantage of all of that early detection response and decision-making process but it's also maintaining that understanding of what that is and that trust plays into that, right? There's so much implicit trust associated with it and the more that you can understand it, comprehend it, take control of it, the better your organization from a security posture is going to be. Yeah, I mean, you got builders and attackers. I mean, it's clearly the spectrum and the builders want the 100% trust and I think this is going to be such an important game-changing topic that has to be addressed. It's the only way with the scale you're seeing and the growth of the software. And by the way, open source has become much more than just open source. It's community, it's social, people kind of hang out and build code together and then ventures are being started up. So this is a nice progression, makes a lot of sense. I have to ask you though, what's some of the data say on the attacks? Is it increasing at what rate? What's the complexity look like? What's it look like as it evolves? Because, you know, even though it's your trust on one side and trust on the other, the attackers also adjust too. Yeah. So what's the- I think it's a great, yeah, it's a very good question. I think that's what we're seeing is this is just a natural evolution. I think there's been, you know, an historic focus on a lot of the security associated with running applications and locking them down. And I was reading a blog just by Docker the other day about how it's like this hardened sort of outside layer, but there's this soft squishy inside. That soft squishy inside is all of those building components that are inside of there. And because of that hardened layer, it makes those attack vectors a little bit more difficult, right, when you're trying to penetrate those. And so what we've seen is this natural evolution is say, well, let's go find the weak link. Let's go understand if there's a way to actually bypass these security controls. And sometimes the ways to do that is to simply go upstream into the process in which the application's being built. If I can go upstream and actually change some of those components and implement my attack inside of the application, it automatically gets embedded instead of trying to attack it directly. And so we're seeing that and it's what's making a lot of the news and why some of the conversations around software supply chain are becoming very prominent. It's this ecosystem and unfortunately, in a lot of organizations, that I think some of that development area hasn't had that security focus as a lot of the traditional areas associated with applications and exposure of your organization. Because of that, it's left a little bit more exposed, right, that trust that we talked about in addition to the processes has to have a little bit more of that security ingrained inside of those processes to make sure that it's not being left open. It's not an open door or an open window that's giving sort of an easy route into the application. Yeah, totally, I totally see that. And the last couple of minutes we have left, I want to get into what you guys are doing with your customers and what are companies doing to mitigate the risks in the software supply chain? Obviously, open source is not going away. It's only going to be part of it. What's going on with the customers? Yeah, it's a great question and a big focus of ours is to help organizations understand all of those areas as much as possible, right? And to provide them that guidance. And part of this is not only the solution and how we deploy it and how we can deliver it, but it's some of the security intelligence associated with it. Instead of putting the burden on our customers of trying to stay on top of all of that risk, right? Where is all of these different moving parts? And something changes from being completely fine one day to a high vulnerability and risk posture. How do you react to that? And so providing as much of that insight, guidance and prioritization and the details to those organizations in an actionable format. That's probably one of the more core elements to this. It's not just the, hey, here's a whole list of all your problems. It's what do you do? Like how do you take all of that information, those details, those risks? Why do you prioritize them? How do you then, what's the steps that you take from an action perspective in order to address those, right? If I've got a container with some problems, what is sort of the recommended approach to solving that? What should I upgrade to? What is the guidance associated with those? And so a lot of it is focused on providing not only the insight and the ability to react and understand that risk at any given time, but also more focused on what do you got to do, right? How do you actually take steps to alleviate or remediate that risk as much as possible? Can't know. That's a good point. So I got to ask you, what's the difference between getting it right and getting it wrong? Or in other words, why do some supply chain vulnerabilities remain fixed, unfixed and de-prioritized? What's the, why isn't it going faster? Yeah, and some of that there's reason to cross the board, right? Some of it cross from the perspective that there might not be fixes. And so in some of those cases, just being aware of what that risk is so you can put in other mitigating controls in order to accommodate those. In other cases, it's prioritizing where your risk is most important, right? And part of this also stems from the fact that if you fall into sort of that reactionary bucket, then you have to be in sort of that prioritization reactive mode. The more that you can push this back to that early process, the less that that has to occur because you have the ability to actually make the best decision possible with the information you have during that early process. So some of it's just predicated on the fact that there's not always solutions to all the problems. And then a part of this too is where in the phase are you actually starting to attack and handle it? All right, Mick, thanks for coming on. Really appreciate it. Business is good, it's neat. Thanks for sharing your insights here on the main stage. Okay, this is theCUBE. Back to the DockerCon main stage. We'll be back more, see you soon.