Joni Klippert

What we had to do is become the best possible API security testing platform because that one API route could serve 2000 pages on a website. So let's just scan the route and fix it at source. So it makes it rip and fast. And then when you fix something, it's going to fix downstream.

What we had to do is become the best possible API security testing platform because that one API route could serve 2000 pages on a website. So let's just scan the route and fix it at source. So it makes it rip and fast. And then when you fix something, it's going to fix downstream.

We went to market with rest and so, and then very quickly first to market with GraphQL testing, next GRPC testing, and then continue to add capabilities to make sure that we could test APIs deeper, like not just really dumb fuzzing, but making sure that we're putting in appropriate variables that help pop the right types of vulnerabilities.

We went to market with rest and so, and then very quickly first to market with GraphQL testing, next GRPC testing, and then continue to add capabilities to make sure that we could test APIs deeper, like not just really dumb fuzzing, but making sure that we're putting in appropriate variables that help pop the right types of vulnerabilities.

So there was a lot of time spent on the scanning capability and it was all very developer driven. So we built a product to be automated and to be used by software engineers. And what started to happen in the market is a couple of things. PLG in this space was slowing down as the market was starting to slow down in 2022.

So there was a lot of time spent on the scanning capability and it was all very developer driven. So we built a product to be automated and to be used by software engineers. And what started to happen in the market is a couple of things. PLG in this space was slowing down as the market was starting to slow down in 2022.

A lot of small companies were just trying to be companies and they were buying less software. And then at the same time, we had been in market long enough that we started to get a lot of enterprises and evaluating stuff, which was very exciting. But that's a big change. In looking at our roadmap, it was, who is our ICP? How is it evolving? And what capabilities does this new audience need?

A lot of small companies were just trying to be companies and they were buying less software. And then at the same time, we had been in market long enough that we started to get a lot of enterprises and evaluating stuff, which was very exciting. But that's a big change. In looking at our roadmap, it was, who is our ICP? How is it evolving? And what capabilities does this new audience need?

And so there've been periods in the business where we're building either very strategic, just technology to make sure that we're being relevant, a relevant product in an API driven world. And then there have been initiatives that are, okay, we have an evolving ICP.

And so there've been periods in the business where we're building either very strategic, just technology to make sure that we're being relevant, a relevant product in an API driven world. And then there have been initiatives that are, okay, we have an evolving ICP.

What do these less technical security folks who are ultimately responsible for the security of their applications, but rely on software engineers in order to make sure that they can do their job and build secure applications. What do we build for them? And so we started building more to help the security persona understand more about what was happening in software engineering.

What do these less technical security folks who are ultimately responsible for the security of their applications, but rely on software engineers in order to make sure that they can do their job and build secure applications. What do we build for them? And so we started building more to help the security persona understand more about what was happening in software engineering.

Like, where are my APIs? That's the thing that keeps them up at night. They don't even know. And we're like, they're in your code base. They can start there. Let me help show you where they are and then how fast that landscape is changing. So you know what to put under test. We always identify a large initiative. We build a roadmap around that.

Like, where are my APIs? That's the thing that keeps them up at night. They don't even know. And we're like, they're in your code base. They can start there. Let me help show you where they are and then how fast that landscape is changing. So you know what to put under test. We always identify a large initiative. We build a roadmap around that.

And then we fill in all the stuff that you have to fill in, right? Like customer requests or hardening of our systems. But that's generally how we build a roadmap.

And then we fill in all the stuff that you have to fill in, right? Like customer requests or hardening of our systems. But that's generally how we build a roadmap.

Early on when we were building out our technical team, I looked for experience. I just felt like this is a really interesting problem to solve. I think it's important to solve it. I'm going to hire engineers who have several startups under their belt of building SaaS, building authentication and multi-tenant SaaS, like building like the core pieces and a really scalable infrastructure.

Early on when we were building out our technical team, I looked for experience. I just felt like this is a really interesting problem to solve. I think it's important to solve it. I'm going to hire engineers who have several startups under their belt of building SaaS, building authentication and multi-tenant SaaS, like building like the core pieces and a really scalable infrastructure.

Because the death knell is you hire inexperienced engineers to get an MVP off. And the second you start to get traction in your business, you have to rewrite your code base. That was not going to happen. I picked up really awesome folks that I had met in the Boulder community or had known that I knew would help tee up this platform for success.

Because the death knell is you hire inexperienced engineers to get an MVP off. And the second you start to get traction in your business, you have to rewrite your code base. That was not going to happen. I picked up really awesome folks that I had met in the Boulder community or had known that I knew would help tee up this platform for success.

And then as we expanded outside of engineering, the value that I look for the most is I want to hire people that feel an inappropriate amount of responsibility for their title, for the success of this company. I want them to care so much that they really think about the whole business and everything that they're doing day to make sure we are in a position to succeed and to win.

And then as we expanded outside of engineering, the value that I look for the most is I want to hire people that feel an inappropriate amount of responsibility for their title, for the success of this company. I want them to care so much that they really think about the whole business and everything that they're doing day to make sure we are in a position to succeed and to win.

Sense of responsibility. Now, this is my job and I do this one job. I'll do anything it takes to help make StackHawk successful. And we've really tried to continue to find people with that. It can be hard as you scale, right? And you do start to hire people more specific type employees than generalists.

Sense of responsibility. Now, this is my job and I do this one job. I'll do anything it takes to help make StackHawk successful. And we've really tried to continue to find people with that. It can be hard as you scale, right? And you do start to hire people more specific type employees than generalists.

But that fire in the belly and that level of responsibility is something we really try to screen for.

But that fire in the belly and that level of responsibility is something we really try to screen for.

