It’s no secret that waiting until late in the software development lifecycle to find and fix bugs is really expensive. Regardless of the nature of the issue — security, functional, UI, or anything in between — it’s exponentially more costly to fix these things when you get to production or post-release than early in the development process.

The “shift left” movement — where testing is done as early as possible in the SDLC — has gained in popularity as a strategy to improve security and efficiency, and reduce expenses. By conducting extensive unit, integration, and security testing early, your cost of finding and fixing bugs is about three times less than if you only find and fix them after you release.

What’s more, the rise of automated testing tools has given development teams plenty of ways to shift left. In addition to writing and running unit, functional, and/or integration tests, a new breed of tools like software composition analysis (SCA) and dynamic application security testing (DAST) now enable teams to catch more bugs, more quickly.

In this blog, we'll explore why relying solely on more traditional testing methods like unit, functional, and integration may not provide a complete picture of what's going in your code, and we'll discuss how SCA and DAST can help fill in that gap. We’ll also demonstrate how to run SCA/DAST in the GitHub Actions CI. And for more information on SCA, DAST, and using these tools in GitHub Actions, check out our recent webinar: Automating Application Security Testing with Github Actions.

RELATED: How to Defend Against Software Supply Chain Attacks

Limitations of Traditional Testing

More traditional methods like unit, functional, and/or integration tests — and having tests fail before committing code — is a cheap way to ensure you're putting out high-quality code quickly. But there’s a downside to relying solely on that type of testing: You risk missing bugs that aren’t covered in your test cases.

Specifically, it’s really hard to write what one might call a negative test case. We write positive test cases — i.e. the application should do this, and here’s the test. It’s really hard to get good coverage on negative test cases — i.e. the application shouldn’t do this.

That’s exactly why there’s a need for tools like SCA and DAST. We’ll go into more detail later in this blog, but, in short, they help you reliably find security issues without writing those exhaustive tests for applications. Instead, they enable you to test automatically as you’re building and deploying software, producing comprehensive and accurate results in the process.

Another, often overlooked concern with traditional testing is its inability to provide strong visibility into third-party code. Developers today generally include numerous open source libraries in their builds, but it’s dangerous to assume those packages are vulnerability-free. And, traditional tests often don’t look for licensing or security issues within third-party components.

Benefits of Using Automated AppSec Tools

When we write functional tests and unit tests, we’re covering the code that we write. We’re hoping that people have covered their open source libraries in a similar fashion, but there’s no guarantee that’s the case.

The solution to that problem — as well as the challenge of reliably finding security issues without writing exhaustive tests for your application — is to embrace automation in the form of security tools built for developers like SCA and DAST.

What distinguishes these tools is that they can help inform developers about mistakes they may be introducing or making as they’re building apps. This stands in contrast to the traditional method of “I built the thing, now I need to let the security team find all the problems.” Or, worse, the scenario in which bug bounty programs find problems, or even worse, threat actors find the problems and take action upon them.

Security tools built for developers scale more efficiently because they put tests and results directly in the hands of people that fix these issues, resulting in less back and forth of tickets with a security team. (As you might have experienced, the back and forth of ticketing can be extremely inefficient and result in issues with prioritization.)

SCA and DAST: A Closer Look

A number of application security testing tools have gained popularity in recent years. They include static application security testing (SAST), dynamic application security testing (DAST), software composition analysis (SCA), interactive application security testing (IAST), and run-time application security protection (RASP), among others.

Here, we’ll focus on two types of appsec testing tools: DAST and SCA.

Dynamic Application Security Testing (DAST)

As the name implies, DAST tests for defects in a running application. It does this by (safely) injecting malicious inputs to identify potential security vulnerabilities  within the application. A DAST tool will make HTTP requests and uncover issues like SQL injections, OS injections, and cross-site scripting errors. It also finds bugs that are important to application security context, like security headers, cookie safety, content security policies, and X-Frame-Options.

There are a few key capabilities that make DAST tools particularly useful:

  • There’s no language dependency because DAST tests the running app, however you compile it
  • DAST takes into account context of how the application works: It tests the running application with bad inputs to see how the application behaves
  • DAST produces a lower rate of false positives: If it finds a security bug in an application, it’s almost certain that bug exists

Security teams often use DAST tools alongside SAST tools, which analyze proprietary source code elements and identify dependencies within that code

Software Composition Analysis (SCA)

