 From around the globe, it's theCUBE, presenting, Cube on Cloud, brought to you by SiliconANGLE. Welcome to theCUBE's event, virtual event, Cube on Cloud. I'm John Furrier, your host. We're here talking to all the thought leaders and getting all the stories around cloud, what's going on this year and next, today, tomorrow, and the future. We've got a featured startup here, Joni Klipper, who's the CEO and founder of StackHawks, developing security software for developers to have them put security, baked in from the beginning. Joni, thanks for coming on and being a featured startup here as part of our Cube on Cloud. Thanks for joining. Thanks so much for having me, John. So one of our themes this year is obviously cloud native has gone mainstream. The pandemic has shown that, you know, a lot of things have to be modern, modern applications, VMworld, all they talk about is modern applications, infrastructure is code. Reinvent is here. They're talking about the NextGen Enterprise. They're public cloud, then you got hybrid cloud, now you got multi-cloud. But for developers, you just want to be building security baked in and they don't care where the infrastructure is. So this is the big trend. Let me get your thoughts on that. But before we jump in, tell us a little about StackHawk, what you guys do, you're founded in 2019. Tell us about your company and what your mission is. Awesome. Yeah, our mission is to put application security in the hands of software developers so that they can find and fix app sec bugs before they deploy to production. And we do that through a dynamic application scanning capability that's deployable via Docker so engineers can run it locally. They can run it in CI CD on every single PR or merge and find bugs in the process of delivering software rather than after it's been deployed to production. So everyone's talking about shift left. Oh, shift left for security. What does that mean these days? And what are some of the hurdles that people are struggling with? Cause all I hear is shift left, shift left. I'm like, I mean, what does that actually mean now? Can you take us through your view? Yes. And we use the phrase a lot and I know it can feel a little confusing or overused probably. When I think of shift left, I think of that Mobius that we all look at all of the time in how we deliver and like plan, write code, deliver software and then manage it, monitor it, right? Like that entire DevOps workflow. And today when we think about where security lives it either is a blocker to deploying production or most commonly it lives long after code has been deployed to production and there's a security team constantly playing catch up trying to ensure that the development team whose job is to deliver value to their customers quickly, right? Deploy as fast as we can as many great customer facing features. They're then looking at it months after software has been deployed and then hurrying and trying to assess where the bugs are and trying to get that information back to software developers so that they can fix those issues. Shifting left to me means software engineers are finding those bugs as they're writing code or in the CI CD pipeline long before code has been deployed to production. And so you guys attack that problem right there so they don't have to ship the code and then come back and fix it again or we forgot what the hell's going on at that point in time some QA team gets it. Is that the problem that's out there? Is that the main pain point? Yeah, absolutely. I mean a lot of the way software specifically software like ours and dynamic application scanning works is a security team or a pen tester maybe is assessing applications for security vulnerability fees that are in prod. That's normally where these tools are run and they throw them back over the wall interrupting sprints and interrupting the developer workflow. So there's a ton of context switching which is super expensive and it's very disruptive to the business to not know about those issues before they're in prod and they're also higher risk issues because they're in prod. So we have to be able to... It's the wrong flywheel basically. It's like you have a penetration test is it okay I want to do ship this app pen test comes back okay we got to fix the bug interrupts the cycle they're not coding they're in fire drill mode and then it's a chaotic death spiral at that point. Right or nothing gets done. Got it. And that's the work. What was the vision? How did you get here? How did you start the company? You woke up one more time and started a security company and what was the journey? What got you here? Sure, thanks. I've been building software for software engineers since 2010. So the first startup I worked for was very much about making it easy for software engineers to deploy and manage applications super efficiently on any cloud provider. And we did programmatic updates to those applications and could even move them from cloud to cloud. And so that was sort of cutting my teeth in technology and really understanding the developer experience. Then I was a VP of product at a company called Victor ops. We were purchased by Spunk in 2018 but that product was really about empowering software engineers to manage their own code in production. So instead of having a network operation center who sat in front of screens and was waiting for something to go wrong and would then just end up dialing, just this middle man trying to dial to find the person who wrote the software so that they can fix it. We made that way more efficient and could just route issues to software engineers. And so that was a very DevOps focused company in terms of improving meantime to know and mean time to resolve by putting up time in the hands of software engineers where it didn't used to live there before. It lived in a more traditional operations type of role. But we deploy software way too quickly and way too frequently to production to assume that another human can just sit there and know how to fix it because the problems aren't repeatable, right? So I've been living in this space for a long time and I would go to conferences and people would say, well, I'd love for, we have these digital transformation initiatives and I'm in the security team and I don't feel like I'm part of this. I don't know how to insert myself in this process. And so I started doing a lot of research about how we can shift this left. And I was actually doing some research about penetration testing at the time and found just a ton of opportunity, a ton of problems that exist with security and how we do it today. So I really think of this company as a DevOps first company and it just so happens to be that we're taking security and we are making it just part of the application testing framework, right? We're testing for security bugs just like we would test for any other kind of bugs. Yeah, that's an awesome vision to have a great, great history there and thanks for sharing that. I think one of the things that I think this ties into that we've been reporting aggressively on is the movement to DevSecOps, DevOps, DevSecOps. And just doing an interview with the guy who stood up Space Force and big space conversation. And we were essentially riffing on the idea that they have to get modern, it's government, but they got to do more commercial. They're using open source. But the key thing was everything's software defined. And so as you move into software defined, then they say, we want security baked in from the beginning. And this is the big kind of like C level conversation. Bake it in from the beginning, but it's not that easy. And this is where I think it's interesting where you start to think DevOps for security because security is broken. So this is a huge trend. It sounds easy to say it, bake security in, whether it's an IoT edge or multi-cloud. There's a lot of work there. What should people understand when they hear that kind of platitude of, oh, just bake security in, it's really easy. It's not trivial. What's your thoughts on that? It isn't trivial. And in my opinion, there aren't a lot of tools on the market that actually make that very easy. There are some, you've had Sneak on this program and they are doing an excellent, really speaking to the developer and being part of that modern software delivery workflow. But because a lot of tools were built to run in production, it makes it really difficult to bake them in from the beginning. And so, I think there are several goals here. One is you make the tooling work so that it works for the software engineer and their workflow. And there's some different values that we have to consider when it's for an engineer versus when it's for a security person, right? Limit the noise, make it as easy as possible. Make sure that we only show the most critical things that are worth an engineer stopping what they're doing in terms of building business value and going back and fixing that bugs and then create a way to discuss and triage other issues later outside of the development workflow. So you really have to have a lot of empathy and understanding for how software is built and how software engineers behave, I think in order to get this right. So it's not easy, but we are here and other tools are here to support companies in doing that. What's the competitive strategy for you guys going forward because there's a big sea change now. I see an inflection point, obviously COVID highlights, it's not the main reason, but cloud native has proven, it's now gone mainstream. Kubernetes, you're seeing the big movement there. You're seeing scale be a huge issue. Software defined operations are now being discussed. So I think it's a simple moment for this kind of solution. How are you guys going to compete? What's the winning strategy? How are you guys going to compete to win? Yeah, so there's two pieces to that. One is getting the technology right and making sure that it is a product that developers love. And we put a ton of effort into that because when a software engineer says, hey, I'd love to use the security product, right? CISOs around the world are going to be like, yes, please, did the software engineer just ask me to use a security product? Thank you, right? We're here to make it so easy for them and get the tech right. And then the other piece in terms of being competitive is the business model. There was something like, I don't, you would know better than me, but I think the data point I last saw was like 1300 venture backed security companies since 2012 focused on selling to CISOs and Fortune 2000 companies. It is a mess. It's so noisy. Nobody can figure out what anybody actually does. And what we have done is said, no, we're going to take a modern business model approach to security. So it's a SaaS platform that makes it super easy for a software engineer or anybody on the team to try and buy the software. So 14 day trial, you don't have to talk to anybody if you don't want to. Awesome support to make sure that people can get onboarded. And with our onboarding flow, we've seen that our customers go from signing up to first successful scan of their platform or whatever app they chose to scan in an average of about 10 minutes. The fastest is eight, right? So it's about delivering value to our customers really quickly. And there aren't many companies in security on the market today that do that. You know, you mentioned pen test earlier. I hear that word and I shiver. I'm like, oh, pen test, penetration test, as it's called, sock reports. I mean, these are things that are kind of like, I got to do that again. I know there's people doing things that are going to be automated. But one of the things that cloud native has proven as be killer app is integrations because when you build a modern app, it has to integrate with someone else. So there you need these kind of pen tests. You got to have this kind of code review. And as code is part of, say, a purpose built device where it's an IoT edge, updates have to happen. So you need more automation. You need more scale around both updating software to a purpose built device or for integration. What's your thoughts and reaction to that? Because this is a real software challenge from a customer standpoint because there are too many tools out there. And every CISO that I talk to says, I just want to get rid of half the tools, consolidate down around my clouds that I'm working through, my environment and be more developer oriented, not just purchasing stuff. So you have all this going on. What's your reaction to that? You got the integration and you got the software updates on purpose built devices. Yeah, I mean, I make a joke a little bit that security land is like, you know, acronym stew. There are so many types of security that you could choose to implement. And they all have a home and different use cases that are certainly valuable to organizations. What we like to focus on and what we think is interesting in dynamic application scanning is because it's been hard to automate dynamic application for especially for modern applications, I think a lot of companies have ignored the opportunity to really invest in this capability. And what's cool about dynamic and you were mentioning pen testing is that because it's actively attacking your app, when you get a successful test, it's like a successful negative test. It's that the test executed, which means that bug is present in your code. And so there's a lot less false positives than in other types of scanning or assessment technologies. Not to say there isn't a home for them. There's a lot of, we could spend a whole hour kind of breaking down all the different types of bugs that the different tools can find. But we think that if you wanna get started developer first, you know, there's a lot of great technologies, pick a couple or one, right? Pick Stackhawk, pick sneak and just get started and put it in your developer workflow. So integrations are super important. We have integrations with every CI CD provider, making it easy to scan your code on every merge or release. And then we also have workflow integrations for software engineers associated with where they want to be doing work and how they want to be interrupted or told about an issue. So, you know, we're very early to market but right out of the gate, we made sure that we had a Slack integration so that a scans are running or as we're finding new things, it's populating in a specific Slack channel for those engineers who work on that part of the app and JIRA integration, right? If we find issues, we can quickly make tickets and route them and make sure that the right people are working on those issues. So that's how I think about sort of the integration piece and just getting started. It's like you can't tackle the whole, like every acronym at once, like pick something that helps you get started and then continue to build out your program as you have success. Yeah, a lot of these tools, they get in the hands of developers and then you kind of win their trust by having functionality. Certainly a winning strategy we've seen, you know, Splunk you mentioned, you worked for, DataDog, and there's a variety of other tools out there. Just get started easily. If it's good, it'll be used. So I love that strategy. Question I want to ask you, you mentioned Docker earlier. They've got a real popular environment but that speaks to the open source area. How do you see the role of open source playing with you guys? Is that going to be part of your community outreach? Does it feed into the product? Could you share your vision on how Stackhawks engaging and playing in open source? Yeah, absolutely. So when we started this company, my co-founders and I, we sat down and said, what are the problems? Okay, the world doesn't need a better scanner, right? If you walk the floor of a security conference, it's like, our tool finds a million things and someone else's, my tool finds a million and five things, right? And that's how they're competing on value. It's really about making it easy to use and put in the pipeline. So we decided not to roll around scanner. We're based on an open source capability called ZAP, the Zet Attack Proxy. It is the world's most downloaded application scanner. And actually we just hired the founder of ZAP to join the Stackhawk team. And we are really excited to continue to invest in the open source community. There is a ton of opportunity to grow and sort of galvanize that community. And then the work that we do with our customers and the feedback that we get about the bugs we find, if they're a false positive or this one's commonly risk accepted, we can go back to the community, which we're already doing and saying, hey, ditch this rule, nobody likes it or we need to improve this test. So it's a really nice relationship that we have and we are looking forward to continuing to grow that. Great stuff. You guys are a hot startup. I love the software and security angle. Again, DevSecOps is going to be really popular. Can you talk about some of the customer successes? What's the feedback from customers? Can you share some of the use cases that you guys are participating in, where you're winning? You mentioned developers love it and try it. Can you just give us a couple of use cases and examples? Yeah, a few things. A lot of our customers are already selling on the notion, like before we even went to GA, right? They told all of their customers that they scan for security bugs with every single release. So in really critical industries like FinTech, right? It's really important that their customers trust that they are taking security seriously, which everybody says they do. But they show it to their customers by saying, here, every single deploy. I can show you if there are any new security bugs released with that deploy. So that's really awesome. Other things we've heard are people being able to deploy really quickly to the Salesforce marketplace, right? Like if they have to have a scan to prove that they can sell on Salesforce, they do that really rapidly. So all of that's going really well with our customers. How would I be a customer if I was interested in using StackHawk? Say we have some software we want to stand up and it's super great and Amazon, Microsoft, Marketplace, Salesforce, they'll have requirements or say I want to do a deal with an integration. They want to make sure there's nothing wrong with the code. This seems to be a common use case. How do I, if I was a customer, get involved or just download software, what's the procurement, what's the consumption side of it look like? Yeah, you just go to stackhawk.com and you create an account if you'd like to get started that way. So you can have a 14 day free trial. We have extremely extensive documentation. So it's really easy to get set up that way. You should have some familiarity or grab a software engineer who has familiarity with a couple of things. So one is how to use Docker, right? So Docker is a deployment mechanism for the scanner. We do that so you can run it anywhere that you would like to and we don't have to do things like pierce firewalls or other protective measures that you've instrumented on your production environment. You just run it wherever you'd like in your system. So locally CI CD. So Docker is an important thing to understand. The way we configure our scanner is through a YAML file. So if you are getting a scan today, either your security team is doing it or you have a pen tester doing it. The whole like getting ready for that engagement takes a lot of time because the people who are running the tests don't know how the software was built. So the way we think about this is just ask them. So you just fill out a YAML file with parameters that tell the scanner what to do. Tell it how to authenticate and not log out. Feed us an API spec if you want so we can super efficiently scan your app and you can be up and running really quickly. And then that's it. You can work with our team at any time if you need help and then we have a really efficient procurement process. I mean, my experience with some of the pen tests for firms out there is it's like the house keeping seal of approval. You get it once and then you got to go back again. Software change, new things come in and it's like, wait a minute, what's the new pen test? And then you got to write a check or engage to have another meeting. I mean, this is the problem. I mean, too many meetings. Do you guys solve that problem? Do you solve that problem? We solve a piece of that problem. So I think, you know, part of how I talk about our company is this idea that we live in a world where we deploy software every single day, yet it seems reasonable that once a year or twice a year, we go get a pen test where a human runs readily available open source software on our product and gives us like quite literal PDF of issues. And it's like, this is so intellectually dishonest. Like we deploy all of the time. So here's the thing, pen tests are important and everybody should do them. But that should not be the introduction to these issues that are also easy to automate and find in your system. So the way we think about how we work with pen testers is run Stackhawk or Zap, right? In an automated fashion on your system. And then give that, give the configuration and give the most recent results to your pen tester and say, go find the hard stuff. You shouldn't be cutting checks for $30,000 to a pen tester for something that you can easily find in your deployment pipeline. You should write the checks for finding the hard stuff that's much more difficult to automate. I totally agree. Final question, business model, once I get in, is it a service, software as a service, is it a monthly fee? How do you guys make money? Yep, it is software as a service. It is a monthly fee. We are early to market. So I'm not going to pretend that we have perfectly cracked the pricing. But the way that we think about this is, this is a team product for software engineers. And for informed constituents, right? You want a product person in the product. You want a security person in the product. And we also want to incent you to scan your apps in the most modern fashion, which is scanning the smallest amount of HTTP that lives in your app, like in a microservices architecture, because it makes it a lot easier, easy to isolate the problems where they live and to fix those issues really quickly. So we bundle team and products and then we scale within companies as they add more teams. So 10 users, 10 apps is 3.99 a month. And as you add software engineers and more applications, we scale within your company that way. Awesome. So if you're successful, you pay more, but doesn't matter, you're already succeeded. And that's the benefit of buying as you go. Great stuff. Final question, one more thing. Your vision of the future, what are the biggest challenges you see in the next 24 months plus beyond that you're trying to attack that's a preferred future that you see evolving? What's the vision? Yeah, you've touched on this a couple of times in this interview with being remote and the way that we need to build software. It already has been modernizing and I feel like every company has a digital transformation initiative, but it has to happen faster. And along with that, we have to figure out how to protect and secure these modern apps and scale. So most important thing that we have to do is in the heart and mind of our software engineers and make it really easy for them to use security capabilities and then continue to grow within the organization. And that's not an easy thing to offer. It's a different way of being security, but I think we have to get there in order to provide the security in these rapidly deployed and developed applications that our customers expect. Awesome. Jody Clifford, CEO and founder of StackHawk. Thank you for coming on. I really appreciate it. Thanks for spending the time featured startup as part of our Cubon Cloud. I'm John Furrier, your host with SiliconANGLE2Cube. Thanks for watching.