I think part of hiring really seasoned engineers have kept us out of that problem to date. Early technical decision we made, and I honestly didn't fully understand it as we were making it because I was so used to SaaS-based software, is we decided the deployment mechanism, the scanning capability is deployed in the client site, so via Docker or within your CLI.

I think part of hiring really seasoned engineers have kept us out of that problem to date. Early technical decision we made, and I honestly didn't fully understand it as we were making it because I was so used to SaaS-based software, is we decided the deployment mechanism, the scanning capability is deployed in the client site, so via Docker or within your CLI.

And the choice to do that has a lot of benefit for the customer in that when the scanner is running and it's sending thousands of attacks, you don't want those attacks to traverse the internet because it's going to take a very long time for that scan to run.

And the choice to do that has a lot of benefit for the customer in that when the scanner is running and it's sending thousands of attacks, you don't want those attacks to traverse the internet because it's going to take a very long time for that scan to run.

We decided the deployment mechanism that the scanning capability is deployed in the client site. So via Docker or within your CLI. And the choice to do that has a lot of benefit for the customer. When the scanner's running and it's sending thousands of attacks, you don't want those attacks to traverse the internet because it's going to take a very long time for that scan to run.

We decided the deployment mechanism that the scanning capability is deployed in the client site. So via Docker or within your CLI. And the choice to do that has a lot of benefit for the customer. When the scanner's running and it's sending thousands of attacks, you don't want those attacks to traverse the internet because it's going to take a very long time for that scan to run.

So if it's instead running right next to where your code lives, your code base is that round trip time is really fast and it makes the scanning capability really fast. But the thing that it did for Stemcock is we aren't having to scale the scanning engine ourselves.

So if it's instead running right next to where your code lives, your code base is that round trip time is really fast and it makes the scanning capability really fast. But the thing that it did for Stemcock is we aren't having to scale the scanning engine ourselves.

So it's a very sort of inexpensive and highly scalable platform to run because as the scanner turns on, it's phoning home and we're getting all of the telemetry and streaming results live. And so there's a very heavy SaaS component to the business, but we aren't having to scale and manage scan runners on behalf of customers all over the world. running as many scans as possible.

So it's a very sort of inexpensive and highly scalable platform to run because as the scanner turns on, it's phoning home and we're getting all of the telemetry and streaming results live. And so there's a very heavy SaaS component to the business, but we aren't having to scale and manage scan runners on behalf of customers all over the world. running as many scans as possible.

So that was a very smart technical decision that had benefits for both sort of the cost of running StackHawk, but also the experience for the customer.

So that was a very smart technical decision that had benefits for both sort of the cost of running StackHawk, but also the experience for the customer.

As a product person, what I would quickly say is the product's very elegant. You have brands, household name brands using your product and telling you how much they love it. There is an incredible amount of pride that I feel associated with that. But more than the product, our team is killer. Like our company culture is so much fun. Those early engineers I talked about still work here.

As a product person, what I would quickly say is the product's very elegant. You have brands, household name brands using your product and telling you how much they love it. There is an incredible amount of pride that I feel associated with that. But more than the product, our team is killer. Like our company culture is so much fun. Those early engineers I talked about still work here.

They're five and a half years in and they love coming to work. They love each other. It's just a really special place to be. And when one chooses to work this hard and do something like a startup, part of the value of that is you get to pick the people that you work with and build incredible relationships with them.

They're five and a half years in and they love coming to work. They love each other. It's just a really special place to be. And when one chooses to work this hard and do something like a startup, part of the value of that is you get to pick the people that you work with and build incredible relationships with them.

So for me, the team and the cultural organism that is StackHawk is something that I'm blessed to be a part of and really proud of.

So for me, the team and the cultural organism that is StackHawk is something that I'm blessed to be a part of and really proud of.

We launched the product with a very PLG focus. So easy to try and buy land and expand software. That's everything in DevOps. It's nothing in cybersecurity. It was actually really interesting to investors to be like, OK, you're not the 3000th company trying to sell to a CISO. Those poor people, they're just inundated with enterprise top-down sales. And we're like, no way.

We launched the product with a very PLG focus. So easy to try and buy land and expand software. That's everything in DevOps. It's nothing in cybersecurity. It was actually really interesting to investors to be like, OK, you're not the 3000th company trying to sell to a CISO. Those poor people, they're just inundated with enterprise top-down sales. And we're like, no way.

This is sign up for a trial, use the product, open documentation. And the foundation of the company being that was really important. And I think it still has a lot of value for StockHawk because people can tinker, play, get familiar with the product. And then once they enter a POV in a more enterprise sales cycle, it's super fast because they've had some experience with the product.

This is sign up for a trial, use the product, open documentation. And the foundation of the company being that was really important. And I think it still has a lot of value for StockHawk because people can tinker, play, get familiar with the product. And then once they enter a POV in a more enterprise sales cycle, it's super fast because they've had some experience with the product.

But, you know, the market was shifting. We're moving into more enterprise sales. The top of mind was the most normal stuff, right? Which is, okay, can we close these guys? These are huge customers. Do we have the product for them to be happy and successful? Are there a bunch of features? they need that are different than when you're serving an SMB clientele?

But, you know, the market was shifting. We're moving into more enterprise sales. The top of mind was the most normal stuff, right? Which is, okay, can we close these guys? These are huge customers. Do we have the product for them to be happy and successful? Are there a bunch of features? they need that are different than when you're serving an SMB clientele?

Fortunately, we had built a lot of those. So that was good. Will they grow? Will they adopt? And then can I find more? And I think a mistake we made, we just let it happen to us. We were rapidly trying to answer all of those questions that I just mentioned.

Fortunately, we had built a lot of those. So that was good. Will they grow? Will they adopt? And then can I find more? And I think a mistake we made, we just let it happen to us. We were rapidly trying to answer all of those questions that I just mentioned.

