← Software Engineering Daily
Software Engineering Daily
StackHawk and Shift-Left API Security with Scott Gerlach
00:46:08
APIs are a fundamental part of modern software systems and enable communication between services, applications, and third-party integrations. However, their openness and accessibility also make them a prime target for security threats,
Loading summary
Transcript54 lines
- [00:00]
Scott Gerlach
APIs are a fundamental part of modern software systems and enable communication between services, applications and third party integrations. However, their openness and accessibility also make them a prime target for security threats and this makes APIs a growing focus on software teams. Stackhawk is a company that scans and monitors source code to obtain the full scope of an organization's APIs and applications and and runs tests to identify vulnerabilities and address them. Pre Production Scott Gerlach is the co Founder and Chief Security Officer at Stackhawk and previously worked at SendGrid and GoDaddy. He has an extensive background running security operations and engineering and in this episode he joins the show to talk about the challenges around API security and leading edge strategies to address them. Gregor Vand is a security focused technologist and is the founder and CTO of MailPass. Previously, Gregor was a CTO across cybersecurity, cyber insurance and general software engineering companies. He has been based in Asia Pacific for almost a decade and can be found via his profile at Vand HK.
- [01:23]
Gregor Vand
Hi Scott, welcome to Software Engineering Daily.
- [01:26]
Scott Gerlach
Hey Gregor, thanks for having me. It's super awesome to be here on Software Engineering Daily.
- [01:30]
Gregor Vand
Yeah great to have you here. And you're here on behalf of Stackhawk as a co founder and we're going to be hearing all about Stackhawk and what the platform does. I mean it's all sort of without any spoilers here. It's all about security. It's about API security. So this is a topic I love to dive into and I think API security especially is always something that I've always wondered how best to do this. So we're going to be going into that today. But in true SE Daily fashion it'd be great just to hear a little bit about yourself kind of what was your just a brief kind of what was your path to co founding. And you're also the CSO of Statcock. So what was life up until that point?
- [02:11]
Scott Gerlach
Yeah, absolutely. Wow. So many questions. First of all, just a little bit about me. I'm Scott Gerlock. My background is in running security teams, security operations, security engineering. So I spent 10 years, almost 10 years running different security teams and functions at GoDaddy, which is essentially like 50 years of security because of, you know, give lots of random people access to your servers and see what goes wrong. That was super fun. I learned a ton after that. I was the CISO@ SendGrid email company. Hopefully you're you know SendGrid. Lots of devs know SendGrid because so easy to get it installed and up and running and send an email. After SendGrid and Twilio got combined is when I left, took a little break, looking for my next, next gig, next role. And I met Joni, our CEO and co founder and she was out digging around in the application security space. We had a pretty good conversation where she was asking questions about application security and why it's tough. And I was kind of unloading a little bit because I was in that like freewheeling. I don't have a job space. So I kind of Unloaded on AppSec a little about how terrible it was and how underserved devs were in this process. Like literally. I think one of the things that we talked about was literally the people that can fix this problem are the last ones to know about it. Like in almost every scenario we go, hey devs, publish code and we'll get back to you in like a month or so, talk to you about all the security problems in there. So after we were done Talking about this AppSec thing, I was feeling pretty full of myself, but I was also like, well that was pretty opinionated. She probably is not going to talk to me anymore. Like two weeks later we started Stackhawk.
- [04:08]
Gregor Vand
Awesome. That's a great co founder story. I love that. Yeah, I mean exactly. The application security. It's something I've spoken a bit about on other episodes. Just how I think there's a misconception that developers are taught this if you do CS or something, that this is part of the syllabus, which is partly true, but it's kind of like an afterthought. And when it comes to just general day to day work, security for a developer again is sort of. Unfortunately the business end isn't often thinking about it and they don't see it until it's gone wrong really. So it's sort of been this slow burn to get businesses and developers kind of more understanding of the problems. But I think the problems are pretty well understood. I think just to kind of set the scene, I thought it might be helpful just to kind of a couple of acronyms here. You know, DAST and sast. What are those and which one is stathoc and why?
- [05:00]
Scott Gerlach
Sure, DAST and sast. Acronym Soup of Information Security, Dynamic Application security testing. That's DAST. So testing what is a running application or running HTTP classic like web one web server or an API HTTP API. So a REST API or a GraphQL API GRPC or God forbid SOAP. That's what DAST specializes at, testing and testing that running version of the application is really beneficial because of a couple of different things, mostly discoverability and exploitability. So when you are testing with a DAST tool, it does a really good job of going, hey, this is super important because it is discoverable, someone can find it and can exploit it. And insofar as those two things are true, what's great about it is it will tell you, it will help you prioritize your time and keep you away from kind of what has historically been the noise generated by SAST or static application security testing. Static application security testing. AST means two different things, two different contexts. Anyway, static application security testing, which is really great at pointing you at exactly the line of code that you want to go fix, but it's also really great at. And also here's 9,000 of them and has no context of what is discoverable, what is exploitable. And where Stackhawk fits in is kind of, we're trying to make our way to the middle. So doing dast, but doing it more of a gray box, white box fashion. So we are also aware of code so that we can point you to, hey, this is discoverable and exploitable. But also here's the code that you have to go fix. And with the advent of LLMs, maybe the code fixes itself, that kind of stuff. So really helping people find security vulnerabilities in HTTP APIs and fix them as quick as possible. So as engineering teams and as security teams, we can get back to the, to the business of helping the business run, which is the ultimate goal of everything, of what everyone's doing.
- [07:23]
Gregor Vand
Yeah, absolutely. So that's a really nice sort of framing. So Stackhawk kind of sits in that sort of semi middle ground, taking sort of the top topic here, which is, you know, Stackhawk is proactive. It's a proactive approach to API security. I guess question number one is sort of like, what does that even mean? Like to be proactive and then looking just sort of this in context. I think a lot of developers are probably pretty aware, listening today you work for a company and you've got API endpoints. Well, you've probably got a ton of API endpoints and some are actually being used. And then you've probably got a bunch of endpoints that are sort of still there, but no one's actually taking them out. And this kind of thing. So talk about that. The proactive side or proactive approach of stathoc as well as sort of this in context of API sprawl is kind of a nice way to term it yeah, for sure.
- [08:16]
Scott Gerlach
So the proactive side is one of the things that I've kind of lived my security life by, worked at a hosting company that is a super reactive environment. No matter how well you do at it, being reactive, especially with vulnerabilities that you can find sucks. Like, it's just not fun, you know what I mean? Like I was trying to think about this earlier as an analogy of like building your own airbag and putting it in your car and never ever testing it. And the only time you get to test it is when you run it into another car. And hopefully that airbag is really good or the protection, some kind of protection mechanism is really good. Putting untested software, un security tested software out on the Internet is sort of a recipe for a fire drill. Later down the road you're going to run into, whether it's now or later, you're more than likely going to run into, holy crap, someone's attacking us. Let's see if we can contain this before it turns into an incident. And if it does turn into an incident now, it's a whole big thing where you've got engineering teams and security teams all working, stopping their regular work and working together to do incident containment and remediation, which is going to happen. Hopefully you want it to happen as little as possible, like reduce the amount of risk that they're putting out onto the Internet or in production is one of the things that security teams are supposed to be doing. And the reactive nature of API security, where publish the APIs, watch for attacks and then react to them, that seems scary. It's super valuable in a. I think I've put out the best thing I can put out. Now let's see. If and when we get attacked, we can respond and block attackers and recover. But doing it without tested software, holy moly. It seems really scary to me. I don't know how other people think about it in security teams or how engineering teams think about it. I think engineers generally want to put out the highest quality, most secure code that they can. The barrier to is this secure was really, really high.
- [10:42]
Gregor Vand
And I think the way I sort of have often thought about it from why is it so scary? It's scary because APIs are literally just roads to your database. That's pretty much the simplest way to put it. Right? They just happen to be rows with lots of rules. But if those rules can be figured out or so on and so forth, then you've just got a straight road to your database. I mean that's just, that's why it's scary, right?
- [11:04]
Scott Gerlach
Yeah. And API sprawl is not only sprawl, but the explosion of APIs is just compounding the problem so much. You've got the introduction of LLMs, which is making it easier for software engineers to write software. It's reducing their comprehensive cognition of what's actually happening in the code. So generally we understand what's going on, but we have less of that manual, one key at a time authoring of some of this code. So we kind of naturally lose some of what's happening in the code. And then the ability to cicd agile process, get everything out the door so fast. APIs are just insanely growing. So API, I don't know if you know this API traffic is approximately 80% of web traffic today.
- [11:55]
Gregor Vand
Yeah. Wow.
- [11:56]
Scott Gerlach
Like everything is API. And that's crazy. And you're absolutely right. It's just like that is the most riskiest place because it's basically direct connect to the database where all the risk is. That's where all the data is stored. That's where all the, all the good stuff that threat actors want is, is right there in the database. And the API is the gateway to get there.
- [12:16]
Gregor Vand
Exactly. So I mean, could you maybe just speak a bit to how does stackhawk approach the discovery and the management of this complexity and then sort of going on from that. How does Stackhawk actually simulate real world attacks? Basically that's always the bit I've been fascinated by. I mean, I thought about this space a few years ago and I just assumed someone was doing it. So that's probably why I didn't go down this road. But the simulating of the attacks is kind of, I think, super interesting. But let's start with how do you even go about the discovery bit and then how do you simulate the attacks?
- [12:54]
Scott Gerlach
Yeah, totally. So the discovery bit, we think of source code as the source of truth for any company that's writing software for any value at all. You might have APIs that you didn't author running around in your organization, but you probably also can't fix them. So that's just a upgrade or a patch. But we think about API discovery insofar as I wrote code that makes this API work and that code is stored in my source code repository. So let's go look there, let's start there. So one of the very first things, one of the newest things we built, one of the first things you experience as a stackhawk user is connect stackhawk to your source code repository. And what we will end up doing is running some Stackhawk magic on that source code and going, hey, we think this repository builds a REST API, this repository builds a Web 1.0 web service, we think this one builds a SOAP service, you know, those kinds of things to be able to go, here's all the source code that builds APIs. Now they might get stitched together later or they might get, they might all end up in a gateway. But that's sort of how we think about it. And how we think about testing is like test that smallest bit of code that you can because it makes it so much easier to correlate the problems with, where to fix it, makes the problem set a lot smaller and way more distributed. So getting that information to the teams that work on those things is super important. So that's how we deal with kind of the discovery of APIs and being able to say, here's the attack surface that you have based on what code you've written.
- [14:32]
Gregor Vand
Nice. And then moving to the sort of, then what happens in terms of okay, you've now discovered and then what happens?
- [14:39]
Scott Gerlach
Yeah, so the really great thing about APIs, the great and terrible thing about APIs is there's not like a classic web browser to go looking around at. And if there is that web browser, I always like to say the Instagram analogy. Like think about when you're looking at Instagram and you're scrolling and scrolling and scrolling, that never ends. It used to, but they fixed that problem. And so all that is is just API call after API call on the back end, pulling more content and more feed. You can't ever complete the task of looking at the front end to be able to get to the back end. So thinking about testing the backend directly, whether those API, whatever flavor that API is, is the most efficient route to testing that kind of data flow. So being able to go, hey, there's a REST API in here and there's a REST API or an open API spec that's either generated by the code or it's hand rolled or Stackhawk helped you build it and then ingest that and go, okay, I understand how this API works. I understand what kinds of data need to go into these URL paths or the post parameters or whatever that is to drive the URL correctly and also try to attack the API itself with valid and invalid data. Those are the keys to being able to really get into an API, test it pretty thoroughly and find out whether there are or are not problems. The next part of that is really kind of business logic Y testing that's a tricky problem. One of the things that we did for that was just be able to write custom test. So if you've got some custom business logic in your application that says Gregor shouldn't be able to get to Scott's information about his address and his family information, you could write a test for that. Right. So I'm Gregor see if I can get Scott's information. If that works now I can throw an alert. So because that tendency is so hard to generalize, or those kinds of workflows are so hard to generalize, being able to help write custom information about that, a lot of our customers found that super helpful.
- [16:56]
Gregor Vand
What are the differences complexity wise between REST and GraphQL? Because I mean, I think GraphQL is where more, at least just from where I sit, that's where I would say even more problems have come up recently from an API standpoint where Those exposing that GraphQL API aren't fully aware of all the traversals that can happen and what can come back. So how does that look? Is it sort of a different process or is it just the same thing?
- [17:26]
Scott Gerlach
Yeah, the complexity and differences between REST and GraphQL are wide and vast. The very first difference in the two is how they document. So GraphQL is really good about self documentation and REST is not. And that's the very first thing, which is a bonus and a drawback for GraphQL. Like you don't have to mentally think about documenting how the GraphQL API works. And so therefore it makes it really easy for us to go test it, but it also makes it really easy for anyone to go find that information and kind of start traversing their way through the graph finding information that they shouldn't be able to get to with recursion. Different. Different recursion attacks those kinds of things. That's not really a drawback of Graph per se, just kind of how it works and how it's intended to work to power the applications that it's intended to power. So I wouldn't say it's really a drawback. It's just one of those differences you got to know about to make sure that you understand why it's a problem and you can test it and find it and fix it.
- [18:35]
Gregor Vand
Yeah. And I think this is, I guess, what's to me great about Stackhawk that it can cover both. So it doesn't particularly matter which one you go for the API type that suits your business case without then having to overthink the security side of that.
- [18:50]
Scott Gerlach
Yeah. Or the language. Right. So, like, one of the really great parts about dast and why we kind of picked DAST was it's language agnostic. So whatever language you decide to write in, like next week, you decide that rust is where it's at and you're going to transform all your stuff to rust. And you've got terrible language support from static providers. Just when you're building an HTTP application, DAST has the ability to test it no matter what language it's written in. So that's always a really great thing for me as a practitioner. Being able to let the engineering team innovate and develop and try new and different things and be able to secure those same things as you're building them is super important to me.
- [19:36]
Gregor Vand
Yeah, that's a great call out. If we just sort of move on to. We have to these days, always touch on Genai and AI. Generally it is pretty pertinent here, right, Because I'm an absolute convert to cursor. I love using cursor to write code now. And yeah, it's churning out a ton of code and so long as it looks kind of okay to me and it works, I'm like, yep, great, we're moving on here. I'm not taking too much time over certain parts of the application now where I'm kind of confident that it's done its job, it doesn't look awful, it can be optimized a bit later on. And just to be clear, I would say I'm using it a little bit more on the front end side right now than the back end side, because it does help to be more aware of your logic. But this is the point. Developers are very much using Genai now to generate quite a lot of code. And on the other side, we've obviously got the possibilities that people can be using LLMs to generate code or just instructions on how might one go about getting into this app through the API, et cetera. How is Stackhawk thinking about this? How has the last two years unfolded for evolving the platform to meet this?
- [20:46]
Scott Gerlach
Yeah, so the Genai problem, the LLM being able to write code, doing it faster, we covered that a little bit. It's contributing to the explosion of APIs in exactly the fashion that you said. Like, generally this looks right, it's going in my code, I'm not sure exactly what it does and that has been shown to date to introduce vulnerabilities. Like sometimes it does, and hopefully, and I think it will in the future, get better at not doing that. And I think where you're Going to see what, what you're going to see happening is as you have copilot or whatever in your IDE and you're writing code, I think you're going to start getting the clippy experience of hopefully not the clippy experience, but like the spell check version of clippy in the IDE that goes, hey, you just introduced a security vulnerability here, would you like to fix it? Those kinds of things. So instead of like running SAST on your code, like doing it live while that's happening, I think you're going to get a ton of value out of that in the near future and near future, I mean like a year or two. As contextually aware, LLMs continue to get better and better and better, especially around code. So that's one thing. The thing that you still have to test for is things that you don't see in code, right? So the pattern that you don't see in code is a business logic problem or a authenta authorization problem. Sometimes you can't see that information in code. So you kind of have to still test running applications for how the app responds to inputs and outputs. Right? So there's a world there where those things I think get more efficient developers get more efficient, the LLMs will stop running. Kind of our junior devs who aren't really aware of what's going on. Like when you have an LLM write some code for you and it's awful, you have to be able to see that, which is unfortunately a thing. Like I run a Kubernetes server at my house here just because I like to, you know, torture myself. And sometimes I go, hey, ChatGPT, help me write a deployment manifest for this service and blah, blah, blah. And I want it to expose itself on the NGINX web server and have an SSL certificate, completely makes it up and it's totally wrong. And you're just like, no. But the trick is you have to understand how that today you have to understand what it's supposed to look like so that you can go, nope, that's completely wrong. I think that starts to go away as well. Like in the future, like that whole total hallucination of what a solution looks like goes away. So it's just going to keep getting faster and faster and faster. And we as software engineers and security people are just going to become less and less intimately associated with this code. It's just going to be a thing that we're generating and getting out to the market to provide value for customers as fast as possible. And we're going to have less of that, like, pride. I pumped hours and hours and hours into this code, like we kind of do today.
- [24:04]
Gregor Vand
I'm already there, you know, I've been using, you know, cursor now for about six months, I think maybe five months. And it is, it is that I just feel less. Less sort of precious, I guess, of the code. And I'm curious, I mean, I think that maybe helps in this case because I think with tools like Stackhawk, at least it's not a person telling you you've done something wrong. But it's still kind of annoying when something's like this thing you wrote, you need to go fix it. And would you say that now if developers are able to kind of utilize more from the LLM generation side, there may be a bit less pressures. And actually, at the end of the day, it's just kind of robot versus robot sort of saying, well, that robot didn't write the right thing. And you're just kind of the pilot overseeing the whole thing going, okay, well, that thing just didn't write the right thing. And Statcox said it's not correct. And. And actually maybe sort of that sort of dynamic is going to play out. I don't know what you think.
- [25:00]
Scott Gerlach
It could, it could, like, human emotion is a thing. And every time a human interacts with a human and goes, you did it wrong. No matter what words you use, that's ultimately what ends up happening. You take a little bit of offense to that. You know what I mean? It's really hard to communicate, man. This thing you did is super valuable. Like, I understand what you're doing. I know that you put your heart and sweat and soul into it, and it took you forever to do this one thing could be better. There's a problem in here. Like, everyone skips that first part and just goes, this part sucked. And it feels like you're terrible at your job. To your point, that could turn into a deflective. Like, no, I'm not terrible at my job. The robot was. And so now I'll just go fix that maybe. I think the more important part is, like, the more in context of what you're doing, you are aware of the problems, the more likely you are to just be like, yeah, yeah, no problem. We'll just fix it, right? You don't get mad at unit tests when they fail. You go, oh, okay, well, I gotta fix that. And linters and all that good stuff. It's annoying, but you go, all right, I gotta fix it.
- [26:10]
Gregor Vand
Yeah. So, I mean, just Kind of like wrapping up on the genai side. At the end of the day, code is being generated much faster and sort of that inevitably leads to code that maybe hasn't had a full check or a full kind of sanity check from a human. And as you've called out, Scott, I've seen code come out and as you say, it's just completely wrong, but it's only from having years of experience, I can quickly look at it and go, that's completely wrong. And then just can it. And then be like, okay, either this needs a different prompt approach or just actually, you know what, I'll just start it myself and then see where we go from there. And I think clearly something like Statcock is able to sanity check that far faster than sort of humans. And as you call out, there's Almost a catch 22 now between sort of junior developers coming in. Are they supposed to be using this from day one or are they not? And how are they going to learn to sanity check? And yeah, it's kind of interesting. And I guess could you almost look at Statcock in this context as sort of just like. I wouldn't say like checking the homework, if you know what I mean. But it's able to kind of sit there and just sort of be that sort of overarching checkpoint. I mean, we haven't even touched on just the classic phrase shift left, which I think probably applies to this somewhat.
- [27:29]
Scott Gerlach
But we've talked to lots of different people using kind of LLM assistants, code assistants, and one of the things they often say is, who's going to check this code? The LLM. When would the LLM go? This is wrong. Or maybe even more importantly, when would the LLM go? This is right. And do you trust the LLM to check the work that it produced? Because is it going to go, no. What I wrote there is completely insecure. You should rewrite that for me. You know what I mean? Having something else that can check it is super valuable.
- [28:05]
Gregor Vand
Yeah, that's a great point. Yeah. So that positive affirmation, it doesn't, to my knowledge, give that yet it doesn't say, I don't think I've seen anything, especially from a security standpoint, where it says, here's this code, and I've definitely, definitely checked. There is nothing wrong with this code. I mean, it doesn't.
- [28:20]
Scott Gerlach
Yeah. Especially if you're writing like a snippet in the context or the context of how that snippet is included in the rest of the app or the code base. Like, that's all really hard problems. I think it's going to get solved over time. But right now it's like, okay, something has to check that this is being done the right way.
- [28:43]
Gregor Vand
So just moving on to devex, we've got quite a technical heavy listener base. We do have non technical listeners as well. So just sort of keep that in context for sort of when we're talking about containers and so on and so forth. But just maybe from a high level. What does that look like for a developer? Someone on your business team or security team has come to you and said, hey, we're implementing Statcock. Off you go, go figure it out. What does that look like?
- [29:10]
Scott Gerlach
Go figure it out. I think for the most part when we started the company, the whole idea was how do we put the right information in the right hands at the right time? Because there's tons of security tools out there that do a great job at serving security teams and they do a great job at kind of building these reports that you look at and you have these huge pie charts of unfixed things and they never move. So our goal was like, how do we help the people that can actually fix the problem understand there is a problem so they can actually fix it? We're staring at shrinking pie charts or some other kind of bar graph, whatever. That's how it started. And so the way that we build the tool and how you use it and the interaction and the documentation that we built and all of that is really, really dev friendly configuration as code. We use YAML. Love or hate YAML. We didn't do it in xml, so be happy about that. That whole process of like thinking about how automation works and how you're going to wire this up in CI and how you're going to continuously test and how you can test on your laptop while you're writing. You put your little snippet of code into debug mode and you could test it and know what's going on before you spend 10 minutes in the CI pipeline and then it pukes. And information architecture like here's the information you need to know and the rest of it is off to the side. Like if you want to know, you can know. But here's the information you need to know. That's how we really, really started with the tool and built the tool and people super love it. Like we've got a ton of customers who are classic security teams. They have had that kind of centralized security appsec force that is trying to keep up with the developer teams. I don't know if you know this ratio, but generally the ratio of developers to security people or appsec people is 100 to 1. So you got like one security person trying to support 100 developers. Never going to keep up if they kind of can't get this information out in a more timely fashion. So almost every single time when we run into that central team who's like, this is broken. I can't do it like this. I need to be able to do more automation, get more information distributed to more teams. They kind of take it on themselves and go, start small and go, okay, I see how this could work. And we recently had more than 10 customers. We do this kind of part of our onboarding is a developer training thing. Once the security team is ready to go, we'll come in and do a developer training, do it virtual or in person and really help people understand what we do and how we do it. And it is crazy to see the developer teams just take off. Like, it's crazy to see them come in there and go, oh, yeah, this makes a ton of sense. And then just start ripping away at configurations and they're like, my app's covered, or my four apps are covered, and just go. And like, going from we're testing one to three things or less than 10% of our things to now I'm testing over 60% of all of the things that we build from our source code in, like, days is crazy improvement. And it kind of blows some people's mind. But it's all because when you put the technical tool simply in the technical people's hands, it just goes fast and it's all.
- [32:36]
Gregor Vand
It's all container based. Is that right?
- [32:39]
Scott Gerlach
Yeah. So. Well, it's not all container based, obviously. Stackhawk is a Sast or sorry, jeez, here we go. Acronym soup some more. Stackhawk is a SASS platform, but the testing engine, and this is really specific and I think unique to Stackhawk, the testing engine is a docker container or a Java executable that you can put around wherever you need to put it. It's maybe the only docker container that's designed to be completely ephemeral, like the docker containers were designed to be. Does its job, does its test, uploads its results to the Stackhawk platform and then goes away. It's made to be really flexible, fit into an environment, no matter kind of how you're doing development. Like, if you have a classic dev test environment, we can run in there. If you have a completely ephemeral CI CD process, we can run in There if you want to test just on your laptop for some reason, you can do that. All of that flexibility to help people improve their application security programs, no matter how their engineering team works, is how we thought about designing the product and the platform as well as the testing engine.
- [33:49]
Gregor Vand
Nice. Yeah, as you call it. It's had a lot of from the developer standpoint and believe you mentioned YAML makes sense. I mean yeah, everything in realm is now sort of just YAML somewhere. I think Stackhog also takes advantage of YAML overlays. I believe you can share configurations across environments.
- [34:10]
Scott Gerlach
YAML overlays, we're really close to some YAML include stuff all kinds of just DevOps theory and process so that you can write the least amount of code or quickly change a configuration by kind of doing that overlay process like this one thing needs to change. Here's how to override that with an environment variable or another small configuration file just based on where it's running, those kinds of things and have the main configuration stay the same. That overlay system people get real attached to it real quick because it's super powerful.
- [34:50]
Gregor Vand
Yeah, I was literally just about to say super powerful. That's exactly what that sounds like. And just wrapping up on the devex side, I believe authenticated scanning is something that's also possible. So can you maybe just speak a bit to what even is that and sort of how does that look?
- [35:06]
Scott Gerlach
For sure, in DAST land, authentication is the key. It's the hardest piece of doing DAST and it is also the most valuable piece of doing DAST because any data worth its salt is behind, well, should be and probably is and hopefully is behind some kind of authentication process. So being able to get past that wicked important to be able to test what's going on behind that authentication. So there's tons and tons and tons of ways that authentication works. Unsurprisingly, devs often know how it looks and are pretty good at going, okay, this is the configuration and this goes here and this goes here and this goes here. And the secret is stored in our CI system and you know, all the devopsy processes. I used to say when we had a little less than 100 customers, we've talked to a hundred customers and we've seen over 700 different kinds of authentication. And that's probably still. That ratio is still probably true. People do some real interesting stuff with their authentic processes. But we built a super flexible engine that has a ton of like standard kind of auths like oauth form based auth jwt Auth, all of the kind of standardy types of auth, but then the ability to customize auth to make it work for whatever weird scenario somebody cooked up because they were having too much coffee on a weekend or other things, being able to kind of customize that auth so that it's repeatable, it works, was super important. So that's, that's a core piece of it. Some of the old, some of the old ways that auth used to work in dast tools is like record a web session, turn on the recorder, I'll punch in my username and password and then you just replay that. And that just doesn't work with a ton of, for good reason. A ton of new web technologies and how security processes work. Because you don't want that to happen. Right. Like you literally are trying to prevent that from happening in your app and hoping that your security tool can do it is a little crazy. But not to mention APIs don't have front ends. Not all of them have a front end. So you can't record that authentication. So that real machine to machine authentication process and capability really critical to being able to test and test quickly and thoroughly.
- [37:35]
Gregor Vand
Yeah, just sort of wrapping up on that bit. Just to throw another name out there, I think that a lot of developers are probably using, if not have definitely heard of, like Snyk for example. And I'm aware. How would you, just to sort of put it in context, how would you compare to them? And I noticed you put out some content recently, just about the speed that Stackhawk can bring over. Something like that. And what would you say to that?
- [38:01]
Scott Gerlach
Yeah, so we still have a pretty tight integration with Snyk where we combine SAST and DAST results. So because of what we talked about early thinking about testing, small testing in relation to source code repositories and how Snyk SAST works and most Sast works, it's like, here's the problem in this repository, if we're doing the same thing, we can really tightly correlate those findings and kind of point at code. The reason we can do that is because we can test like most of our applications or APIs that we're testing, we can test under 10 minutes. So speed is a critical factor. Especially if you're like, yes, I would like to integrate this into my CI CD and software delivery process. It can't take days, it just flat cannot. Not only is that not developer friendly, that's not people friendly. Like, I don't care what your job is, what waiting A day for something to finish its job sucks. That's kind of the capability they bought and I think they bought. I don't know why they bought it. Their goal there was to kind of round out their AppSec suite to say we have Sast and we have Dast and we have Secrets and we have SCA and we have all the whole Gartner AppSec platform. I just don't think they, I don't think they stayed close to their core dev friendly AppSec mantra when they did that. It's very much a security like click checkbox security tool that you put something on the Internet and you scan it and hope that there's nothing bad in there when the results come back in a couple days.
- [39:37]
Gregor Vand
I agree. I mean, you know, I used Snyk back in 2015, 16, this kind of thing, but certainly today it's not. It's there, but yeah, it's not a tool that I sort of find terribly inspiring. So I think the devex focus that Stackhawk brings should be a clear reason to give it a look.
- [39:57]
Scott Gerlach
If you're thinking about tools like that, even a tool like GitHub Advanced Security is reimagining and rethinking how that process works. Instead of like hook it up to your repository and then find all the problems and start sending them out. They started at hey, this dependency needs an update, here's a pr. And then they quickly moved. How do I get this information to the security teams? And the security teams push around tickets becomes really inefficient. GitHub advanced security is working on making that PR process and that like iterative feedback and things like auto fix with their, with their LLM, those kinds of things. But they're taking that more how do I serve developers mantra and pushing it way, way forward, I think in a much better fashion. So that's super cool, I think. And being able to get that information to both parties is really important. So get it to the developers and help security teams have oversight into what's going on. Like, is my program getting better? Is my development team getting better? Where do I need to spend resources to educate people because they keep making the same mistake? Those kinds of things. Both of those things need to happen, not just one.
- [41:13]
Gregor Vand
Yeah, I think that's some great analysis there. Just kind of as we start to wrap up, looking at at the moment who Stackhawk kind of serves, I believe quite a lot of financial companies is sort of quite a customer base for yourselves. Are there any sort of, I don't know, standout challenges There that's interesting. When it comes to working on financial.
- [41:35]
Scott Gerlach
APIs, I wouldn't say that there's anything that really stands out. I mean especially in financial services kind of vertical. That is financial services, no one walks around going, I'm in the financial services vertical. But the people that are kind of handling investments and money and stuff, that's really important to people. Not only is there a ton of regulation that goes into that, talking about things like Graham Leach Bliley act, which is super fun, government regulations and Sarbanes, Oxley and Soar and all kind like there's all kinds of regulations that go into that and it can really weigh down a company if they're. If you're kind of doing it the old way and wielding the security hammer of compliance. You can however make that an advantage to your company. And tons of our customers are doing that by integrating the security process and making it part of the value prop of being able to go fast and do it securely. There's nothing super, super different about the financial sector and the APIs that they're building and using to handle data. It can be one of the go to market specialties or go to market advantages for those companies to be able to meet all that regulatory compliance, keep that customer data safe and do it fast. Companies like Capital One that are like rapidly iterating using the cloud, being able to go fast, meet regulation and help customers save money, grow their money, spend their money, all the fun money things I think it can be for a ton of those companies an advantage.
- [43:23]
Gregor Vand
Absolutely. As we wrap up, where's the best place to get going with Stackhawk? Where should somebody go?
- [43:30]
Scott Gerlach
You want to try out Stackhawk or you want to, you know, kind of book a demo? Ask one of our awesome team members to show you around. You can do that. @Stackhawk.com There's a free trial. You can always start a free trial of Stackhawk. One of the most annoying things as a security buyer is you can't test a thing before you talk to somebody. So we tried to fix that. But if you just want to doesn't work for how your company works or reach out to us and we'd be happy to give you a demo, help you out, understand how Stackhawk can help your business.
- [44:01]
Gregor Vand
There we go. Stackhawk.com S T A C K H A W K.com well, just one final question that I tend to ask to most guests these days. So you've obviously you've had quite a career say through, through various companies, most of which I think the listener base will have heard of. If you could tell yourself something at the beginning of that journey, you know, now, what would you tell yourself?
- [44:25]
Scott Gerlach
Tell myself something at the beginning that you now know.
- [44:28]
Gregor Vand
Some kind of infinite wisdom that you've picked up over your different roles and this kind of thing. Something that you could tell yourself to sort of. Whether it's just not worry about something or do more of something or less of something. I don't know.
- [44:42]
Scott Gerlach
I think right now it would be get on the air fryer bandwagon earlier.
- [44:47]
Gregor Vand
No, I still don't have one. I live in a country where they're not really a thing, I don't think.
- [44:55]
Scott Gerlach
I feel like I did a ton of stuff right, and that was just dive headfirst into a ton of technologies and get out of your comfort zone and stay out of your comfort zone. Meet new people, understand the way they do, new processes. It took a while, but that's how learning goes. So I think I might tell younger me to have a little more fun in between. That's. That's maybe the one thing. But I had plenty of fun too, so I'm not. I'm not super worried about that.
- [45:25]
Gregor Vand
That's good. That's good. Someone had once say to me a while ago, they wrote me a note and said, have more fun. So I did take that to heart slightly. Clearly I was being a bit too serious about things at times, so that's a good place to end it. Thank you so much, Scott. Coming on, telling us all about stathalk. Sounds like an awesome platform. Definitely something that I'll be looking out for and hope we get to catch up again in the future.
- [45:46]
Scott Gerlach
Sounds great, Gregor. Thanks for having me. Really enjoyed it. Let's air fry something together sometime.
- [45:51]
Gregor Vand
Definitely. Definitely. All right, thanks.