Getting untested apps under test.

Security can’t test what it doesn’t know exists.

StackHawk tests APIs for security bugs. Customers pointed us at the APIs they knew about. We tested those well, and then the account stopped growing. I’d been running product for about a year by then. In January 2024 my title changed to VP of Product & Design. API Discovery was the first feature I owned from strategy to ship.

“

A security engineer told us they owned the security of hundreds of applications, had never talked to the teams who built them, and needed help deciding what to test first.

A company often has one security person for every 1,000 engineers, and those engineers ship code every day. It’s very rare for security to have an up-to-date list of every application and API that development is actively working on and shipping to production. The developers don’t have one either, because nobody asked them to keep it. Security is on the hook for testing everything and doesn’t know what exists. Engineering knows what exists, spread across a thousand repositories, and nobody there owns testing it. So security spends the week on its heels, testing only the most critical things, often after they’re already in production, and asking in Slack what a repository is and who owns it.

The customer tested the ten things they could name. The other two hundred sat untested. Asking them to build that list was never going to work, so we built it from their code.

If an application or API exists, its code is in a repository somewhere, and that code says what it is, what it talks to, and whether anyone is testing it. Code was being shipped and APIs released faster and faster. The repository is the first place a new one shows up.

The vendors we were up against mostly tried to find APIs by watching network traffic. We looked at partnering with adjacent companies for this data, and it was a hard sell. Almost none of those companies could think about an API from its source code. They looked at the problem from the outside in, from the internet, instead of from the inside out, from the code.

One customer’s security team tracked what they could from API documentation and load balancer traffic, and had no plan to look at the source code. New API routes kept appearing without their knowledge.

We already had a start on reading the code. In 2023 we shipped a GitHub integration that pulled a customer’s repositories into StackHawk, let them create applications to test in bulk, and invited the developers who committed to that code. It went to beta at the end of August 2023 and to every customer at the end of October. Teams that used it put 55% more apps under test.

In January 2024 I made that the center of the product strategy. The GitHub integration became API Discovery, a strategic bet on a shift in how companies get their apps and APIs tested. We shifted all of product, sales, and support to make API Discovery the foundation of our approach to application security testing.

Getting API Discovery on the roadmap that quarter meant setting the hosted scanner aside, the number one requested feature from almost every customer and prospect. My job was to turn that into real work. I built out the roadmap, prioritized the other work, and got the team focused on the shift and on building the new feature. API Discovery shipped on time in the first quarter of 2024.

Before launch, I redesigned the MVP myself because I needed to ground the strategy in the app and get it on the roadmap fast. I worked from internal feedback, direction from the founders, and my latest conversations with customers. The job was to bring to light what already existed, the actual attack surface, read straight from the code repositories.

“

A security lead told us they wouldn’t trust it until they saw their own data in the attack surface.

A security engineer connects their source control, and a minute later they’re on the API Discovery page, looking at everything their company has built, sorted by what’s tested and what isn’t. I called it the aha moment.

I studied how other security dashboards showed an attack surface, then rebuilt ours. The page shows what exists across the repositories and what’s under test. The security team can turn any untested item into a test plan and hand it to the team that owns the code.

In its first quarter, API Discovery scanned thousands of repositories, and about a third of them contained an application nobody was testing. Customers told us mapping their repositories to testable applications took a year. API Discovery did it in 15 minutes.

By the third quarter, more than 50 customers had mapped discovered repositories to an application to test, well past our goal. Several customers that had been testing a couple of applications were testing several times that. That quarter, new sales opportunities and total pipeline set a company record, and we traced it to the API Discovery launch. Net dollar retention reached 138%, meaning existing customers spent 38% more than the year before, with API Discovery a big driver.

API Discovery kept watching after the first scan. It saw every time a repository was added or changed in the customer’s source control, the system where their code lives, like GitHub. Because it read the code itself, it told security what each repository was built with, which APIs it held, whether those APIs handled sensitive data and what kind, how often the code changed, and who made the commits. Security could finally see what engineering was doing and how those teams worked.

That let security hand part of the testing to the developers writing the code. Developers ran StackHawk scans while they worked, before anything reached pre-production, and fixed what it found. The industry calls this shifting left, which means moving testing earlier, closer to when the code is written. Security kept its time for the business-critical services and APIs.

Right after the first version shipped, two customers told us the same story. An engineering team had started a brand-new codebase, and API Discovery showed it to security right away. In both cases security sat down with that team before the engineers were off and running.

“

Another customer told us API Discovery flagged a new repository within two minutes and indicated it was a testable API. That was enough for security to go to the developer and work out how to get it under test.

Sensitive data detection followed in June 2025. It scans the same repositories for personal, payment, and health data and shows what it finds in the attack surface, next to each repository. Security could see which untested APIs handled customer data and test those first.

In August, OpenAPI spec generation started writing specs from the source code with AI. A spec tells the scanner how an API is built, its routes and the parameters each one takes. Most APIs have none, and writing one by hand is slow work that rarely gets done. The AI reads the code, writes the spec, and updates it every time the code changes. The scanner pulls the AI-written spec straight from StackHawk, so a discovered API goes into automated testing without anyone writing a spec by hand. The hosted scanner shipped in September and runs scans from StackHawk’s infrastructure, so customers don’t have to set up a scanner of their own.

At one customer, API Discovery found well over a hundred APIs, and only a handful had specs. After OpenAPI spec generation shipped, they put dozens more applications under test. Their team built a pipeline that generates specs from their code, runs StackHawk scans in CI/CD, and breaks the build when a scan fails. Within weeks it scanned a new service, found critical vulnerabilities, and stopped it from deploying to production.