And at the same time, we were spending a lot of money on an inbound focus demand gen marketing motion that works in SMB and it can provide air cover for customers. enterprise sales, but it's a little wasteful because you really have to shift the motion to a more sophisticated enterprise and sometimes top-down sale. And I think we waited too long to do that.

And at the same time, we were spending a lot of money on an inbound focus demand gen marketing motion that works in SMB and it can provide air cover for customers. enterprise sales, but it's a little wasteful because you really have to shift the motion to a more sophisticated enterprise and sometimes top-down sale. And I think we waited too long to do that.

Like I would have augmented the team faster and get more bench in enterprise sales faster rather than making sure we checked off every single box of that handful of questions that I shared early on.

Like I would have augmented the team faster and get more bench in enterprise sales faster rather than making sure we checked off every single box of that handful of questions that I shared early on.

So if it's instead running right next to where your code lives, your code base is, that round trip time is really fast. But the thing that it did for Stemcock is we aren't having to scale the scanning engine ourselves. I'm Joni Klippert, CEO and co-founder of StackHawk.

So if it's instead running right next to where your code lives, your code base is, that round trip time is really fast. But the thing that it did for Stemcock is we aren't having to scale the scanning engine ourselves. I'm Joni Klippert, CEO and co-founder of StackHawk.

Yeah, I think the market is really starting to understand the cybersecurity market, the importance of a really strong API security platform. Early on, and even within the last couple of years, I think there's been a lot of fear from the cybersecurity side of, oh gosh, so many APIs. They're getting released so fast. We can't keep up. We don't know where they are.

Yeah, I think the market is really starting to understand the cybersecurity market, the importance of a really strong API security platform. Early on, and even within the last couple of years, I think there's been a lot of fear from the cybersecurity side of, oh gosh, so many APIs. They're getting released so fast. We can't keep up. We don't know where they are.

With our journey, the evolution has been, okay, create a super fast, can run in pipeline, developer first testing capability. And then it was, okay, we have a great product to test APIs, but our buyer is in cybersecurity and they don't even know what APIs and applications they have. So let's help them.

With our journey, the evolution has been, okay, create a super fast, can run in pipeline, developer first testing capability. And then it was, okay, we have a great product to test APIs, but our buyer is in cybersecurity and they don't even know what APIs and applications they have. So let's help them.

So that was the next piece, which is, okay, this is what your landscape, your tax surface looks like. Here's how fast it's changing. And we can even tell you in advance before an API or an application has been shipped to prod that it's under development. So you can make sure that thing is tested. And what that has illuminated is the scope of the problem.

So that was the next piece, which is, okay, this is what your landscape, your tax surface looks like. Here's how fast it's changing. And we can even tell you in advance before an API or an application has been shipped to prod that it's under development. So you can make sure that thing is tested. And what that has illuminated is the scope of the problem.

If you're a mid-market company, you easily have 1,000 or 2,000 repositories in whatever code repository that you're using. And we see about 30% to 50% of those repositories contain APIs or applications that need to be under test with something like StackHawk.

If you're a mid-market company, you easily have 1,000 or 2,000 repositories in whatever code repository that you're using. And we see about 30% to 50% of those repositories contain APIs or applications that need to be under test with something like StackHawk.

And that is very overwhelming for a security professional to realize that they have to get all of that under test and they need to use their developers to help them.

And that is very overwhelming for a security professional to realize that they have to get all of that under test and they need to use their developers to help them.

The future of our roadmap is pretty AI heavy, but it's AI heavy in that we can do things that allow us to introspect the code base and get all of these assets under test very quickly and remove a lot of sort of the cumbersome human manual tasks components of filling out a YAML file and knowing what your authentication mechanism is.

The future of our roadmap is pretty AI heavy, but it's AI heavy in that we can do things that allow us to introspect the code base and get all of these assets under test very quickly and remove a lot of sort of the cumbersome human manual tasks components of filling out a YAML file and knowing what your authentication mechanism is.

And when you introspect the code base and use AI, it is so much faster. You could have written code for it before, but it would take a long time. And now we can just move a lot faster for our customers. So it's a lot about ease of use and testing your APIs at scale and leveraging AI to help us do that.

And when you introspect the code base and use AI, it is so much faster. You could have written code for it before, but it would take a long time. And now we can just move a lot faster for our customers. So it's a lot about ease of use and testing your APIs at scale and leveraging AI to help us do that.

The first CEO I worked for is a woman that was building technology in the child care, home care industry. And to be perfectly honest, I didn't care at all about what this company did. Like it was not passion of mine at all. But when I met her, I was like, I have to work for this woman. She's just had such a presence. She was so convicted, so strong willed.

The first CEO I worked for is a woman that was building technology in the child care, home care industry. And to be perfectly honest, I didn't care at all about what this company did. Like it was not passion of mine at all. But when I met her, I was like, I have to work for this woman. She's just had such a presence. She was so convicted, so strong willed.

And I was really excited to learn from her. And to this day, that was pre-grad school. She is a coach of mine. And so when I approach her with things about how I work, how I show up for my team, she really helps me with that. And then Todd Vernon, I had the pleasure of working for at Victor Ops.

And I was really excited to learn from her. And to this day, that was pre-grad school. She is a coach of mine. And so when I approach her with things about how I work, how I show up for my team, she really helps me with that. And then Todd Vernon, I had the pleasure of working for at Victor Ops.

And when you are a first-time CEO, a first-time founder, there are a lot of things that come your way that you have never thought about before. and having a great CEO coach and mentor to help you understand what is important. And sometimes to help you realize there actually isn't a decision to be made here. I know you think there is, but here's how this is going to play out.

