The application security testing market is bursting with tools options—commercial, open source, and proprietary, and across numerous categories including static application security testing (SAST), dynamic application security testing (DAST), interactive application security testing (IAST), mobile application security testing (MAST), web app testing, software composition analysis, and dependency analysis. It’s a lot for security teams to cover. Even more so for developers.
For years, security teams spent considerable effort trying to work their way into development lifecycles and ensure that code deployed into production was as secure as it could be. But the attempt at DevSecOps wasn’t entirely successful; developers felt the processes introduced by outside (a.k.a., security) teams were cumbersome and in conflict with development goals. Over time, security realized that anything which slowed down deployment wasn’t going to be accepted, thus the market adapted and security testing tools were developed to better integrate with the CI/CD pipeline.
Developer-friendly tools helped developers grow more security conscious, which in turn made security teams happier and reduced enterprise risk of application exploit. Today, dev teams regularly use multiple application security testing tools throughout their build-deploy lifecycles, yet many of the tools are focused on applications/software already in production. While finding bugs and software vulnerabilities at any (or every) stage is important, the founders of StackHawk wondered why the AppSec testing market hadn’t shifted left as readily as other security tools categories.
Building software for software engineers
Prior to the formation of StackHawk, Joni Klippert, CEO, was building software for software engineers and realized many companies were only assessing their products and services once per year during an annual pen test. She knew a once-a-year strategy wasn’t sufficient for any other parts of the security program and thought there should be a way to move application testing into the hands of developers, automate it, and make sure it was being done all throughout development, not just at the end stages.
Around the same time, Scott Gerlach, Klippert’s co-founder and CISO, was working in AppSec, helping developers engage with security. Given the priorities and pressures of dev groups, it wasn’t always easy to find a meeting ground between development and security, but Gerlach knew that developers cared about security; the trick was finding ways to empower developers with security rather than insert it in a way that hindered their workflow. He also knew that developers would rather find and fix vulnerabilities as the code was being written (or used, in the case of open source) instead of having to double back after an app was already in production.
Klippert and Gerlach joined forces in May 2019, along with their third co-founder, Ryan Severns, to build a new application security testing tool that would address all their concerns: ongoing assessments during development which allow developers to find and fix vulnerabilities immediately, but which are written in the language of development (vs. security) and integrate with development tools, in line with dev workflows.
Within three months of ideation, the founding team was writing the code that would become the foundation of their current product. Along the way, they realized that “the world doesn’t need a better scanner,” said Gerlach during a recent briefing, “we need a scanner developers will use and that’s easy to put in the pipeline.” Their focus was thus building a DAST product that was easy to run and was built on the best-of-breed OWASP ZAP. This element was and remains important to them because they knew ZAP is widely used, is trusted by developers, and is continuously maintained.
Deployable via Docker
Deployable via Docker, StackHawk can run anywhere—a developer’s local machine, in a container, as an integration with dev-specific software like Jira—and scans the running application on every merge or pull request (PR). Klippert explained that the purpose of this model is to allow developers to “find issues on smaller bits of code,” making them easier to fix before production (PROD). However, StackHawk isn’t recommending developers throw away other types of testing; production scanning remains important and necessary, but the idea with automated pre-production scans is eliminating or reducing the number of vulnerabilities that make it into deployed software. The analog, said Gerlach, is integration or unit testing.
Klippert and Gerlach are enthusiastic about positioning StackHawk, the platform, and HawkScan, the company’s dedicated scanner, as development tools rather than a security platform, even though secure code is the goal. They want to change the perception of application security from laborious to easy, slow to fast, burdensome to painless.
The company provides step-by-step YAML configuration instructions for both the platform and the scanner on its website. With the tools in place, HawkScan tests applications—wherever they are in the CI/CD pipeline—for bugs and the platform provides continuous updates on findings, remediation recommendations, risk, and prioritization. Users can create and/or assign tickets directly from the platform, though Gerlach said he’s found that many developers prefer to “fix on the fly” as bugs are found. “They’re already in the application,” he said, highlighting the fact that developers like to work fast and efficiently.
Security in early stages
Given the plethora of products available, I asked what makes StackHawk truly different, because, let’s face it, one of the most common phrases heard in vendor sales pitches is that X tool integrates seamlessly into the CI/CD pipeline and is developer friendly. Klippert responded that StackHawk, “allows developers to successfully use a security tool without feeling like it’s a security tool. And it gives them the opportunity to fix security flaws in dev mode—no other product is trying to tackle that.” Gerlach pointed out that they chose to focus their product on DAST (vs. the other *ASTs) because it’s not language specific, which gives developers more flexibility and the ability to try new languages or methods as they evolve.
In short, StackHawk’s message is that their product is a “super easy “development tool that alleviates the need to wait until applications are in PROD before finding vulnerabilities—or before a threat actor does. Coming in early into the development lifecycle is an attractive proposition, both for development lifecycles and for security teams. Since the platform is lightweight and quick to deploy through Docker, devs should feel instantly comfortable with it.
The challenge for an up and coming company is going to be the already-crowded market and that many entrenched players in the application security testing space offer great solutions. However, StackHawk is still young and nimble and will likely be a top choice for smaller, nimble development shops that love the idea of innovation and a tool built by developers for developers. Security pros, in turn, will love that it nips bugs in the bud before they become business risks.
