www.stackhawk.com Open in urlscan Pro
65.9.66.109  Public Scan

Form analysis
0 forms found in the DOM

Text Content

go to homepage
Why StackHawkProduct
Solutions
DocsPricing
Resources
Sign InCreate Account



WHY DAST SHOULD BE
YOUR FIRST APPLICATION
SECURITY PRIORITY

Rebecca Warren|October 28, 2021

StackHawk is DAST (dynamic application security testing) reimagined for today’s
engineering teams, with features that alert engineers of potential
vulnerabilities on the pull request and enable them to push fixes quickly. 

Whether you are an engineering team looking to roll out application security
testing or a seasoned application security expert looking to improve your test
suite, learn why we love DAST here at StackHawk.



 * Why We ❤️ DAST
 * Where DAST Has Historically Fallen Short
 * How StackHawk Is Different
 * Why Teams Like SAST
 * DAST vs SAST
 * Why Teams Like SCA
 * DAST vs SCA
 * Get Going with DAST



There are three standard tools in a security leader’s arsenal for tackling
application security testing  – Dynamic Application Security Testing (DAST),
Static Application Security Testing (SAST), and Software Composition Analysis
(SCA). 

One of the conversations we come across often here at StackHawk is, “Which tool
should I start with?” This is true for organizations of all sizes  –  from those
just beginning to build out their AppSec program to those working on retooling
their current approach to be more developer friendly. 

While a comprehensive security program will have all three in place, we are big
believers that DAST is the best place to start an application security journey. 

Ready on to see why teams can get the most out of a tool by starting with DAST.


WHY WE ❤️ DAST

Of the three security tooling types available, teams can see the greatest return
on investment by implementing DAST. There are a few reasons for this:

 1. DAST simulates how bad actors access your applications. The types of attacks
    that a DAST scan can find simulate a bad actor attempting to steal or
    manipulate sensitive data, deface a website, or plant malware on the site.
    If you are implementing a tool to protect yourself from external threats,
    DAST is the best option.

 2. DAST tests the running application. Neither SAST nor SCA have the proper
    context of how the application being tested actually works. Because DAST is
    testing the running application with bad inputs to see how it behaves, users
    get more accurate results.

 3. DAST finds vulnerabilities that your team is writing. While testing open
    source libraries is important, 69.1% of companies have more vulnerabilities
    from their own application development vs. the use of open source. This
    means your first consideration when it comes to security testing should be
    the code your team is writing with a tool like DAST, not the libraries you
    are using.


WHERE DAST HAS HISTORICALLY FALLEN SHORT

That being said, DAST has not always been a user-friendly tool. Historically it
came with operational hurdles that made it a tool that frustrated both security
and developers. 

Until recently, DAST had the following struggles:

 1. Difficult to automate. DAST was typically used by penetration testers to run
    manual audits that could take days or weeks. Until recently there have not
    been good options for fitting DAST into the modern development workflow.

 2. Testing the front end in prod. Because DAST was difficult to automate, that
    meant security teams and pen testers were testing the application in
    production. One of the biggest hurdles with this approach is that it only
    tests an app’s front end. 

 3. Coverage for microservices and modern apps. DAST technologies were created
    at a time when application architectures were much simpler. Unfortunately
    that means for today’s teams that are building microservices architectures
    with backing APIs, there is no good way to test these individual components
    for vulnerabilities.

 4. Difficult to take action on findings. Perhaps the most frustrating part of
    DAST is that it only tells teams that certain vulnerabilities exist versus
    pointing to the exact line of code causing the vulnerability. The
    frustration from this issue is compounded by the first two items on this
    list. By the time vulnerabilities are found and shared back with developers,
    it may be weeks or months since they worked on the code that was tested.
    They have moved on and forgotten about that particular portion of the
    application they were working on, and as a result, the fix requires mental
    backtracking. 


HOW STACKHAWK IS DIFFERENT

When we started StackHawk, we were well aware of the typical challenges of DAST.
So we created a DAST tool that was easy to deploy, easy to automate in CI/CD,
provided complete coverage for APIs, and had developer-friendly features that
equipped engineers to fix vulnerabilities immediately.

If you are hesitant to try DAST because you have been burned by other tools
before, give StackHawk a try for free and see what you think. 

But enough about us, let's get back to the other types of tools available.


WHY TEAMS LIKE SAST

If you are trying to find vulnerabilities in the code your team is writing, the
alternative to DAST is SAST. SAST works by analyzing an app’s source code and
looking for vulnerabilities in the code as it is written. 

By analyzing the source code instead of the running app, users are able to get
broad coverage, even if that code is difficult to execute programmatically.
Additionally, a SAST scan can be done relatively quickly because the scanner is
not interacting with a live app instance. 

Perhaps the most loved feature of SAST is that it pinpoints to the exact line of
code causing the vulnerability. 


DAST VS SAST