And when you are a first-time CEO, a first-time founder, there are a lot of things that come your way that you have never thought about before. and having a great CEO coach and mentor to help you understand what is important. And sometimes to help you realize there actually isn't a decision to be made here. I know you think there is, but here's how this is going to play out.

It's really useful to have somebody with so much experience helping to filter through the noise and helping me focus on what is really important in this job. So I am very fortunate to have those two in my corner.

It's really useful to have somebody with so much experience helping to filter through the noise and helping me focus on what is really important in this job. So I am very fortunate to have those two in my corner.

First, congratulations, person. I'm very happy that you were so excited and have built the next great thing. But what I would say is this job, the amount of responsibility associated with being a founder is very high. I'm giving this advice to both the person sitting next to me on the airplane and myself right now. There is a danger a little bit.

First, congratulations, person. I'm very happy that you were so excited and have built the next great thing. But what I would say is this job, the amount of responsibility associated with being a founder is very high. I'm giving this advice to both the person sitting next to me on the airplane and myself right now. There is a danger a little bit.

in no longer being able to discern yourself as a human being from what you do for work. It can be very dangerous to have your identity completely tied to what you do and your company. And so what I would say to this person is enjoy it.

in no longer being able to discern yourself as a human being from what you do for work. It can be very dangerous to have your identity completely tied to what you do and your company. And so what I would say to this person is enjoy it.

And I understand the responsibility and I understand how easy that is, but also to carve out time for the other humans in your life and build tools to be really present with them. Because one day that company won't be your identity anymore.

And I understand the responsibility and I understand how easy that is, but also to carve out time for the other humans in your life and build tools to be really present with them. Because one day that company won't be your identity anymore.

And you want to know who you are when that's all done and have all your champions that have been cheering you on along the way, continuing to have really great relationships with them.

And you want to know who you are when that's all done and have all your champions that have been cheering you on along the way, continuing to have really great relationships with them.

Thank you for having me.

Thank you for having me.

StackHawk is an API security platform. We help teams understand their API landscape and application landscape, which informs what should be tested. And StackHawk has a very robust API security testing platform. which was the very first capability we came out with. There's a realm out there called pen testing, where you hire a human to attack your web properties to ensure that you're safe, right?

StackHawk is an API security platform. We help teams understand their API landscape and application landscape, which informs what should be tested. And StackHawk has a very robust API security testing platform. which was the very first capability we came out with. There's a realm out there called pen testing, where you hire a human to attack your web properties to ensure that you're safe, right?

It's part of SOC 2 compliance. You have to have pen tests on some regular cadence. Maybe it's yearly, six months, quarterly, whatever it might be for your organization. And they attack the running app and they give you a report of vulnerabilities that For us, we believe that much of that, other than the third-party validation, can be automated.

It's part of SOC 2 compliance. You have to have pen tests on some regular cadence. Maybe it's yearly, six months, quarterly, whatever it might be for your organization. And they attack the running app and they give you a report of vulnerabilities that For us, we believe that much of that, other than the third-party validation, can be automated.

So we help companies test their applications and APIs for vulnerabilities, and we help the software engineering team actually fix those bugs before they deploy to production. So I'd been building software for software engineers for about 10 years before we started. I went to a company called VictorOps. They were super early. We were a competitor to PagerDuty.

So we help companies test their applications and APIs for vulnerabilities, and we help the software engineering team actually fix those bugs before they deploy to production. So I'd been building software for software engineers for about 10 years before we started. I went to a company called VictorOps. They were super early. We were a competitor to PagerDuty.

At that business, the idea was, OK, DevOps is a thing. We're deploying code to production so frequently at this time. The idea that you should send alerts about uptime or latency or downtime or anything with your production assets to neckbeards eating Cheetos, watching dashboards, wondering what's going to break, and then they would be the first line of defense to fix things.

At that business, the idea was, OK, DevOps is a thing. We're deploying code to production so frequently at this time. The idea that you should send alerts about uptime or latency or downtime or anything with your production assets to neckbeards eating Cheetos, watching dashboards, wondering what's going to break, and then they would be the first line of defense to fix things.

At the rate that code is changing, there's no way that you could actually pass those alerts to that person. All that's really doing is increasing your time to know and increasing your time to resolve uptime issues.

At the rate that code is changing, there's no way that you could actually pass those alerts to that person. All that's really doing is increasing your time to know and increasing your time to resolve uptime issues.

So when that company, VictorOps, was acquired by Splunk in 2018, I had the opportunity and a lot of support from CEOs I'd worked for and investors to go out on my own and start a new company. And I didn't exactly know what it would be. I know I built a lot of domain and digital transformation over about 10 years. So it's something I knew a lot about.

So when that company, VictorOps, was acquired by Splunk in 2018, I had the opportunity and a lot of support from CEOs I'd worked for and investors to go out on my own and start a new company. And I didn't exactly know what it would be. I know I built a lot of domain and digital transformation over about 10 years. So it's something I knew a lot about.

I started researching what felt like the last mile of DevOps, which is how is it that our security teams are so far behind?

I started researching what felt like the last mile of DevOps, which is how is it that our security teams are so far behind?

I'd be introduced to different security folks during DevOps Days enterprise conferences, and they're like, we're just here to figure out how we can operate in a landscape where teams are deploying to production so fast because none of their tooling or processes were capable of keeping up with that pace. The very first thing I was researching was pen testing as a service.

I'd be introduced to different security folks during DevOps Days enterprise conferences, and they're like, we're just here to figure out how we can operate in a landscape where teams are deploying to production so fast because none of their tooling or processes were capable of keeping up with that pace. The very first thing I was researching was pen testing as a service.