In contrast to SAST, which is designed to scan proprietary code, SCA tools analyze open source components. (Given the fact that over 90% of modern applications are built with at least some open source, it’s easy to see why SCA has become a vital part of many security programs.)

You can more or less group the functions of SCA testing into three buckets: identification, policy, and remediation.

  1. Identification: SCA starts with looking at your open source code components and going through your dependencies. And it doesn’t just look at the dependencies that are directly in your file, but also the dependencies of your dependencies, and the dependencies of those dependencies, and so on. SCA tools go all the way down to what we call the deep dependencies to create a dependency graph or tree. The SCA tool will then cross-reference that data with both an OSS license database and a vulnerability database. This all comes together to build an exhaustive and noise-free compliance and vulnerability inventory.
  2. Policy: Different organizations have different priorities when it comes to open source vulnerability management. For example, what matters for a healthcare organization might not be as important to a phone manufacturer. SCA enables companies to build customizable policies that determine how to prioritize, and whether to filter or approve/deny specific vulnerabilities and licenses to create an appropriate risk profile.
  3. Developer-friendly remediation: The ultimate goal of SCA tools is to enable teams to address security (and license compliance) issues in third-party components as quickly as possible. Top-tier SCA tools not only integrate directly into developers’ workflows, but they also provide guidance on how to best upgrade the vulnerable component.

Running SCA and DAST in GitHub Actions

Organizations can run SCA and DAST testing in any number of CI/CD tools (Jenkins, CircleCI, GitLab, and many more). In this blog, we’ll demonstrate how to use a popular SCA tool (FOSSA) and a popular DAST tool (StackHawk) in the GitHub Actions CI.

Running FOSSA SCA in GitHub Actions

Step 1: Generate an API key in FOSSA: https://app.fossa.com/account/settings/integrations/api_tokens

Step 2: Add your FOSSA API key to your repo. This can be done under Settings -> Secrets -> New repository secret. In this example, we call our secret "fossaApiKey"

Step 3: Add the following to your existing github workflow, or create a new GitHub workflow under .github/workflow/fossa.yml and add these jobs

jobs:
  fossa-scan:
    runs-on: ubuntu-latest
    steps:
      - name: "Checkout Code"
        uses: actions/checkout@v2

      - name: "Run FOSSA Scan"
        uses: fossas/fossa-action@v1
        with:
          api-key: ${{secrets.fossaApiKey}}

      - name: "Run FOSSA Test"
        uses: fossas/fossa-action@v1
        with:
          api-key: ${{secrets.fossaApiKey}}
          run-tests: true

Running StackHawk DAST in GitHub Actions

Step 1: Generate an API key in StackHawk:

https://app.stackhawk.com/settings/apikeys

Step 2: Configure your Application in StackHawk and add the stackhawk.yml file to your code repo:

https://app.stackhawk.com/applications

Step 3: Add your StackHawk API key to your repo. This can be done under Settings -> Secrets -> New repository secret. In this example, we call our secret "HAWK_API_KEY"

Step 4: Add the following to your existing GitHub workflow, or create a new workflow under .github/workflow/stackhawk.yml

  hawkscan:
    name: StackHawk DAST
    runs-on: ubuntu-latest
    steps:
      - name: Clone repo
        uses: actions/checkout@v2
      - name: Run the Vuln Django Containers
        run: docker-compose up -d
      - name: Run HawkScan
        uses: stackhawk/hawkscan-action@v1.2.1
        with:
          apiKey: ${{ secrets.HAWK_API_KEY }}
          configurationFiles: stackhawk.yml

More Resources: DAST and SCA in GitHub Actions

Check out these helpful links for more information on running DAST and/or SCA in GitHub Actions.

Webinar: Automating Application Security Testing with Github Actions

Step-by-Step Directions: Using FOSSA SCA in GitHub Actions

Step-By-Step Directions: Using StackHawk DAST in GitHub Actions

About the Authors

Solomon Rubin is a Senior Security Product And Software Engineer with a history of working in Government and Software Security roles. He spent several years working on high-profile projects at the MITRE Corporation in DC, leading open source initiatives in the US government. Now, he leads a security and vulnerability product team at FOSSA.

Scott Gerlach is StackHawk's co-founder and CSO. He has 20-plus years of experience in information security, including security processes, procedures, policies, and compliance. He has strong expertise in identifying security gaps and working with companies to develop safe and effective policies and procedures to mitigate those risks.