DevSecOps – How to Add Security Testing to your Delivery Pipeline

In 2018, nearly 76% of organizations experienced a cyber-attack or data breach due to a compromised application. The speed with which software today is developed means that security defects in the code are a fact.
Traditional security tests carried out by external security teams at the end of development don’t work to protect against attack. By the time the bug is found, the development team is already working on the next iteration.
To provide fast feedback from a security point of view, security tests must be treated the same as functional tests. Application Security Testing tools should be integrated into the SDLC, to support development teams with Continuous Security Testing.
DevSecOps takes up the idea of DevOps and adds the missing component, security.

Are you new to DevSecOps or want to improve your security? Combine the following security tests, technologies and methods to successfully integrate security testing into your SDLC.

Application Security Technologies & Methods

SAST – Static Application Security Testing

Most security vulnerabilities sneak in during the coding of the system. However, they are also easiest to find and fix if there are good code reviews and other good development practices. Static Application Security Testing (SAST) is used to parse the source code of the application, bytecode, and binaries without executing the application. With SAST, the system under test will be checked from the “inside.” A good way to improve security in your coding is to study OWASP’s Secure Software Development Lifecycle Project. This guideline for developers offers security best practices.

DAST – Dynamic Application Security Testing

Dynamic Application Security Testing (DAST), can identify security vulnerabilities in a running application, typically web applications and mobile applications. Often referred to as black box testing, DAST checks the running application from the outside by trying to find security flaws and using them for an attack. DAST tries to detect patterns that indicate a security vulnerability in a running application. When running DAST for a mobile application, consider an additional aspect for vulnerabilities: the aspect related to the device on which the mobile app is executed.  We have to test the underlying platform like iOS & Android, as well as the interaction with device-specific functions such as Camera, Bluetooth, GPS and other things.

RASP – Analyze & Self-defense at Runtime

Runtime Application Self-Protection (RASP) is integrated with the application under test to detect and prevent real-time attacks. The application is instrumented by a runtime agent to subsequently control and monitor the execution. RASP is used when the application is executed (at runtime), which causes the program to self-monitor and detect malicious inputs and behaviors. RASP analyzes the behavior of the application and the context of the behavior. Thus, continuous security analysis is implemented with the system reacting immediately to detected attacks. If certain safety conditions are met, RASP gains control of the application and takes the necessary protective measures.

IAST – Interactive Application Security Testing

IAST is a combination of dynamic application security testing (DAST) and runtime application self-protection (RASP). The IAST approach analyzes application behavior in the test phase using the RASP runtime agent and DAST as the attack inductor. The agent, which is integrated with the application’s runtime engine (for example, JVM), has insight into the application’s logic flow, data flow, and configuration, monitors the test attacks triggered by the DAST attack, and then reports possible weak points.

SCA – Software Composition Analysis

In order to fully understand the vulnerabilities and the general security of applications, detailed insights into the external libraries and used software components are necessary. Software Composition Analysis (SCA) enables the identification of third party and open source components that have been integrated into the application. SCA checks if open source frameworks have open vulnerabilities (CVE) and newer versions are available. SCA tools identify which open source components a company uses in its source code. Then they align those components with community databases, advisories, and issue trackers to detect code vulnerabilities. Finally, an inventory report of all open source components involved in the application, including all direct and transitive dependencies, are created.

With DevSecOps it is possible to test security again and again early within the development process and enable “fast feedback.”

Functional Security Tests

These are regression tests aimed to verify functional security features such as Login, Logout, Password Policy and Credentials Management. Most of these regression tests can be automated with tools such as Selenium for Web or Appium for Mobile Apps. If you decide to use a tool for test management, you’ll have native support to setup testing automation with XRAY.

Non-Functional Security Tests

These types of tests are better known as Penetration Tests, and test the application and the runtime environment by scanning for known vulnerabilities (e.g. SQL-Injections) and misconfigurations (e.g. use of known SSL suites). According to Gartner, “Through 2020, 80% of cloud breaches will be due to customer misconfiguration, mismanaged credentials or insider theft.” These tests are the perfect candidates for automation, as the vulnerabilities are known in advance. To test them, a hybrid approach comes into the game: automation along with a proxy server to validate, enter, and modify HTTP requests and HTTP responses.

Runtime Environment

Here, the infrastructure and runtime environment of the application is scanned for vulnerabilities. It examines specific IP addresses and all exposed ports for known vulnerabilities. This includes dependencies on open source tools and possible vulnerabilities in their components.  

How Continuous Testing looks in the Delivery Pipeline

Together, these technologies provide an integrated strategy for detecting and protecting security vulnerabilities. This is what Continuous Delivery Testing could look like in a Continuous Delivery Pipeline:

Local Dev Stage

During development, thread modelling will be used to analyze possible vulnerabilities and attack scenarios. The insights will be incorporated into the development of the application itself. Additional functional security tests, and adjustments will be used to setup DAST. First SAST checks are made via IDE to the local repository.

Integration Stage

Here, the code from the global repository is subjected to a limited SAST check and a SCA is used to check for known vulnerabilities. For quick feedback, this check only files that have changed since the last commit. In addition, limited functional security checks are performed that test only the features affected by the code changes.

Acceptance Stage

In this phase of the pipeline, a comprehensive SAST check is now conducted with the entire security policy. In addition, Fuzzing is used to detect security vulnerabilities that could be a problem due to a lack of robustness of the application. Then the application is tested for OWASP‘s Top 10 vulnerabilities via DAST and the remaining functional security checks are performed. Finally, there are limited compliance tests of the runtime environment.

Pre-Prod Stage

Here, IAST analyzes application behavior using DAST as an attack indicator to determine if the application is vulnerable. Then, correct countermeasures are started via RASP. Soon after, the application will undergo a final endurance test with all functional security checks. The runtime environment will also undergo a complete compliance test (security).

Production Stage

The runtime environment is subjected to a full compliance test (security) to finally protect the application against production-phase attacks with RASP.

Together, these methods and tests can build a robust and automated security strategy integrated into your SDLC.

If implemented correctly, DevOps enables today’s companies to bring their products faster to market. This creates an advantage over competitors who still develop software according to a classic SDLC.
However, successful implementation of DevOps is only possible through consequent test automation. The problem is that security tests are still semi-automated or manually carried out by security experts who join at the end of the project and check the security features with manually executed penetration tests.
With this approach, DevOps fails since it is meant to avoid the manual security testing phase at the end.

DevOps consistently implemented means that security tests must be carried out fully automated in the continuous delivery pipeline. They must also be included in the development activity in the form of static analysis of security vulnerabilities.

---

With Xray, you can easily adopt DevSecOps and implement Continuous Security Testing. Xray has extensive support for automated tests, no matter the framework or tool you use to implement them. Thus, you can track all security related testing and see their impact on related issues, in real time.
Besides this, it is flexible and adaptable to your process and workflow. Even better, Xray is integrated into Jira, the leading issue and project tracking software. Because of this, it fosters collaboration between all team members, including developers, testers and the missing component, security.

Try Xray for yourself and see how you can optimize security in your software.

---

Author Bio

Rudolf Groetz has been in IT for 30 years. He’s been working as a passionate software tester since 2017 for Raiffeisen Bank International in Vienna as chapter lead software testing in the Group Digital Solutions program.

He is the organizer of the Agile Test Automation Meetup Vienna (aka TestBusters Night Vienna) The opinions in this article are the opinions of the author and do not necessarily reflect the opinion of Raiffeisen Bank International.