At StackHawk, we prefer using DAST as the foundation of an application security
program over SAST. We are obviously biased, but we think the quality of results
from a DAST scan are of higher quality and better protect team from
vulnerabilities making it into the wild. 

The benefits of DAST over SAST we see the most are:

 1. DAST is much less prone to false positives. If DAST finds a security bug in
    the application, it almost certainly exists. By producing less false
    positives, security teams can spend less time validating if findings
    actually exist, and developers can get a more focused testing experience.
    
    
    

 2. DAST can handle complex application architectures. SAST has difficulty
    finding vulnerabilities when an app has multiple layers (e.g., proxies,
    middleware) or is composed of microservices. If we were building apps in
    2004, this wouldn’t be a problem. But if your team is building modern apps,
    SAST may not be your best option.
    
    
    

 3. SAST is language dependent. If you are writing an app in C++ or python, this
    is likely not going to be a problem for you. But, if you are writing an app
    in Kotlin, Rust, or any newer language, you are likely going to be short on
    SAST options for your shiny new app.


WHY TEAMS LIKE SCA

Software Composition Analysis, or SCA, is another type of security testing tool
that finds vulnerabilities in open source components that your team is using.

Teams like using SCA because it is quick to run and provides broad coverage. SCA
is also a newer class of tool that is built to enable developers to remediate
vulnerabilities before production. 

Most SCA tools integrate with major CI/CD providers, run a scan at the PR, and
provide a summary of actionable findings to developers if the application
contains any vulnerable dependencies. The tools provide guidance on how to
remediate vulnerabilities (most often by updating the version being used), and
developers can get back to building features. 

If you are working on a new project, it is really simple to update versions of
open source components without breaking changes. For legacy projects, this can
be much trickier, but still worth the effort. 


DAST VS SCA

As we mentioned above, most companies have more vulnerabilities from their own
application development as compared to open source components. This means your
first consideration when it comes to security testing should be the code your
team is writing, not the libraries you are using. 

DAST and SCA are not substitutes for one another. If your team is looking to
prioritize a rollout between tools, our recommendation is DAST first, so that
you can be sure the code your team is writing is secure.

That being said, open source code is pervasive. Almost 99% of audited codebases
contain some amount of open source, and the average percentage of open source in
those code bases has almost doubled — from 36% in 2015 to 70% in 2019. 

Your work is not done after securing your own code base and SCA is a great
follow-up tool to add to your pipeline. 

There are great benefits to using DAST and SCA together. Where DAST can find a
vulnerability in a running application, SCA can help you validate that finding
and pinpoint where it lives in an open source library while providing quick
remediation guidance which is typically a version upgrade. 

You can see an example of that in action in our joint webinar with Snyk. 


GET GOING WITH DAST

Implementing new security tooling in any organization is a big decision. It is
important that you think through what types of vulnerability protection you are
looking for, who will be involved in testing, and how the tool fits into
existing workflows. 

Based on how you answer those questions you can determine if DAST is the best
place to begin, which we strongly believe is the case for most teams. 

Teams that are implementing StackHawk in their pipelines are seeing operational
gains in their security team, protecting their APIs from vulnerabilities, and
reducing risk across their organizations. 

You can set up a StackHawk account and get scanning for free today. Teams are
able to get from account sign-up to a completed scan in CI/CD in 20 minutes. So
give it a go, and feel free to drop us a line if you run into any hurdles.

--------------------------------------------------------------------------------

Rebecca Warren  |  October 28, 2021

MORE STACKHAWK

Add AppSec to Your CircleCI Pipeline With the StackHawk Orb



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



Using StackHawk in GitLab Know Before You Go (Live)

We use first and third party cookies to ensure that we give you the best
experience on our website and in our products. If you continue to use this site
we will assume that you are happy with it and we'll let corporate know.
OKPrivacy policy
Close GDPR Banner

PRODUCT

 * Overview
 * Why StackHawk
 * How it Works
 * What it Tests
 * Pricing
 * Integrations
 * Sign In

RESOURCES

 * Getting Started
 * Docs
 * Config
 * Run Hawkscan
 * Troubleshooting
 * Blog
 * ZAP Fund

COMPANY

 * About
 * Team
 * JobsWe're Hiring
 * Press

GET IN TOUCH

 * Contact Us
 * hello@stackhawk.com
 * StackHawk Inc.
   1624 Market St,Ste 226
   PMB 36969
   Denver, CO 80202
 * Follow
 * Visit Stackhawk's Twitter AccountVisit Stackhawk's Linkedin Company
   ProfileVisit Stackhawk's Facebook AccountVisit Stackhawk's Github Account

--------------------------------------------------------------------------------

©2021 StackHawk Inc., All Rights Reserved | Terms | Privacy

Crafted in Colorado

Learn how to automate security testing in CI/CD with StackHawk + GitHub Actions
Watch the Video