Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Continuous testing tools and approaches: Boost your app sec the easy way

public://pictures/omer-levi-hevroni.jpg
Omer Levi Hevron AppSec Engineer, Snyk
 

"What you don’t know can't hurt you."

There are situations when that sentence is true, but when talking about application security, what you don’t know will hurt you. But how can you know what you don’t know? How can you find security issues before hackers will?

One answer is through application security testing, and tools are key. But it's not enough to run a security tool. You need to run it in a continuous integration/continuous deployment (CI/CD) pipeline, and the tool must break the build if it finds something. These tools work on containerized applications running on Kubernetes, but almost all of the tools and tests are generic and relevant to other kinds of applications.

Here is a look at the kinds of testing and tools you should use to find all those unknowns. Free and open source, they are tools you can start using today. 

Break the build or it didn't happen

Running security tests in the CI/CD pipeline improves the security of your code because:

  • The tests run continuously, each time the code changes. These tests make sure the code stays secure.
  • Faster feedback. The developer receives immediate feedback about the quality of her commit.

(Which is why you will run any kind of tests in the CI/CD pipeline.)

But running security tests in the CI/CD pipeline is not enough. You must break the build if your tests find any issue. Without breaking the build, the developer has no way to find out about the issue. So, if you’re running a security tool, and that tool does not fail the build (or blocking from publishing new code into production), it’s as if you didn’t run it at all.

A typical reaction to a broken build

It's all about ownership

Running tests on the CI means that the developers are the only owners of those tests. They will review the issues and decide what to fix and what to ignore—and usually they will consult with the security team. But they must own those tests for two reasons:

  • Capacity. When you start to automate security, you will have many reports from various tools, and there aren’t enough security people to review all of them. You have to let go and trust the developers to do their job.
  • Ownership. This is critical for developers to be proactive and fix issues the tool found. If only the security team can review the reports and decides how to handle them, the developer team does not own the tests.

Testing the code: Static analysis

When talking about containerized applications, you have three levels of code that you need to scan:

  1. Code scan. Look for various security issues, from hard-coded credentials to insecure deserialization or broken authentication. To scan the code, you need to find the best tools for the language you're using. Here you can find a list of static analyzers for many languages, some of them also looking for potential security issues.
  2. Dependencies scan: Almost all programming languages use package managers (NuGet, NPM, PyPi, Gem, etc.). You need to scan all the dependencies that are used by your software, and look for dependencies with known vulnerabilities (OWASP A9). For that, you can use OWASP Dependency Track. Check out the Jenkins plugin to see all the supported languages.
  3. Docker image scan: The image you're using has a lot of software installed (besides the app) and those could also contain security issues. Also, the engine that runs the app (for example, NodeJS) might be vulnerable too, so this is another thing to scan. You can use open-source tools such as Clair and Anchore, but in my experience they find too many issues, making it hard to determine what's relevant and what's not.

Testing the app: Dynamic analysis

Aside from scanning your code, you also want to test your live app. You can do this in two ways:

  • Proxy the requests and response from the app, and look for security issues.
  • Send malicious requests to the app and test the response to make sure the app is not vulnerable to those attacks.

The advantage of this kind of test is that it’s language-agnostic—you're testing how the app behaves, not how it was written.

This test might sound complicated, but it's easily done by using OWASP Zap. And since the app is already containerized, it is easy to perform this test. Here's how this could be done easily with a high-level approach. For a hands-on walkthrough, check out this repo, which will guide you through the process.

Now make sure that only applications that passed all those tests will be deployed into the cluster. This can be done at the CI level, or by using Image Policy Webhook to allow specific images.

How to handle false positives

Handling false positive is hard, and sometimes painful. If you have worked with any security tool, you've probably noticed that it had some false-positive findings (and false negatives, which are a lot harder to find—but also more dangerous).

When running those tools on the CI, you must have a way to ignore those false positives. You can use OWASP Glue for that—a tool that aims to ease the integration of security tools into the CI/CD pipeline. It has built-in capabilities for filtering findings (for example, filtering false-positive results), and for reporting (for example, TeamCity reporter, which reports each finding as a failed test), and popular tools. And because it's open source, it's simple to add new integrations based on your needs.

Continuous improvement is key

Finding all those unknowns is a process, one of continuous improvement. These tools allow you and your team to get started today. Which of these tests you are going to use?

Share your ideas in the comments below. Your feedback will help me and others to become better.

Join me at DevSecCon Tel Aviv on May 7, 2018 for my talk, Secure the pipeline: How we’ve built a secure Kubernetes CI/CD pipeline.

Keep learning

Read more articles about: SecurityApplication Security