StackHawk’s Free Developer Plan: Application Security Testing for All
By: Ryan Severns
Tags: Security, Software Testing, Application Security, Software Development, Software Engineering

Today we are excited to announce the launch of StackHawk’s free Developer Plan. With this launch, engineering teams or individual developers can take ownership of security in the development and delivery of their applications. Read on to learn a bit more about why we are so excited to launch this, or jump right in to sign up for a free account.

Application Security’s New Paradigm

It is no secret that the speed of application delivery has rapidly accelerated over the past decade. Most companies are pushing to production several times per week, or even multiple times per day. Originally, security struggled to keep up, with the dated models of quarterly penetration tests or manual scans by security teams clearly no longer cutting it.

These legacy models were predicated on finding vulnerabilities in production, often awhile after code had been deployed. This is at best, inefficient, and at worst a security issue. Once a vulnerability was found, it then had to navigate internal silos to actually get a fix released.

Modern engineering teams, however, have not only accelerated delivery speed, but have also improved security in the process. Here is how.

Find Vulnerabilities with CI/CD Automation

Companies using modern approaches check for security vulnerabilities on every pull request (or even every commit) in the same way that they run unit tests and integration tests. With automated testing in CI/CD, developers can catch vulnerabilities early in the software development lifecycle, and fix issues while they are still in the context of the code.

After an initial triage of any existing security bugs, application security tooling should at least be configured to break the build if any new high criticality vulnerabilities are identified. This doesn’t mean that every vulnerability should prevent a deploy to production, but that deploy should be done eyes wide open to the risk it presents.

Triage and Initial Risk Decisions Live with Developers

When a vulnerability is found, the developer(s) who were recently working on the application are best equipped to review the finding and make risk-based decisions. Should this block the deploy to production? Can this be added to a backlog and addressed later? Is this low enough risk that it isn’t worth fixing?

The individuals who are intimately involved in creating the application are best equipped as the first-line of defense for these decisions. Internal security teams are undoubtedly called upon for clarification and support (…and are often reviewing historical decisions as well), but modern teams are empowering developers to make these triage decisions themselves.

Fast Developer Fixes

When a security bug requires a fix, the responsibility for the fix squarely lives with the developer who introduced the vulnerability in modern teams. This individual is in the codebase, familiar with the context of the recent vulnerability addition. Not only are they best equipped to implement the fix, but by democratizing this responsibility across the team, no person or team bears the burden of interrupt driven work.

Taking Ownership of Application Security

Ever since we embarked upon building StackHawk, we have been laser focused on building a tool for developers. The market is rife with security tools built for the CISO that no developer wants to use, and these tools typically start at six-figure contracts. StackHawk is different, and we are excited to equip engineers to own the security of their application. This shows up in our product, and with our new free Developer Plan, it also shows up in our pricing.

Now individuals or teams can start running application security tests against their first application for free. There is no longer an excuse not to be looking at the security of your application.

Getting started with StackHawk is easy, with most developers completing their first security test in under 20 minutes. You can get the full details in our docs, but in short it is as simple as building a yaml config, pointing the scanner at your application, and taking a look at the results.

Sign up for a free account and give it a try today!