Organizations worldwide are building and deploying cloud native applications, where the architecture is quite different from yesterday’s monolithic counterparts. What used to be a custom code block installed on a single bare metal server or a virtual machine has morphed into hundreds of small, independent pieces of code. These are installed on loosely-coupled microservices, executed as orchestrated containers, and deployed in the cloud.
Distributed cloud based applications pose challenges to yesterday’s application security testing (AST) solutions. Herein is an overview of AST and the challenges DAST, SAST, IAST, and SCA tools face when assessing vulnerabilities in cloud native applications.
As part of the SDLC process, companies leverage legacy AST tools to run security scans against their applications. But these generate many false positives and miss critical vulnerabilities. They fail in their effort to secure cloud native applications.
More specifically, they don’t fully secure today’s containerized applications built using distributed microservices. What used to be a vulnerability that starts and ends with the same monolithic code segment is now an exposed vulnerable flow involving multiple microservices and infrastructure layers.
Many organizations report to us that AST tools are outdated and don’t provide effective results – leading to frustration and waste of development resources. Migration to the cloud has a major effect on how vulnerabilities come into existence, such that cloud native application security testing requires a new approach.
Not having been designed to test cloud native applications, AST tools can be divided into the following categories:
We’ll rank each category for the following vectors: developer friendliness, security coverage, and accuracy of results. (Our scoring system isn’t scientific in any way; rather, it provides an impression of the aspects of each tool category.)
DAST – Assessing vulnerabilities in cloud native applications at runtime is the function of DAST tools. But DAST scanners only test exposed HTTP and HTML application interfaces. They crawl a web application, collecting information about exposed entry points (e.g., URLs, parameters, cookies), then actively initiate attacks such as SQL injection and cross-site scripting (XSS). On the plus side, modern tools can also perform scans at the individual microservice level.
SAST – Looking for coding and design conditions indicative of security vulnerabilities, these tools analyze application source code, byte code, and binaries in a non-running (static) state. To locate application layer vulnerabilities, SAST tools detect the source function – the “entery point” where user input is entered – and the sink function (e.g., database call, system call) that eventually uses the user input.
IAST – IAST tools use instrumentation that combines DAST and SAST techniques to increase accuracy. It permits DAST-like confirmation of exploit success and SAST-like application code coverage. In some cases, IAST enables security self-testing during general application testing.
SCA – To secure all open source components, their license, and any known security vulnerabilities, SCA tools scan an application’s source code – including related artifacts such as containers and registries.
Web API testing performs fuzz testing of input parameters. Setting them to unusual values causes unexpected behavior and errors in the API backend. This helps with discovering bugs and potential security issues that other QA processes might miss.
The diagram below summarizes the scoring for each of the tool categories:
This table lists the shortcomings of existing/legacy AST tools in relation to efficiently scanning cloud native applications:
You now understand the challenges legacy AST tools face when assessing vulnerabilities. Cloud native application security testing requires a different paradigm with respect to how vulnerabilities are found, assessed, and resolved. Stay tuned for a deeper analysis of each technology and their shortcomings when scanning cloud native applications.
In the meantime, I welcome you to see Oxeye in action - https://www.oxeye.io/get-a-demo