Agile security scans are essential to meet the required IT protection goals in modern development environments. Many project managers often have to deal with strict deadlines and the testing of complex applications. A large part of these checks can be mapped by automated tests and embedded directly into software release management. This process is integrated directly into the CI/CD pipeline to ensure more secure release cycles. The most important factor in developing an automated AST (Application Security Testing) solution is the need to support agility initiatives. This article will shed light on automated techniques at AST and present our view and recommendations.
The common AST security process in DevOps or NoOps environments is described in the following diagram. The security consultant initially implements the security process in the CI/CD pipeline, after which he is only active as a consultant. He supports the developers with tooling and with complex incidents.
SAST analyses the source code, byte code or binary code of an application for security vulnerabilities, typically in the programming and/or testing phase of the software lifecycle (SLC). This methodology can also only test program parts, so the applications do not have to be executable or completely tested in the test case. Therefore, SAST does not understand any execution context and does not know the state of a variable, which is why not all vulnerabilities from the OWASP Top Ten can be investigated. However, this offers the advantage that the process can be used early in the Software Development Life Cycle (SDLC). The testing of external libraries can also be problematic, since they often do not exist in the desired form and can be obfuscated.
DAST analyzes applications in their dynamic and running state during the test or operation phase. It simulates attacks on an application, analyzes the reactions of the application and thus determines whether it is vulnerable. This type of verification fully covers the OWASP Top Ten and works well against common frameworks such as Wordpress, Joomla or Drupal. Also the server-side languages are covered and found vulnerabilities are easier to check for false positives. However, more manual configuration is needed because authentication and an executable application have to be created.
IAST combines elements of SAST and DAST simultaneously. It is typically implemented as an agent within the test runtime environment that monitors operations or attacks and identifies vulnerabilities. In this way, the dynamic test can be made much more "intelligent". IAST cannot analyze how all parts of an application interact and work at runtime, so vulnerabilities in the running applications can be detected that could be exploited by attackers.
In this methodology, an IAST agent is implemented in the software, which automatically tests the software at runtime and reports weak points to the IAST Management Server. A WAF (Web Application Firewall) works according to the same scheme.
With Active IAST, the quality of DAST scanners is increased because the requests that are present in the backend can be better analyzed.
However, the central problems of DAST scanners are not solved. However, the DAST results then provide code-level guidance on where software vulnerabilities are located, making it easier for developers to fix identified vulnerabilities.
An IAST implementation does not cover Broken Authentication, Broken Access Control and Insufficient Logging & Monitoring from the OWASP Top Ten.
Gartner expects the AST market to grow at an average annual growth rate (CAGR) of 10% through 2022. This remains a fast growing segment in the information security market, which is expected to grow with a five-year CAGR of 9%. The AST market volume is estimated at $1.15 billion by the end of 2019.
All presented methods have specific advantages and disadvantages, therefore it has to be evaluated which techniques are most useful in the software development process. IAST can be used as a useful complement to SAST and DAST, but it does not completely complement them. We always recommend to evaluate the SDL by security experts in order to find an efficient solution.
The methods presented cannot replace the following points:
Continuous Security Testing mit IAST, Matthias Rohr, October 2019