I just thought it's so intellectually dishonest to have a human being attack your application and provide you with a PDF report of your vulnerabilities. And you're like, sweet, we're safe for the next year. Are you kidding? Like you deployed by the time that PDF was printed on a piece of paper. It's already out of date. How do we automate this process?

I just thought it's so intellectually dishonest to have a human being attack your application and provide you with a PDF report of your vulnerabilities. And you're like, sweet, we're safe for the next year. Are you kidding? Like you deployed by the time that PDF was printed on a piece of paper. It's already out of date. How do we automate this process?

And so I talked to 50 different CISOs and VPs of engineering about their experience. And they just kept saying, it's not about the pen test. Third-party validation is great, but there's this technology that they use called DAST. dynamic application security testing. And if you could automate DAST, that would be amazing. And I was like, okay, I'm not that smart. Why is nobody automating DAST?

And so I talked to 50 different CISOs and VPs of engineering about their experience. And they just kept saying, it's not about the pen test. Third-party validation is great, but there's this technology that they use called DAST. dynamic application security testing. And if you could automate DAST, that would be amazing. And I was like, okay, I'm not that smart. Why is nobody automating DAST?

Is this crazy complicated? I know we're about to figure out what it was. That was how the company was founded. And I was on that customer development tour and I met my co-founder, eventual co-founder, Scott Gerlach. And for him, he'd been a practitioner for a long time. So he was the CISO at SendGrid through the acquisition by Twilio.

Is this crazy complicated? I know we're about to figure out what it was. That was how the company was founded. And I was on that customer development tour and I met my co-founder, eventual co-founder, Scott Gerlach. And for him, he'd been a practitioner for a long time. So he was the CISO at SendGrid through the acquisition by Twilio.

And before that, he ran functional security teams throughout GoDaddy for 10 years. And so he also had a very interesting disdain for products that were available because it was his job to try to make cybersecurity tooling accessible and approachable to software engineers in 10, 15 years of operating security teams. And he knew how deficient they were.

And before that, he ran functional security teams throughout GoDaddy for 10 years. And so he also had a very interesting disdain for products that were available because it was his job to try to make cybersecurity tooling accessible and approachable to software engineers in 10, 15 years of operating security teams. And he knew how deficient they were.

And so we totally bonded over how do we support the software engineer and the software engineering lifecycle and also build and maintain secure software. So I met him, let's see, two or three times and said, hey, do you want to do this thing? He fortunately said yes. And that's how the company was started.

And so we totally bonded over how do we support the software engineer and the software engineering lifecycle and also build and maintain secure software. So I met him, let's see, two or three times and said, hey, do you want to do this thing? He fortunately said yes. And that's how the company was started.

The thing that bothered me about this space is there were a couple of open source products available. And anytime there's open source products in the space, people aren't building what's possible. Like, it's interesting. It's like, how come nobody has modified any of these products to... actually make them usable earlier in software delivery lifecycle.

The thing that bothered me about this space is there were a couple of open source products available. And anytime there's open source products in the space, people aren't building what's possible. Like, it's interesting. It's like, how come nobody has modified any of these products to... actually make them usable earlier in software delivery lifecycle.

So we chose an open source scanner that did DAST that had some support for APIs. We got it to run. We looked at the output. And what we realized is part of the problem is DAST was just so hard to use. It's like being in a Michelin star kitchen, right? There are a million tools, but the average human being, they just want to make a sandwich.

So we chose an open source scanner that did DAST that had some support for APIs. We got it to run. We looked at the output. And what we realized is part of the problem is DAST was just so hard to use. It's like being in a Michelin star kitchen, right? There are a million tools, but the average human being, they just want to make a sandwich.

You're like, I don't even know just how to find like a knife and something simple and be able to actually use this capability. It's highly capable in terms of the different tools that are involved, but getting an average person to use it was nearly impossible. So what we decided is, okay, the world doesn't need a better scanner.

You're like, I don't even know just how to find like a knife and something simple and be able to actually use this capability. It's highly capable in terms of the different tools that are involved, but getting an average person to use it was nearly impossible. So what we decided is, okay, the world doesn't need a better scanner.

Oh, I found another six vulnerabilities out of 3000 possible vulnerabilities. What it actually needs is something that people can use. And so we took this open source capability and made it very highly opinionated about how it should run and what the output should be such that it was accessible to software engineers.

Oh, I found another six vulnerabilities out of 3000 possible vulnerabilities. What it actually needs is something that people can use. And so we took this open source capability and made it very highly opinionated about how it should run and what the output should be such that it was accessible to software engineers.

We took something that might take weeks or months to deploy and we made it deployable via Docker and eventually a CLI. So it can run on your machine. It can run in CICD. You could point it at production assets if you wanted to, though that's not what we recommend. We informed it via a YAML file. With a few lines of YAML, I can actually identify a target and get a scan running in just minutes.

We took something that might take weeks or months to deploy and we made it deployable via Docker and eventually a CLI. So it can run on your machine. It can run in CICD. You could point it at production assets if you wanted to, though that's not what we recommend. We informed it via a YAML file. With a few lines of YAML, I can actually identify a target and get a scan running in just minutes.

And then another really important piece was the output as it was finding vulnerabilities in the open source version is it was so hard to discern what to pay attention to. It was just garbage output. And there's a statement that people say in cybersecurity, which is you can't get engineers to care about cybersecurity. That's bullshit. They do care about security. They care about quality.

And then another really important piece was the output as it was finding vulnerabilities in the open source version is it was so hard to discern what to pay attention to. It was just garbage output. And there's a statement that people say in cybersecurity, which is you can't get engineers to care about cybersecurity. That's bullshit. They do care about security. They care about quality.

But if you're a software engineer and your job is to deliver value to the market, and I give you a tool with output like this that's completely undiscernible, there's no way that they can afford to care about this.

