[Part 2] DevSecOps nAST

8 min readOct 23, 2023

Welcome to the 2th DevSecOps article (previous articles: https://medium.com/@lahutsin/part-0-devsecops-introduction-412e3aa019a6, https://medium.com/@lahutsin/part-1-devsecops-analytics-41c560004da3) (0–7 — spoiler). Today we will talk to you about application security testing processes, what types are used in DevSecOps, and talk a little about each of them. Let’s discuss the differences in testing techniques and, most importantly, the strict differences between all four AST methods. I hope you will be satisfied with getting some knowledge in this specialization, and continue to develop this area in the future. This series of articles assumes a basic understanding and knowledge of DevOps. As an author, I do not claim to have a final or conclusive expert opinion in this area.

SAST (Static Application Security Testing)

Static Application Security Testing (SAST) is a method of security testing that analyzes source code to identify vulnerabilities. SAST tools scan source code and find vulnerabilities without the need to execute the application. These tools detect a variety of vulnerabilities, such as SQL injection, XSS, and others.

The advantage of SAST is that it can detect vulnerabilities early in the development process, allowing developers to quickly fix security issues before they become more complex and expensive to fix later in the development process. However, it is important to note that SAST cannot detect some types of vulnerabilities that can only be manifested during application execution. Therefore, SAST should be complemented by other security testing methods, such as dynamic application security testing (DAST) and interactive application security testing (IAST), to achieve maximum effectiveness in application security.

Please pay attention to the SAST diagram. As mentioned in previous articles, the prioritization of existing issues is configured with the input of development team leaders and depends on the programming language and technology stack. I think you have probably encountered static code analysis in your projects, so now you understand the full depth of this analysis, given the previous article on vulnerability analysis.

OAST (Open Application Security Testing)

OAST stands for Open Application Security Testing, which can be translated as “Open Application Security Testing”. It is an approach to application security testing that is part of the overall development and testing cycle (SDLC) and provides early detection of application vulnerabilities, allowing developers and security teams to take action to address these issues before the application goes into production.

OAST includes automated vulnerability scanning of the application using a variety of security testing tools, such as vulnerability scanners, code analysis tools, and others. In addition, OAST also includes manual testing, which can include traffic interception, vulnerability research, and so on.

Overall, OAST is a comprehensive approach to application security testing that allows you to identify and fix vulnerabilities in the application at the early stages of development, which helps improve the overall security of the application.

I will remind you that SDLC stands for “Software Development Life Cycle”. SDLC is a methodology or process used in the creation of software.
OAST is mostly paid products and are the most expensive on the market among other types of testing or scanning, as it is one of the most complex mechanisms for testing applications, which requires significant investment funds for research and of course compliance with a variety of security standards.
As you can see from the slide, the diagram is very simple, but in reality, these tested requests hide an infinite amount of research on a particular application.
Usually, in free OAST tools, these tests are written by automation testers, when our task is to provide them with tools for this field of activity.

OAST in CI workflow:

OAST tool integration: Select and integrate the appropriate OAST tools into the CI environment. These could be vulnerability scanners, code analysis tools, or other tools that can perform dynamic application security testing.
Test case development: Developers create test cases that cover different aspects of the application’s security. This could include input validation, authentication, authorization, error handling, and other security aspects.
Automated testing: OAST testing is automatically executed at each stage of the CI pipeline after code changes are made. This can be done using automated vulnerability scanning tools or other tools that interact with the running application.
Results analysis: The results of OAST testing are analyzed to identify and assess the vulnerabilities found. This could involve generating warnings, errors, or security reports.
Integration with bug tracking system: Vulnerabilities found can be automatically submitted to a bug tracking system (such as Jira or another similar system) so that developers can review and fix the vulnerabilities as part of their workflow.

On the scheme, you can see the approximate location of these utilities. But as you can see, in addition to the standard environments, there is a so-called isolated environment.
This environment is an isolated environment from everyone. In other words, this environment is only available to the pipeline. This is done so that this environment during OAST testing plays the role of an independent arbiter for a particular problem, a means of running new test scripts, and much more until the finished artifact is delivered to the next endpoint or repository.
The mechanism is simple, first after successful static scanning, the code goes directly to the isolated environment for the subsequent OAST mechanism.
Since developers often have the ability to locally test the problem, the meaning or even the essence of this environment is to punish those who try to inject defective code automatically into the next delivery cycles of software without running script tests locally.
We would like to note that OAST technologies have a limited selection of tools, and for a more complete understanding of the functionality and capabilities of OAST, it is recommended to turn to commercial solutions and contact specialized security providers.

DAST (Dynamic Application Security Testing)

DAST (Dynamic Application Security Testing) is a method of application security testing that is performed at runtime (in real-time) and uses input data to check for vulnerabilities.

DAST can be used in DevSecOps to detect vulnerabilities in applications that can be exploited by attackers. It can detect vulnerabilities such as authentication flaws, SQL injection, and cross-site scripting vulnerabilities.

DAST can be integrated into the continuous integration and delivery (CI/CD) process for automated application security testing as part of the pipeline. This helps to improve the quality and security of applications, reduce risks, and accelerate the development and delivery process.

DAST works on a “black box” approach, where the tester does not have access to the source code or internal components of the application. Instead, DAST interacts with the application as a regular user, sending requests and analyzing the responses to detect potential vulnerabilities.
OAST works on a “white box” approach, where testing is performed based on the logic of the application’s code and full traffic monitoring.
Therefore, in the “black box” method, we focus on obvious problems. Sending requests virtually blindly, when in the “white box” method we know the code and can fully track the traffic and analyze it for potential problems.
In the end, we use the “white box” method first to reduce the number of obvious problems at the production stage and test using the “black box” method, which is in line with the DevSecOps philosophy.

IAST (Interactive Application Security Testing)

IAST (Interactive Application Security Testing) is a method of application security testing that uses real-time code analysis to detect vulnerabilities in applications.

When using IAST, code analyzers run inside the application during its execution, so IAST can detect vulnerabilities that cannot be detected by other security testing methods. IAST can also provide accurate information about the location of vulnerabilities and how they can be exploited.

IAST can be integrated into the continuous integration and delivery (CI/CD) process for automated application security testing as part of the pipeline. This allows vulnerabilities to be detected and fixed early in the application’s lifecycle and significantly improves the security and quality of applications.

It is worth noting that there are active and passive IAST.
Active IAST involves the injection of agents or libraries into the application to monitor its execution in real time. Agents collect information about code execution, including security data, and transmit it to a security analysis tool. This allows vulnerabilities to be detected at the code execution stage, as well as to provide contextual information about the problem, such as call stack, function parameters, and more.
Passive IAST, on the other hand, does not make any changes to the application. It operates in “observer” mode and analyzes traffic between the client and server. Passive IAST analyzes requests and responses, looking for potential vulnerabilities based on known attacks and security settings. It can detect vulnerabilities such as information leakage, lack of encryption, insufficient authentication validation, and other problems related to traffic processing.
I personally prefer the active testing method, including in production environments, because it helps to tightly control any deviations from the application’s operation without bothering with any anomaly tests or writing and managing them.

A few words….

Eventually. SAST is a simple static code scanner and code quality analyzer. DAST — testing an application blindly based on queries and analysis of input and output data. OAST — open application testing, based on code and full traffic analysis. IAST — internal testing of the application — for example, checking the privacy coverage of the API by running the application during the pipeline, IAST can also be built into applications which will increase the verification of the code base as sensors and the results are displayed in any dashboard for this. IAST is very similar to the analogy of real-time tracing, but in the context of security, and here you yourself choose to damage sensors, launch applications, and, at the expense of DAST, simultaneously check and IAST many tricks and solutions.

As you may have already noticed, different manufacturers or vendors provide access to their software differently and therefore it is not possible to track changes in the usage pattern. In some cases, we have to deploy the application initially in order to test it and move on, but this must be taken into account and the pipeline that looks ideal in the picture may look much different in real life.
The main thing is to select the necessary and important utilities according to the interests of the project, the technology stack, and the adequacy of the customer.
For example, if a backend and frontend are written on a project using different technologies, then it is better to use different utilities tailored to the needs of a particular technology as closely as possible, this will help closely monitor the quality of software delivery.