DEV Community: Ryan Severns

StackHawk’s Free Developer Plan: Application Security Testing for All

Ryan Severns — Tue, 08 Dec 2020 13:57:41 +0000

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.

Announcing GraphQL Application Security Testing

Ryan Severns — Wed, 10 Jun 2020 21:17:52 +0000

In 5 short years, GraphQL has solidified its footprint as the API backing of many applications, and it shows no sign of slowing. More and more companies are choosing GraphQL for its simplicity, ability to fetch the right amount of data, and the way it can traverse a graph of relational data.

Securing GraphQL applications, however, has been a challenge. Sure, there are common best practices and rules in place. But reliance on training or the rudimentary automated checks that currently exist only gets you so far. Eventually security bugs will be deployed and your app will be at risk.

…until now.

GraphQL Security from StackHawk

We’re excited to announce that HawkScan, StackHawk’s scanning engine, now supports GraphQL applications. StackHawk is the only product on the market that can scan a running GraphQL application, simulating an attack by fuzzing the various query parameters, and surfacing potential security bugs to engineering teams.

With StackHawk, teams using GraphQL for their API layer can now confidently catch potential vulnerabilities before security bugs hit production. With CI/CD automation, you can ensure that potential bugs are caught early in the development lifecycle and fixed by the developers who have the context and expertise of the code base they just merged to.

How it Works

StackHawk is a dynamic application security testing tool. That means it runs security testing against your running application, whether that be on your local machine, in CI environments, or against your application in production.

GraphQL testing is done by exposing the introspection endpoint to the scanner via the StackHawk.yml file. The scanner runs introspection and identifies all of the potential query and mutation operations of the endpoint, and then gets to work finding potential security bugs. As a dynamic security test, the scanner sends requests to all endpoints, effectively fuzzing the whole GraphQL tree, simulating the ways the application could be attacked. The scanner logs all tested endpoints and any security bugs found, with the associated request and response payload. From there, developers can triage bugs, fixing high priority issues and using Findings Management to quiet noise for accepted risk or assigned items. Then, GraphQL scanning can be automated in the pipeline to ensure that no build hits production with unaccepted security risk.

Getting Started

Getting started with GraphQL security in StackHawk is incredibly easy, simply requiring the addition of the schema path to the stackhawk.yml file.

App:
  ...
  graphQL: true
  graphQLSchemaPath: /graphql

Visit our docs for more information on configuration for GraphQL, as well as other configuration options such as authenticated scanning. As always, our team is available to assist as you begin using StackHawk. Reach out to support@stackhawk.com and we will be happy to help.

Application Security is Broken. Here is How We Intend to Fix It.

Ryan Severns — Wed, 20 May 2020 20:54:58 +0000

Application security as we know it today is broken.

You commit your code and push features into production, only to get a high priority Jira ticket from security months later with little context. At this point, a security bug has been in production for months and you are pulled into an inefficient fix process.

There is a better way.

tl;dr

Modern AppSec is Broken. Agile, Cloud, DevOps, CI/CD, and open source have changed everything for engineers, but security processes struggle to keep up.
AppSec’s Future is in Engineering Teams. Traditional IT Operations was replaced by DevOps; shouldn’t engineering own the security of the code they write?
A New Breed of Security Tools are Coming. We are part of a small but powerful group of security tools that are built for the developers who do the actual fixing of security bugs.

Application Security is Broken

Applications are being pushed into the world faster than ever before. Cloud deployments, DevOps teams, and CI/CD have enabled engineering teams to produce high quality software with incredible efficiency. As these applications are pushed to production, often multiple times per week or day, the current security model can’t keep up.

Below are some of the ways that AppSec is no longer working for modern software teams:

Doesn’t Match Modern Workflows. Development has shifted to continuous delivery, with endless tools to support you in your work. You deploy software quickly and count on test suites to catch bugs. Your application security tools, however, are built for a waterfall era and exist in isolation from the rest of your workflow.
Not Built for Automation. Security bug testing should be automated throughout the delivery pipeline, starting as close to local dev as possible. Solutions that center on testing once an app hits production just don’t cut it in this day and age.
Finding > Fixing. Existing application security tools (and, in some cases, teams) engage in a contest of finding the most things and you get an ever increasing backlog. Fixing easily exploitable, easily fixed bugs should be prioritized over finding the most obscure vulnerability.
Built for InfoSec. It only takes a few minutes on the RSA trade show floor to know that the security products of old are built for the suit-wearing Fortune 500 CISOs. Built for Developers is a marketing tagline, not a product reality. Jump into any of the market leading security tools and it is quickly apparent that they are not, in fact, built for developers.
Training > Tooling. Security teams invest time and effort training developers on how to write secure code. While a noble pursuit, the reality is that you are pushed toward feature delivery and don’t retain enough of their secure coding workshops. Good tooling will always win out over another training day.

Engineers Will Own the AppSec of the Future

The tide is beginning to shift, with engineers taking hold of the security of their applications. Modern engineering teams know that to ship secure apps, they need to own it themselves. We are in the early days of that shift, with a day soon on the horizon where inefficient InfoSec models for application security will become a relic of the past.

As we talk to the developers who are on the cutting edge of this shift, we are seeing the following trends:

Finding Security Bugs is Shifting Left. As with any bug, it is best to find and fix earlier in the development process. Finding a bug in local dev and hammering away on a quick fix is easy. When a bug breaks a build or is found in production, that is a different story. The best engineering teams are adding application security checks at commit and merge and equipping their developers with the tools to troubleshoot quickly when a bug is found.
Triage and Fix Lives with Those Best Equipped. If you wrote the code, you are typically the best equipped to make a call on the security risk of a particular bug and to instrument a fix. Even better is when the fix is so simple that it erases the cognitive load of defining the risk, but the bug can be found and fixed while still in local dev.
Fixing While in Context Drives Speed. No more getting alerted on security bugs for code you wrote months ago. Fixing a bug while you have the context of the part of the code base you are working on drives simplicity and efficiency.
Security == Quality, and Engineering knows Quality. Your engineering team knows how to ship high quality applications with speed and efficiency. In the same way that teams would not push UI bugs into production, security bugs can be fixed before the latest release goes live. Secure code is quality code.

The New Breed of Security Tooling

The application security shift has already begun. There has been incredible progress on what makes a best-in-class engineering program over the past two decades. Engineers own the end to end building, delivery, operation, and quality of their applications, and the time has arrived for you to own the security as well.

This shift, however, requires a new breed of security tooling. The tools that aim to serve the CISO first, to the detriment of engineers, will no longer cut it. The products that carry outrageous price tags but have not kept up with the shift in how software is created and delivered will have to be phased out. Here at StackHawk, we say, “This is not security for security people.” As long as application security tools are built for InfoSec teams, they will lack the features that are needed to truly serve you, the modern software engineer.

We created StackHawk to simplify the process of building and delivering secure code. We are dead set on creating the best security focused dev tool out there, ensuring that the same people who write the code are equipped to ensure it is secure. We are excited about what we have built already and we are just getting started.