>>Hello everyone. And welcome to the cubes presentation of the AWS startup showcase open cloud innovations. This is season two episode one of our showcase ongoing series. We're covering very exciting startups from the AWS ecosystem. And we're going to be talking about the open source community. I'm your host, Lisa Martin. And today I'm excited to be joined by Robbie, Myra, the head of product and partner marketing at sneak. Robbie's here to talk with me about developer security for your digital transformation. Robbie, it's great to have you on the cube. >>Thanks Lisa. Nice to be here. >>So talk to me about what's going on in developer land. They're under a lot of pressure. A lot of them are building apps with open source, but what does sneak seeing from the developers lens >>From the developer's lens? There's a lot of pressure to build fast and that's probably the biggest challenge, right? We're in a world of digital transformation where everybody's trying to compete no matter what industry you're in, right on the technology and on the quality of your software or the capabilities of your software, which puts a lot of pressure on developers to build fast. That causes them to do a few things. One, it causes them to build, to develop in a way where they're doing constant iteration and so models that would have enabled a security check to come in at the end, aren't working anymore because they don't have time for those security checks. And it also causes them to do a good thing, which is to leverage other people's code when they can like open source. So they can just focus on, on their own functionality. And that's true, whether they're building new functionality or modernizing legacy applications by moving them to the cloud. >>So it's a high percentage of, of app code 80 to 90% is open source. Then that opens up. Talk to me about w where the vulnerabilities are and how you guys help customers and developers address that. >>Yeah, the vulnerabilities can be anywhere, but the key is that that point, right? If you're using open source in a typical application, 80 to 90 plus percent of the lines of code in that application are going to be open source code, their code. Somebody else wrote that you don't have a direct relationship with, and yet you own the risk that whatever they may have, whatever vulnerabilities may be in their code, you now own that risk. So what we're trying to do with sneakers, trying to do is enable developers to leverage open source, but do that securely. And then we also help them with the 10% that they rent as well, and, and do that all in one really easy environment for a developer that fits into their workflow and into their daily life. >>So security should shift left. I've had the chance to talk with a couple of, do you call them sneakers sneakers? Oh, you do a couple of sneakers recently. We've talked about security shifting lab. That's not a new concept, but I'd love to dig in more to how sneak and AWS do that. And I'm also curious if what you're doing helps. We've talked about the cybersecurity skills got for a long time. Now, just what you guys do, help address that >>It does because it's really leveraging a resource that, that is there, right? There's the number of developers worldwide is growing from, depending on who you believe for these numbers and their estimated numbers, right? But 25 million to 50 million over roughly a five-year period that's already started. So we're somewhere in the 30 now, right? Meanwhile, the security jobs, there's something like 9 million cyber security people in the world, and that's all cyber security roles. It's a much shorter, a smaller chunk that are application security folks. And there's three and a half million unfilled cybersecurity roles. So you can't get cyber security people and keep using the current model you're using. But just scale it linearly, you have to change things. And sneaks belief is the way you change things is you have the developers be part of your security solution, which means they need to have the ability to not only develop, but to develop securely. And that's our concept of developer security. We build tools and a platform that enables developers to be the first part of the security solution and enable security teams rather than individually auditing and fixing things to develop a process, govern the process, guide the development teams, but let the developers own that first step of security. And that's really how you solve that scale problem. >>When you're talking with customers, is this kind of a better together scenario, developers and security folks? Are you helping them align culturally because this is a change? >>Absolutely. I think one of the biggest misconceptions out there is that there's a tension between security and development. And I think that's because organizationally there might be right. Security is responsible for risk and developers responsible for speed of innovation and the faster you innovate, potentially there's more risk. So there might be some organizational tension, but at the human level, people understand each other, they understand the pressures that the other one's going through. They just don't have an easy way to work together. And if you can help them get that, then they, it really takes off it. The relationships form they'll build human to human programs like security champion programs and things to, to integrate the teams because they're both going after the same goal, both sides want to build awesome technology and grow in whatever market they're in. >>Right. And of course, with the need to do that at today's markets speed and scale is a great thing that you guys are doing to facilitate that collaboration. And of course the security let's kind of take a double-click now into the different integrations that sneek has with AWS services. I know there's quite a few, >>There's quite a few. The biggest one, probably the easiest one for the integrations is the native integration that we have with code pipeline. So it makes it easy for developers as they're finishing their builds and deploying to have an automatic security check that comes in, understands if there's things that need to be fixed before this really should be released, and then they can fix it and go forward. But we integrate across with our API across a lot of other services, ECR EKS code builder, so that wherever the developer is working, there's a way for us to integrate with them as they're building across their AWS development process. >>Okay. So giving them plenty of opportunity, let's dig into the platform. Talk to me about the platform, how it's really aimed at developers. You alluded to this a little bit, but I'd like to kind of take a double-click into the technology. >>Sure. That the platform, it, part of it is that idea of it we've wrapped it all as a developer tool. But the thing that makes sneak unique in this is not only we have the idea that we wanted to shift left in time, but we wanted to shift left in ownership. So the developers are primary user and we built a tool that is a developer tool that happens to do security. And we've extended that tool into a platform by enabling it to connect into the developers tools, sharing information, across different elements of what it securing. So for example, the open source that we're scanning for you and testing to find for vulnerabilities, we're also looking at the vulnerabilities in your code and where they may overlap or intersect. We can adjust priorities so that you might not need to fix something. Let's say you're using an open source, vulnerable, a package that has a vulnerability, but your code is never going to access that you don't need to fix it. >>So you can prioritize that one lower, right? Same thing with Kubernetes and containers. You may have a container vulnerability, but the way you're going to leverage the container that won't be used so we can adjust the priority to make it easy for the developer. And that's the other big thing that's different about a developer security platform than a typical security tool. A typical security tool is an audit tool it's designed to output. Here are all the things you have a problem with a developer security tool is a fixing tool. It's just defined as a, here are the problems you have developed with here's how you fix it and go back to building on that. That prioritization is a big part of that, because you can say, here's what you don't need to worry about. And then you can focus the rest of your energy on helping developers fix the problem either by giving them really good advice or automating it for them and saying, Hey, here's a button click that will generate a pull request. And your problem is this fixed. >>It must go a long way to improving developer productivity, one facilitating that speed and the agility with which they need to work, but also from a developer kind of crowd sourcing, crowd swell perspective. I imagine, talk to me about what some of the voices are, the developers that are in your community. What are some of the things that they're saying in terms of how much faster they're able to work, they're able to get those priorities established with automation so much faster? >>Well, that's the biggest thing. Is there a, the productivity gain happens because of the benefit of shift left, right? You're testing earlier. You're finding it at an earlier time when it's easier to fix, but that's because they're the ones doing it, right. If they're waiting to hand off to an auto report and then it comes back, even if somebody is, is giving them them audit faster, it's still after they've moved on. And the other way people try to solve it as well. They'll say, well, I'll take a security tool then to hand it to the developer and they can run it. But so developers are not security experts. So the tool needs to understand what they know and what they don't know, and, and working in an upload. And that's what developers generally say to us because sneak makes it easy to work, but also focuses on the fix and helps them guide them to that, to that answer. Then they're able to go much faster when we're evaluated by companies who are looking for a security solution. If the developers get involved in that evaluation, they'll choose sneak. >>So I'm curious a little bit about as, as the head of product marketing, I'm thinking customer advisory boards, things like that. What's the collaboration like between sneak and the developers to really tune and push the technology forward. I imagine it's quite collaborative, >>Quite collaborative and it's across a lot of, of spectrum. So we do have a customer advisory board and that's generally leaders, right? That's either security leaders or development leaders or operations leaders who are in that advisory board. And they're giving us input on things they need for program-wide governance or program wide adoption. We also have a developer community where we're talking directly to developers and that's where we get a lot of, Hey, here's how I could use this better as a developer. And that guides where we focus features that help developers work better, whether it's integrations with our IDs or whether it's the way we present information, help them prioritize. And then the third part is we have a lot of people using the tool because it has a free model, right? We're as a developer tool, we have a freemium model. There's a level of sneak that developers can use that they don't need to pay for. That's not a temporary trial, it's forever. If you want to use it at that level and we can observe what they're doing. So that observability gives us another insight into where folks get challenged run into, to struggles. And then we can look to address those in our roadmap as well. So, so all of that together really helps us drive the product forward. >>What is the perspective from the analyst view? You talked a little bit about the perspective from the customer. We'll get into a customer story in a bit, but I'd love to know what are the gardeners saying? >>Well, Gardner especially put us, we debuted in their magic quadrant for application security last year. And we did David as a visionary and sort of the highest part of the visionary quadrant you could get in before you crossed over into leader, which is kind of unheard of for a first time into the, into the quadrant. And the main reason for that is that they have built the way those, those magic quadrants are built is they have key capabilities and then they score companies against key capabilities and they weight those capabilities, you know, by order of importance. And Gardner has started to put some of this notion of developer security and cross cloud native application security into those key capabilities. And those tend to align really well with what sneakers. So they have a, for example, a software composition, which is sort of open source security analysis, where first, w w w where the top ranking in that, where the top ranking and container security, where the top ranking and developer enablement. So that's pulling us, they are so-so Gardner and the analyst community is seeing this same demand coming from their customers. And that's really aligning to where our vision is. >>And in terms of kind of propelling that vision forward, the voice of the customer, the voice of the analyst, aligning with what you guys are doing to kind of lead the vision going forward. I want to get into some of the intelligence before we kind of break into a customer example. Talk to me a little bit about snakes security intelligence, what the key capabilities are, and some customers that are leveraging it. Sure. >>The biggest thing is with all the developer tool wrapping that needs to be in this product than it is a developer tool. It's got a developers heart, but it has to have a security brain because it still is a security tool. There are some developer tools. We try to have little check the box capabilities of security and they'll crowdsource for vulnerabilities potentially. But if you're doing this, you need to make sure that all the vulnerabilities that could be found are in the database to be able to be found that the database is comprehensive, that it's timely. They get in very quickly that it's accurate. You don't waste time on false positives because that will turn developers off faster than anything. And that it's actionable. So when it does find something, it helps you go forward with it. And that's where sneaks really focused on. So we collect data from multiple public sources. >>We also have a fairly large proprietary research team that curates that information determines what needs to go in. Sometimes we'll adjust priorities. And we also get a lot of contributions from other sources like community contributions. Again, that big free user base of ours is giving us input academia. Open source groups are also in their social media trends. So if we see something trending on Twitter, then that'll not only get it into the database, but it'll drive prioritization. And that's a big part of what's in sneak Intel, which is the name we use for our vulnerability database. We also have a machine learning algorithm. That's constantly looking at all the code in public, in public applications and repositories. And we use that to train for our own proprietary code testing tool, but it also just gets a lot of it finds things there as well. So it brings a really good source of information that helps people make sure you're finding the vulnerabilities, you're prioritizing them correctly and fixing them. And so Amazon's one who is the, you know, one of the folks that using that tool where one of the primary sources of, of Amazon inspector for open source vulnerabilities, as well as a bunch of other security companies like rapid seven tenable and, and others. >>One of the things I was reading from, I'm always kind of looking at the differentiators and I'm sure you are as the head of product marketing and partner marketing, but it sounds like the database can, is, is a key differentiator finding vulnerabilities up to what is it? 46 days faster than competitors. >>Yeah. I mean, faster than especially public sources, which are the easier ones to, to know how you're doing against, but that's a big part of us. So when I talked about those categories, that's really what we measure ourselves against. How are we doing in terms of comprehensive? Do we have the vulnerabilities that we should have? So we have over four times the number of vulnerabilities as the next largest publicly available database, we find them faster, so timely. So that's at 46 days getting it in faster or faster than other public sources, they get into our solution and then accuracy. Again, we, it's not a stat we can test because you can't test it just from the database. You have to run the tools of our, of others in this space. And we don't have those, but making sure that you're not hitting a lot of false positives is a big part of it as well. >>Got it. Okay. And we only have a couple minutes left, but there's two more areas that I want to dig into with you just crack crack. The surface one is log four, shallow was reading. Snake says this. We were the perfect solution at the perfect time. Unpack that for me in the next minute or so. >>Yeah. And that's a bit, and it kind of wraps back to what we were talking about earlier. Everybody's using open source. If you're in the Java world, a lot of folks had logged for shell and we're using lock for shell for logging as a part of their, as a part of their applications. And so a lot of our customers, I think it was over 30%, 36% of our paying customers had the vulnerability. And you would only have the vulnerability of your Java. So it's a very large percentage of our Java using my customers had the vulnerability, but because they were using sneak, they were able, once we put it in the database, which we did the day, it was disclosed, they were able to find it and fix it very quickly. So 91% of our customers fixed that vulnerability in just two days, 98%, because this was a rolling thunder event, right. There was a vulnerability. And then there was a second vulnerability in the, in the fix. And then there was a vulnerability, even in the fix of that. So the second vulnerability that came out because everybody had been ready for it from the first time 98% picks within two days. Whereas the median number of days to generally fix a vulnerability is over two months. So really fast addressing the solution. >>So those are really impressive. And speaking of stats, I wanted to get into just really quickly a case study that really shows that lasting is one of your customer. One of your many customers, big developer community there about 3,500 developers. Give me some kind of the high level of business outcomes that at Lasagne is, is, is achieving thanks to sneaky. >>Yeah. I mean the biggest one is that almost 99% of their applications are deployed in containers. So being able to have the containers tested for vulnerabilities as they're being deployed before they're being deployed is huge for them to reduce the risk of a vulnerability. They, they had a 65% reduction in high severity container volumes a few months after using sneak across all those developers, which really reduces your, your risk profile of your, of your cloud native applications. They're obviously a big AWS user as well. So, so for them, that was the big thing. And again, it goes to that scale, right? They've got 3 3500 developers, more than 3,500 developers. If you try to go through the security team and have the security team fixing all those things, you'll just never catch up. >>Got it. Last question. Where can I get this available through the AWS market prays marketplace? You mentioned the freemium model, give folks kind of a direction on where to go. >>Yeah. So I would say if you are a, if you're someone in the security team, if you're a buyer, the AWS marketplace is a great place to go because you can probably leverage your existing spend commits with AWS. It's easy to purchase, easy billing, et cetera. If you're a developer, then there is this free version where you might go and just start using it and get comfort for it. And if you are a buyer, talk to your developers because there's a pretty good chance. Someone in your company, that's a developer is already using. Sneak will be comfortable with it. These solutions are only successful. If the developers actually use it, you can't shift left unless the developers pick it up and use it. So using the one that developers are already using is probably a good idea. >>Awesome. Robbie, this has been a great conversation, so much momentum at snake. You're the third sneaker I'd gotten to speak to you in the last month and I have, it's pretty exciting, but thanks for walking us through the technology, the capabilities, the differentiators, the voice of the customer, the voice of the analyst, we appreciate your insights and your time. And we look forward to next time we talk to you. >>Terrific. Lisa, I look forward to it as well, but there's a lot more Smith sneakers to go through before you get back to me again. I guess >>I look forward to adding to my repertoire of sneaker interviews, Ravi. Thanks so much. Thank you for Ravi Myra. I'm Lisa Martin. You're watching this cube interview as part of the AWS startup showcase. Stick around more great content coming up next.