But if you're a software engineer and your job is to deliver value to the market, and I give you a tool with output like this that's completely undiscernible, there's no way that they can afford to care about this.

And so we took the output of the scanning capability and made it super easy to bundle by vulnerability type, then the path, then the request response, so that you could just zero in immediately on what is the highest vulnerability, where can I go fix it, and how do I fix it fast so that I can continue my job as a software engineer of writing code.

And so we took the output of the scanning capability and made it super easy to bundle by vulnerability type, then the path, then the request response, so that you could just zero in immediately on what is the highest vulnerability, where can I go fix it, and how do I fix it fast so that I can continue my job as a software engineer of writing code.

So the MVP was in some, it's like taking an open source capability and just making it so easy to use and having a very PLG experience. So something that took weeks or months to instrument, a person could come to StackHawk, they could download the scanner, point it at a target and complete the scan in around seven minutes. I think was one of our fastest deployments.

So the MVP was in some, it's like taking an open source capability and just making it so easy to use and having a very PLG experience. So something that took weeks or months to instrument, a person could come to StackHawk, they could download the scanner, point it at a target and complete the scan in around seven minutes. I think was one of our fastest deployments.

And it was often like seven minutes to 10 minutes. So that was the MVP. And then we ended up adding obviously a bunch of goodies on top of that.

And it was often like seven minutes to 10 minutes. So that was the MVP. And then we ended up adding obviously a bunch of goodies on top of that.

After ease of use, it started to become, how do we test APIs very thoroughly? Legacy DAST tools didn't really have knowledge of how applications were built today. They expected browser-based applications that you would try to spider and you look for places to have inputs, essentially fuzz with inputs, looking for outputs that generated vulnerabilities.

After ease of use, it started to become, how do we test APIs very thoroughly? Legacy DAST tools didn't really have knowledge of how applications were built today. They expected browser-based applications that you would try to spider and you look for places to have inputs, essentially fuzz with inputs, looking for outputs that generated vulnerabilities.

What we had to do is become the best possible API security testing platform because that one API route could serve 2000 pages on a website. So let's just scan the route and fix it at source. So it makes it rip and fast. And then when you fix something, it's going to fix downstream.

We went to market with rest and so, and then very quickly first to market with GraphQL testing, next GRPC testing, and then continue to add capabilities to make sure that we could test APIs deeper, like not just really dumb fuzzing, but making sure that we're putting in appropriate variables that help pop the right types of vulnerabilities.

So there was a lot of time spent on the scanning capability and it was all very developer driven. So we built a product to be automated and to be used by software engineers. And what started to happen in the market is a couple of things. PLG in this space was slowing down as the market was starting to slow down in 2022.

A lot of small companies were just trying to be companies and they were buying less software. And then at the same time, we had been in market long enough that we started to get a lot of enterprises and evaluating stuff, which was very exciting. But that's a big change. In looking at our roadmap, it was, who is our ICP? How is it evolving? And what capabilities does this new audience need?

And so there've been periods in the business where we're building either very strategic, just technology to make sure that we're being relevant, a relevant product in an API driven world. And then there have been initiatives that are, okay, we have an evolving ICP.

What do these less technical security folks who are ultimately responsible for the security of their applications, but rely on software engineers in order to make sure that they can do their job and build secure applications. What do we build for them? And so we started building more to help the security persona understand more about what was happening in software engineering.

Like, where are my APIs? That's the thing that keeps them up at night. They don't even know. And we're like, they're in your code base. They can start there. Let me help show you where they are and then how fast that landscape is changing. So you know what to put under test. We always identify a large initiative. We build a roadmap around that.

And then we fill in all the stuff that you have to fill in, right? Like customer requests or hardening of our systems. But that's generally how we build a roadmap.

Early on when we were building out our technical team, I looked for experience. I just felt like this is a really interesting problem to solve. I think it's important to solve it. I'm going to hire engineers who have several startups under their belt of building SaaS, building authentication and multi-tenant SaaS, like building like the core pieces and a really scalable infrastructure.

Because the death knell is you hire inexperienced engineers to get an MVP off. And the second you start to get traction in your business, you have to rewrite your code base. That was not going to happen. I picked up really awesome folks that I had met in the Boulder community or had known that I knew would help tee up this platform for success.

And then as we expanded outside of engineering, the value that I look for the most is I want to hire people that feel an inappropriate amount of responsibility for their title, for the success of this company. I want them to care so much that they really think about the whole business and everything that they're doing day to make sure we are in a position to succeed and to win.

Sense of responsibility. Now, this is my job and I do this one job. I'll do anything it takes to help make StackHawk successful. And we've really tried to continue to find people with that. It can be hard as you scale, right? And you do start to hire people more specific type employees than generalists.

But that fire in the belly and that level of responsibility is something we really try to screen for.

I think part of hiring really seasoned engineers have kept us out of that problem to date. Early technical decision we made, and I honestly didn't fully understand it as we were making it because I was so used to SaaS-based software, is we decided the deployment mechanism, the scanning capability is deployed in the client site, so via Docker or within your CLI.

And the choice to do that has a lot of benefit for the customer in that when the scanner is running and it's sending thousands of attacks, you don't want those attacks to traverse the internet because it's going to take a very long time for that scan to run.

We decided the deployment mechanism that the scanning capability is deployed in the client site. So via Docker or within your CLI. And the choice to do that has a lot of benefit for the customer. When the scanner's running and it's sending thousands of attacks, you don't want those attacks to traverse the internet because it's going to take a very long time for that scan to run.

So if it's instead running right next to where your code lives, your code base is that round trip time is really fast and it makes the scanning capability really fast. But the thing that it did for Stemcock is we aren't having to scale the scanning engine ourselves.

