Interview with Scott Gerlach, Co-founder and Chief Security Officer at StackHawk, an AppSec company based in Denver, CO.
Hi Scott. Thanks for taking the time to chat today. Could you share a bit about your background?
I spent about ten years working in many different aspects of security. At GoDaddy, I worked in areas from operations to engineering to architecture. I moved on to CSO and architect work at SendGrid through the Twilio acquisition, and after that, I took some time off, during which I met Joni Klippert, the CEO and co-founder of StackHawk. We started talking about application security and its problems and what we could do to change how AppSec works. Today, I’m CSO and co-founder at StackHawk. My current role involves a lot of different duties, like heavy product and marketing input, working with the pre-sales technical engineers and solutions architects, and handling IT and security.
What makes StackHawk different from other cybersecurity companies?
There’s a lot of things that makes us different. Number one, while what we do is serious business, we don’t take ourselves overly seriously. If you look at our website or attend a talk we’re presenting, there’s a lot of humor and trying to have fun at what we do. That seems to be a lot different from a lot other cybersecurity companies out there. Second, we’re really focused on changing how security folks operate to get developers involved. We believe that developers are the only people who can fix problems in AppSec because they’re the ones who write code and they’re the ones who can fix code.
It is one of the things Joni and I talked about—why are developers the last people in the security loop? It just seems antithetical to anything that makes sense around application security programs. Our design and features and everything we do is geared to help developers find vulnerabilities as soon as possible so they can get back to their other primary job. A third thing that makes us different is our deep belief in dynamic application and API security testing (DAST). I strongly believe in DAST and have used it in every role I’ve been in. It helps us prioritize what the problems are and what problems you need to fix. If DAST can find a problem, it's probably something that is discoverable by others and, hence, exploitable. Overall, we’re taking much less of a black box approach to security, but rather a gray box that determines how code is related to an application we’re testing and we can infer problems from that.
Let’s talk about StackHawk’s products. Tell me about what your products do and what’s new on the horizon?
StackHawk breaks down the silos between dev and security teams to create a more efficient way to deploy security-tested software. By playing a leading role in the industry-wide "shift security left" concept, StackHawk enables engineers to own security testing for their APIs and applications, while simplifying the process to deliver secure code.
As mentioned, the reason Joni and I started the company was around that notion of developers being the last to know in the security loop. With that in mind we focused on building a modern DAST solution that enables developers to easily find and fix security vulnerabilities prior to pushing to production. StackHawk’s emphasis on developer workflows is a clear differentiator. StackHawk delivers API and application security testing that’s automated in CI/CD, provides complete coverage across modern APIs including gRPC, GraphQL, REST and SOAP, and compliments a number of developer-first integrations.
As a developer-first tool, StackHawk gives the flexibility to create custom scripts to test specific scenarios and use integrations with core SAST solutions like Snyk Code and GitHub GraphQL to provide correlated findings and insights into the most important vulnerabilities to fix.
As far as what's on the horizon, we're taking an emphatic approach to deeper and more thorough API Security testing, addressing visibility into applications and API routes, giving security teams improved insights via their code repositories (check out our GitHub Insights currently in open beta), and connecting code to applications via an outside in/inside out approach with security monitoring platforms like Salt Security (inaugural partner for their STEP program).
What do you think are some of the challenges facing StackHawk and serving your clients needs?
Market conditions is one of the biggest challenges, but outside of that, when I talk to other CISOs, prospects and customers, I find there is a disconnect between application security—or in our case, application security testing—and API security and API security testing. I think they are the same things but clearly the market doesn’t. APIs are web applications but almost no one else thinks of it like that. I was talking to someone recently who asked what our company did. I said we do dynamic application security testing. He's like, oh, that's a bummer, we only have APIs, and I was like no man, we do that. That is exactly what we do, but he just didn't think about it that way. Trying to change the perception that API security testing and application security testing are or should be different is probably the biggest challenge.
Building on that, what are other misconceptions that your clients have about application security and API security?
I just mentioned what’s probably the biggest one. Another one that’s interesting is the single page app stuff and not really focusing on API-first testing for API-driven applications. That’s because of how the app security market started. Everyone was trying to build the best JavaScript parser/browser interaction, and that turns into a zero-sum game. So it’s changing the perspective of needing to drive the front end to this API.
How do you address risk with your customers?
We try to keep it simple. I’m a big believer in the KISS principle. You’ll see three different kind of criticality rankings in our system – high, medium, and low. We try to keep it developer focused. The first thing you’ll see in a vulnerability description in StackHawk is how do I fix this. What is remediation going to look like for this problem? If we talk about these things to the right people, they get fixed.
What do you see as some of the biggest challenges in cybersecurity in general, now and into the future?
I think it is just following the evolutions of technology. The problems that are here now are probably always going to exist. We’re not going to have enough people. The people resource budget is always going to be tough to justify because it is hard to put capital investment in people to scale at the same rate as your need to scale engineering. We could train for every open cybersecurity job and still be behind. And then it is just a matter of keeping up with all the new technology—every new technology introduced in the past five years has come with a cybersecurity problem. There was the cloud, there was Web3 and crypto, and now there’s AI and LLMs.
There are always tons of new attack vectors that come up, and we get pretty good at protecting them. But one thing I don’t see as changing is API development. API development is insanely fast, and the vast majority of companies deploy changes or updates to APIs a couple times a week. They’re constantly adding new APIs. The ability to design systems and maintain those processes at that scale is going to be a skill infosec teams will need to learn. So I think that in the near future, the speed of deployments of APIs is going to be our biggest cybersecurity challenge.
By Sue Poremba
Twingly offers a Dark Web API that provides access to over 16 million posts, articles, and documents each month from the Tor network, pastebins, Telegram, as well as various marketplaces, forums, networks, and free speech platforms. Additionally, for forums on the open web, we offer a Forums API that grants access to over 10 million forum posts every day.
