 Hi, this is Yoastakil Bhartia and welcome to your first talk. Today we have with us once again Scott Gerlach, CSO and co-founder of Stackhawk. Scott, it's great to have you back on the show. So, I know it's super good to be here. Thanks for having me. And as before the recording started, we were talking about, you know, you folks are busy. You were at AWS readment as well. And you announced GitHub Insights there. We'll talk about a lot of things today, but before we go there, just remind our viewers what is Stackhawk all about. Yeah, totally. Stackhawk is an application and API security testing platform, enabling you to automate testing of APIs and applications and really specializing, helping developers understand what those problems are. So they can get to the ultimate problem of fixing those problems and making sure that you can produce safe software very quickly within your organization. Now, let's talk about your presence at readment. What was the experience there? What was the theme this year? And then we'll talk about the announcement that you folks made there. Yeah, I think the theme this year was crowd surfing. There was an insane amount of people there. It was really an exercise in how do you navigate through the waves of people. Really great conference this year. We had a larger booth this year, so we could effectively serve the t-shirt masses, audiences that came to the booth who wanted to learn about Stackhawk and of course get one of our super comfy t-shirts. But it was really fun. We had a larger team this year. We talked to a lot more people. There was so many people at the conference. And a lot of people were really interested in API security testing. And then we also launched our new GitHub Insights at ReInvent as well. And people were really, really excited about what the possibilities of GitHub Insights are going to lead to. Now, let's just go a bit deeper into GitHub Insights. Yeah, for sure. So a brand new feature for Stackhawk in the platform, really helping security teams connect what code is being written to what applications are being produced. So obviously the very first problem in application security are one of the first problems. And application security is, what things do I have to test? Now, because of our deep, we heart developers background, we always think about code repositories as the source of truth for all of that, what applications are there in the organization. So what we built is a way to connect to GitHub repositories today, and then be able to map those and help create applications in the Stackhawk application, Stackhawk platform, so you can test those thoroughly, as well as see insights into how often am I testing this application versus how often is it being developed? So you can see if those things get out of alignment. And then who's working on this thing? So one of the other challenges is, who can I go talk to about this application or code if there's a problem in it? This helps connect that divide between security teams and engineering teams. And then the last part that we announced at the show was an AI component of GitHub Insights. So being able to take AI, we do this, take AI, inspect the repositories, look at what's going on in that repository, and going, hey, we think this is an application, hey, we think this is an API based on what's going on in this repository, and you should probably be testing it. Let us help you get to the point where you've got it all set up. And if you don't know what it is and you need somebody to talk to, again, there's that connection point. Here's the last person that made a commit in this repository. You can go talk to them about what it is, hopefully they know, and they probably do. But then getting yourself to, all right, I've got this configured setup and working under test in Stackhawk, helping you give confidence in what you're building is secure. Future-looking versions of this are, hey, a new repository spun up. So probably a new application coming out the door. Who's working on it? Let's go talk to them so we can get in sync with engineering and security teams much earlier in the process than happens today. When you look at security, sometimes, I don't know, the generalize that everybody, but most people think about, you know, it's kind of react, reactivist like response, you know, to sometimes it's also proactive, you know, like you have seat belts and you have airbags in the car, you have batteries in the plane. But do you also feel that, like, you know, capabilities like GitHub insights, you also enable empowered developers, you know, I'm not talking security, but essentially that instead of having a lot of gates put up by the security, they are some guardrails, so they can, you know, freely innovate, they can do a lot of things without having to worry about stepping on the tools of security. So what I'm trying to look at it is to just flip the security and instead of thinking of it as blocking innovation, by these tools actually empower developers to be able to do things that they want to do more comfortably and freely. What are the thoughts on that? I think you hit the nail on the head. Like, there's a talk that I've done a bunch of times talking about racetracks and how much security you see at a racetrack. It's like everywhere, right? There's safety in walls and fences and how the cars are built and the safety harnesses and the roll cages in the cars and how do you keep the spectators safe from crashes. But the main point of the whole thing is going fast. And that's how I kind of think about or how I advocate. Security teams should think about what they're doing, help the product go fast, build in safety nets and protection mechanisms that help people make good decisions, but also help the product go fast. So, you know, in this particular case, you're talking about making sure that the engineering and security teams are a little more connected on what's happening. Be able to test in CICD. Get yourself to the point where you're informing developers of intelligent, like, here's a problem. You, developer team, who are the only ones that can fix it, can also triage this thing, figure out what the problem is, hopefully fix it, but move on with the job of creating value for the company by producing code and putting it into production. And that's, you know, that is the core of how StackHawk thinks about it, how I think about it. And we see a ton of people moving this way, right? The whole shift left movement. When people are coming to our product to like check it out, see the product in action, ask us about how it works. The very first thing they're saying is we need to help our development teams go faster, but we also want to do security. So, both of those things are super important. And the only way you can really get them done is by connecting those two teams. Let's look at it from the business's point of view that, of course, security, everybody wants security, but once again, it slows things down. So, despite the want, they don't implement all the right practices because they don't see the value immediately. So, talk a bit about the business value through GitHub Insights. So, of course, not just like saving developer's time, security team's time, but just to kind of relate it with the business, with ROI, because it's here and so let's talk about the books as well. Yes, that sounds great. So, the ultimate goal of the business is to create value for customers. The thing that's pushing speed is the ability to get to market quickly. So, if you think about cloud technologies, CI, CD specifically, the ability to write some code, compile it, build it, deploy it, get it into customers' hands quickly so that they can derive value from it, that's the whole point of technology in a business, is to be able to do that quickly and before your competitors do. Now, if you can't, if you can do it fast, but it turns into a car wreck and everyone goes flying through the front window, okay, that's macabre. I take that back. If you run over the nails in the driveway, because you didn't go check the driveway and the car's tires are flat, then you're not going to get to market very fast. However, if you have a process that enables both teams to be aware of what's happening at all times, so as you integrate testing, like you do other testing, feature CI, integration testing, unit testing, that's all integrated in CI and it's feeding back to development teams. Is this thing working correctly? If we think about security testing in the same kind of fashion, test in CI, feed back to development teams, let them understand and fix those problems, it's just testing, but it's the security version of testing and if we think about it the same way as we think about other testing, it becomes this much better paved and nail swept up road of how to get that code into production and get value to customers and that is the business value of why making technology exists. Initially we started talking about AWS re-invent and this year there was a lot of focus on Genitive AI, you know, SKU and a lot of other things there. I want to also talk about Genitive AI in the context of, of course, stack hog security. At the same time, let's look at a Genitive AI for security and security for Genitive AI workloads. The thing about Genitive AI is it's A, going to be useful for people to save time, B, still has inherent risk and C is just going to contribute to this explosion of APIs across the internet. Every time you start talking to a Genitive AI endpoint, it's an API itself and people are starting to wire those APIs together. So we're already talking about an explosion of APIs across the landscape here Genitive AI is going to add to that. Now there's a ton of benefits that come out of that which are include how do you write code better, how in Q's case, how do you write data queries better across multiple data sources. But the thing that it has been proven so far and is a documented thing is sometimes those Genitive AIs are introducing new problems, introducing new vulnerabilities. Now I'm not saying don't do that because absolutely do that. What I'm saying is test it. Make sure that what's Genitive AI is helping you go fast again and it's helping you get to the end goal. Make sure that it's not introducing new problems and you can do that through testing. And then the last part there, testing Genitive AI LLMs. If you think about the way that you interact with an LLM and the way that you could potentially test it, we think Stack Hawk is well positioned in this market to be able to test that looking at inputs that go into an LLM interface and seeing what comes out. That's kind of the only way you can really security test an LLM because it relies on being creative and coming up with output based on what you're doing with input. And that is exactly what Stack Hawk does. So we're very excited about the possibilities of being able to not only use Genitive AI, the explosions of API that that's going to create and the creativity that goes along with it, but also the ability to test Genitive AI prompts to make sure you can't do stuff like prompt escapes and data retrieval, those kinds of things. So we're thinking about that really deeply and we're pretty excited about the kind of possibilities there. I may be totally wrong, but we did not hear that many scary stories related to security that we used to hear earlier. Is it because that the media, the press is just tired of it because there are so many other things happening? You folks, do you also do some surveys, some reports to understand where the market is today? Because it's the year end. So and from your perspective, have you seen that security has gotten better? Or you see that, hey, actually this year, these kind of tests that emerged, tests are becoming more sophisticated, new kinds of tests are emerging. I just want to get the state of security from your perspective. Yeah, totally state of security. How long is our talk here? Like a two hour, three hour thing? See if I could summarize really quickly. We're definitely seeing more attacks and specifically more attacks around APIs. And when we're talking about that, we're talking about usually authentication and authorization type problems. So can an attacker get access to customer databases? Can an attacker chain pieces of information together? And I think even though you haven't heard about it in the news, there are more of those things happening. And that's mostly because of proliferation of APIs, more APIs, more attack surface, more ability for attackers to go poking around in it. So I think that's happening. I think why it's not in the news is there's a lot of other stuff happening in the world that may be preempting people's concern about API attacks. I bet you could off the top of your head think of two or three. So I think that's why maybe you're not hearing about it in the news. We're commenting on tons and tons of those kinds of stories, whether they're breach notifications or incidents or whatever. And I think there's even a survey out there that said API attacks, API security problems were double or something higher than that from last year. So it's a thing that's out there. Maybe people are getting tired of hearing about it. I don't know. But there's definitely more APIs, more surface area out there. So that is for sure a thing that's happening. When we are talking about, in earlier, you're talking about enabling developers, enabling security teams. You are at AWS. Of course, that audience was totally different. But if you look at the end of 2020 for how content you are, where you see that organizations, they understand the risk. They also understand that the tools are there, but they also need to have practices, culture in place so that they have a very well-rounded approach towards improving their security posture. Or you feel that a lot of work has to be done. And if you feel the work has to be done, in what area is it culture? Is it available for better tools? Is it availability of maybe the whole top-down, just having a CISO or DevSecOps label is not enough? Yeah. No fair. You asked me 14 questions right there. Let's start from the top. I think if you look at what's happening in executive suites, especially in public companies, the SEC teeth around security are getting really sharp. So the requirement to be able to report breach information to SEC from public companies is a thing. So that's making a lot of executive teams and boardrooms way more aware of the need for understanding and building insecurity. To your point about people and process and technology, we've been out, I've been giving talks this year, really helping people understand those key three pillars to being able to do shift left kind of momentum to be able to build good process and procedures around security testing by involving people that are responsible and required to be able to make things functional and make them perform correctly and understanding the tooling that can help enable that. So if you look at how cloud started, so you think about the cloud services that were out there, people were like, oh, this technology is awesome. It's going to change how everything operates and then we didn't change how the people interact with it and the process to build software. And it turned into it was just more expensive. But then once people were like, oh, actually we should change how we build software and include different people and different roles in how this works, now it turns into it's much more cost efficient to get to market because of that technology and the process that we redesigned to get there. And that is starting to happen in security, which is super exciting. There's a lot of really great tooling out there that helps kind of enable this shift left process. And you got to get the people involved to be able to change the process so that it works correctly to really get the benefit out of it. And there's work to do there. Sometimes we have a little bit of a broken relationship between engineering teams and security teams, so you got to do a little repairing of that relationship. But once you get to that spot, you've got much better insight as a security team as to what's being built, what's the risk, how is it benefiting the company, how can you help development teams understand that risk, manage the risk. And development teams have a better view of what security is working on alongside of them instead of in some black box somewhere where they just magically show up today with a pile of tickets like this big and you'll fix all these now. We live in a data-centric data-driven world. We live in an API-centric API-driven world. What are the new workloads that worry you that, hey, we are not ready to secure those workloads? Or you're like, nah, things are evolving at their own pace. Yeah, I mean, there's so much technology out there. You know what I mean? You've got Kubernetes and container clusters and workloads and VMs and data lakes and somebody said data swamp the other day. I thought that was pretty funny. But there's so much technology out there and there's so much security technology that goes on top of that. It's really hard to understand what goes where, how do you benefit out of it? How do you get the most out of that tool? And how does it help organize risk around the company as a security team? And the other problem there is, you know, we talk about this security team to developer ratio and the commonly accepted ratio, there is one security team member to 100 developers. Pretty hard to keep up with that kind of headcount pace, let alone development deployment pace. So the really the great way to get that get that kind of under control and help scale out the security process, you're not going to be able to hire 100 security people for every 100 developers. Not going to happen. What you can do is help them make better decisions with better tooling. So we kind of got our security teams as security folks. We have to get out of this mentality of I can't share information, only I can know. It's too sensitive to tell other people because they'll use it against us. Now there are companies, businesses, government organizations where that is a thing, but most companies are not in that place. So think about how do I engage my other team members, whether that's engineering or accounting or data operations, how do I engage them so that we can work together to make security risk management, not risk elimination, we're not trying to eliminate risk, trying to manage risk, make that really effective across the organization. When you're talking about your managing risk, when we look at security as you're already discussing about that, it's more like kind of react to something may go wrong. We do prepare, but still security is not a product, it's a process. The bad guys have to be right only once. Good guys have to be right all the time, 100 percent times. But are you also seeing that we are still in a phase where security is more like, hey, you're trying to put garlic, you're trying to product, or you're moving a phase that things are like, good example is airbags or brakes, which are there to stop bad things from happening versus reacting and responding to them? I think security teams are historically great at detecting respond, or at least very good at detecting respond, because it's kind of a thing that you can do by yourself. Like a security team can ingest a bunch of logs, look at firewalls, look at WAFs, look at kind of all this external traffic, what's happening on our workstations and our workloads, gather all this information and do detect respond work. Like I said, I think it's great, if not really, really good. The thing that's very hard for security teams to do is work with other teams and have a perspective of what they're trying to get done and how can security help or at least not hinder what they're trying to do, right? How do I help design systems that are a little more fault tolerant, a little more data protected, data protective, a little more risk adverse? Again, not risk zero, turn everything off, that's the only way to get risk zero. But working together with those counterparts, now you kind of got to start where your most risk is, right? So if you're a digital technology company and you're protecting HIPAA data and you're providing APIs around it, probably the biggest risk there is the APIs and the people that have access to the data, start there. If you're a different kind of a company, you got to figure out what makes the company money, why do customers ask about it? And I would challenge the securities not a product because if you're in any kind of B2B, business to business kind of a system, one of the very first things you do before you buy software or something from another business tell me about your security practices. That either helps the deal get done, helps the deal get done quicker or it doesn't. So I think that that's kind of part of the product. But really, really encompassing where is my risk, how can I help those people make better decisions so I can start moving down the chain to, okay, this is lower risk, how can I help those people? This is lower risk, how can I help those people and make sure you're using a risk-based approach to how you're attacking risk in the organization. Scott, thank you so much for taking time out today and of course talk about the GitHub Insights, your presence at AWS, re-invent, and great insights about the whole security landscape there. And as usual, I would love to chat with you again. Thank you. Yeah, absolutely, Swaddle. It's always great to be here. Thank you for having me once again.