So it's a very sort of inexpensive and highly scalable platform to run because as the scanner turns on, it's phoning home and we're getting all of the telemetry and streaming results live. And so there's a very heavy SaaS component to the business, but we aren't having to scale and manage scan runners on behalf of customers all over the world. running as many scans as possible.

So that was a very smart technical decision that had benefits for both sort of the cost of running StackHawk, but also the experience for the customer.

As a product person, what I would quickly say is the product's very elegant. You have brands, household name brands using your product and telling you how much they love it. There is an incredible amount of pride that I feel associated with that. But more than the product, our team is killer. Like our company culture is so much fun. Those early engineers I talked about still work here.

They're five and a half years in and they love coming to work. They love each other. It's just a really special place to be. And when one chooses to work this hard and do something like a startup, part of the value of that is you get to pick the people that you work with and build incredible relationships with them.

So for me, the team and the cultural organism that is StackHawk is something that I'm blessed to be a part of and really proud of.

We launched the product with a very PLG focus. So easy to try and buy land and expand software. That's everything in DevOps. It's nothing in cybersecurity. It was actually really interesting to investors to be like, OK, you're not the 3000th company trying to sell to a CISO. Those poor people, they're just inundated with enterprise top-down sales. And we're like, no way.

This is sign up for a trial, use the product, open documentation. And the foundation of the company being that was really important. And I think it still has a lot of value for StockHawk because people can tinker, play, get familiar with the product. And then once they enter a POV in a more enterprise sales cycle, it's super fast because they've had some experience with the product.

But, you know, the market was shifting. We're moving into more enterprise sales. The top of mind was the most normal stuff, right? Which is, okay, can we close these guys? These are huge customers. Do we have the product for them to be happy and successful? Are there a bunch of features? they need that are different than when you're serving an SMB clientele?

Fortunately, we had built a lot of those. So that was good. Will they grow? Will they adopt? And then can I find more? And I think a mistake we made, we just let it happen to us. We were rapidly trying to answer all of those questions that I just mentioned.

And at the same time, we were spending a lot of money on an inbound focus demand gen marketing motion that works in SMB and it can provide air cover for customers. enterprise sales, but it's a little wasteful because you really have to shift the motion to a more sophisticated enterprise and sometimes top-down sale. And I think we waited too long to do that.

Like I would have augmented the team faster and get more bench in enterprise sales faster rather than making sure we checked off every single box of that handful of questions that I shared early on.

So if it's instead running right next to where your code lives, your code base is, that round trip time is really fast. But the thing that it did for Stemcock is we aren't having to scale the scanning engine ourselves. I'm Joni Klippert, CEO and co-founder of StackHawk.

Yeah, I think the market is really starting to understand the cybersecurity market, the importance of a really strong API security platform. Early on, and even within the last couple of years, I think there's been a lot of fear from the cybersecurity side of, oh gosh, so many APIs. They're getting released so fast. We can't keep up. We don't know where they are.

With our journey, the evolution has been, okay, create a super fast, can run in pipeline, developer first testing capability. And then it was, okay, we have a great product to test APIs, but our buyer is in cybersecurity and they don't even know what APIs and applications they have. So let's help them.

So that was the next piece, which is, okay, this is what your landscape, your tax surface looks like. Here's how fast it's changing. And we can even tell you in advance before an API or an application has been shipped to prod that it's under development. So you can make sure that thing is tested. And what that has illuminated is the scope of the problem.

If you're a mid-market company, you easily have 1,000 or 2,000 repositories in whatever code repository that you're using. And we see about 30% to 50% of those repositories contain APIs or applications that need to be under test with something like StackHawk.

And that is very overwhelming for a security professional to realize that they have to get all of that under test and they need to use their developers to help them.

The future of our roadmap is pretty AI heavy, but it's AI heavy in that we can do things that allow us to introspect the code base and get all of these assets under test very quickly and remove a lot of sort of the cumbersome human manual tasks components of filling out a YAML file and knowing what your authentication mechanism is.

And when you introspect the code base and use AI, it is so much faster. You could have written code for it before, but it would take a long time. And now we can just move a lot faster for our customers. So it's a lot about ease of use and testing your APIs at scale and leveraging AI to help us do that.

The first CEO I worked for is a woman that was building technology in the child care, home care industry. And to be perfectly honest, I didn't care at all about what this company did. Like it was not passion of mine at all. But when I met her, I was like, I have to work for this woman. She's just had such a presence. She was so convicted, so strong willed.

And I was really excited to learn from her. And to this day, that was pre-grad school. She is a coach of mine. And so when I approach her with things about how I work, how I show up for my team, she really helps me with that. And then Todd Vernon, I had the pleasure of working for at Victor Ops.

And when you are a first-time CEO, a first-time founder, there are a lot of things that come your way that you have never thought about before. and having a great CEO coach and mentor to help you understand what is important. And sometimes to help you realize there actually isn't a decision to be made here. I know you think there is, but here's how this is going to play out.

It's really useful to have somebody with so much experience helping to filter through the noise and helping me focus on what is really important in this job. So I am very fortunate to have those two in my corner.

First, congratulations, person. I'm very happy that you were so excited and have built the next great thing. But what I would say is this job, the amount of responsibility associated with being a founder is very high. I'm giving this advice to both the person sitting next to me on the airplane and myself right now. There is a danger a little bit.

in no longer being able to discern yourself as a human being from what you do for work. It can be very dangerous to have your identity completely tied to what you do and your company. And so what I would say to this person is enjoy it.

And I understand the responsibility and I understand how easy that is, but also to carve out time for the other humans in your life and build tools to be really present with them. Because one day that company won't be your identity anymore.

And you want to know who you are when that's all done and have all your champions that have been cheering you on along the way, continuing to have really great relationships with them.

Thank you for having me.

StackHawk is an API security platform. We help teams understand their API landscape and application landscape, which informs what should be tested. And StackHawk has a very robust API security testing platform. which was the very first capability we came out with. There's a realm out there called pen testing, where you hire a human to attack your web properties to ensure that you're safe, right?

It's part of SOC 2 compliance. You have to have pen tests on some regular cadence. Maybe it's yearly, six months, quarterly, whatever it might be for your organization. And they attack the running app and they give you a report of vulnerabilities that For us, we believe that much of that, other than the third-party validation, can be automated.

So we help companies test their applications and APIs for vulnerabilities, and we help the software engineering team actually fix those bugs before they deploy to production. So I'd been building software for software engineers for about 10 years before we started. I went to a company called VictorOps. They were super early. We were a competitor to PagerDuty.

At that business, the idea was, OK, DevOps is a thing. We're deploying code to production so frequently at this time. The idea that you should send alerts about uptime or latency or downtime or anything with your production assets to neckbeards eating Cheetos, watching dashboards, wondering what's going to break, and then they would be the first line of defense to fix things.

At the rate that code is changing, there's no way that you could actually pass those alerts to that person. All that's really doing is increasing your time to know and increasing your time to resolve uptime issues.

So when that company, VictorOps, was acquired by Splunk in 2018, I had the opportunity and a lot of support from CEOs I'd worked for and investors to go out on my own and start a new company. And I didn't exactly know what it would be. I know I built a lot of domain and digital transformation over about 10 years. So it's something I knew a lot about.

I started researching what felt like the last mile of DevOps, which is how is it that our security teams are so far behind?

I'd be introduced to different security folks during DevOps Days enterprise conferences, and they're like, we're just here to figure out how we can operate in a landscape where teams are deploying to production so fast because none of their tooling or processes were capable of keeping up with that pace. The very first thing I was researching was pen testing as a service.

I just thought it's so intellectually dishonest to have a human being attack your application and provide you with a PDF report of your vulnerabilities. And you're like, sweet, we're safe for the next year. Are you kidding? Like you deployed by the time that PDF was printed on a piece of paper. It's already out of date. How do we automate this process?

And so I talked to 50 different CISOs and VPs of engineering about their experience. And they just kept saying, it's not about the pen test. Third-party validation is great, but there's this technology that they use called DAST. dynamic application security testing. And if you could automate DAST, that would be amazing. And I was like, okay, I'm not that smart. Why is nobody automating DAST?

Is this crazy complicated? I know we're about to figure out what it was. That was how the company was founded. And I was on that customer development tour and I met my co-founder, eventual co-founder, Scott Gerlach. And for him, he'd been a practitioner for a long time. So he was the CISO at SendGrid through the acquisition by Twilio.

And before that, he ran functional security teams throughout GoDaddy for 10 years. And so he also had a very interesting disdain for products that were available because it was his job to try to make cybersecurity tooling accessible and approachable to software engineers in 10, 15 years of operating security teams. And he knew how deficient they were.

And so we totally bonded over how do we support the software engineer and the software engineering lifecycle and also build and maintain secure software. So I met him, let's see, two or three times and said, hey, do you want to do this thing? He fortunately said yes. And that's how the company was started.

The thing that bothered me about this space is there were a couple of open source products available. And anytime there's open source products in the space, people aren't building what's possible. Like, it's interesting. It's like, how come nobody has modified any of these products to... actually make them usable earlier in software delivery lifecycle.

So we chose an open source scanner that did DAST that had some support for APIs. We got it to run. We looked at the output. And what we realized is part of the problem is DAST was just so hard to use. It's like being in a Michelin star kitchen, right? There are a million tools, but the average human being, they just want to make a sandwich.

You're like, I don't even know just how to find like a knife and something simple and be able to actually use this capability. It's highly capable in terms of the different tools that are involved, but getting an average person to use it was nearly impossible. So what we decided is, okay, the world doesn't need a better scanner.

Oh, I found another six vulnerabilities out of 3000 possible vulnerabilities. What it actually needs is something that people can use. And so we took this open source capability and made it very highly opinionated about how it should run and what the output should be such that it was accessible to software engineers.

We took something that might take weeks or months to deploy and we made it deployable via Docker and eventually a CLI. So it can run on your machine. It can run in CICD. You could point it at production assets if you wanted to, though that's not what we recommend. We informed it via a YAML file. With a few lines of YAML, I can actually identify a target and get a scan running in just minutes.

And then another really important piece was the output as it was finding vulnerabilities in the open source version is it was so hard to discern what to pay attention to. It was just garbage output. And there's a statement that people say in cybersecurity, which is you can't get engineers to care about cybersecurity. That's bullshit. They do care about security. They care about quality.

But if you're a software engineer and your job is to deliver value to the market, and I give you a tool with output like this that's completely undiscernible, there's no way that they can afford to care about this.

And so we took the output of the scanning capability and made it super easy to bundle by vulnerability type, then the path, then the request response, so that you could just zero in immediately on what is the highest vulnerability, where can I go fix it, and how do I fix it fast so that I can continue my job as a software engineer of writing code.

So the MVP was in some, it's like taking an open source capability and just making it so easy to use and having a very PLG experience. So something that took weeks or months to instrument, a person could come to StackHawk, they could download the scanner, point it at a target and complete the scan in around seven minutes. I think was one of our fastest deployments.

And it was often like seven minutes to 10 minutes. So that was the MVP. And then we ended up adding obviously a bunch of goodies on top of that.

After ease of use, it started to become, how do we test APIs very thoroughly? Legacy DAST tools didn't really have knowledge of how applications were built today. They expected browser-based applications that you would try to spider and you look for places to have inputs, essentially fuzz with inputs, looking for outputs that generated vulnerabilities.