The application security testing (AST) market has a variety of tools across categories for security professionals, including dynamic application security testing (DAST), static application security testing (SAST), interactive application security testing (IAST), software composition analysis (SCA), and API security testing tools, manual testing tools & fuzzers.
But as companies modernize their applications with monolithic codebases residing in on-premises data centers, new requirements for security testing arise. In the past, code chunks lived in private servers, managed by internal infrastructure teams. With the rise of public clouds like Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure, organizations are modernizing their applications for these clouds for cost savings, flexibility, and better performance. This means a transition towards microservices and containers, with a distributed architecture where apps consist of multiple components and resources. This type of architecture takes advantage of public cloud environments where better orchestration and automation can be achieved with each individual piece.
The decomposition of apps in public clouds creates a new set of challenges around application security though. In the past, code was all in one place, but now, it’s spread across many components, services, and resources that all interact with each other. When various components of an app are pointing across s3 buckets in AWS, multiple containers, with APIs to and from other third-party services, it’s hard to tell where a vulnerability starts and ends.
We’ll talk about the other types of application security testing, but for this post, we’ll focus on traditional SAST and why it no longer meets the security testing needs of modern, cloud-native apps.
First, when we talk about SAST, we refer to application security tools designed to analyze application source code, byte code, and binaries for security vulnerabilities. Apps are analyzed in a non-running state, hence “static” testing. SAST can be used by developers and are integrated into IDEs. These tools tell developers what code may be vulnerable and recommendations on how to fix.
SAST tools have source code access and can provide better coverage than DAST and IAST. Also, SAST can be run passively without much configuration or worrying about breaking apps since the code is not executed.
The traits that made SAST strong for legacy apps make it weak for cloud native apps. Here are three reasons SAST tools shouldn’t be used for cloud apps.
As mentioned before, cloud apps are made of many components with multiple teams working on each one. And these components only communicate with each other during runtime. With static testing, the code isn’t run, meaning that the SAST tool won’t be able to see everything working together to pinpoint vulnerabilities. Each component of a distributed cloud app is scanned independently – vulnerabilities that arise when the components are talking to each other are missed.
Scanning code before runtime of a cloud app also results in a large number of false positives and missed vulnerabilities. SAST solutions scan through a long list of potential vulnerabilities to see if the code may be susceptible but many false positives end up being generated as the SAST tool doesn’t know what part of the code is in use and when or if the code is even used (as it could be deprecated). This relates back to the first problem of lack of context. Lots of false positives of vulnerabilities that may not be exploitable (due to input validation and a variety of other reasons) end up being generated by the SAST tool for developers to triage, prioritize, and investigate – wasting time and resources.
This is compounded by the fact that many actual vulnerabilities unique to cloud apps are missed. SAST tools are not focused on cloud misconfigurations or permissions and also miss APIs and other services that interact with a cloud app. Only looking at the code base provides a limited view into how the cloud app actually works and what interacts with the core code components. Risk from vulnerabilities builds as misconfigurations around cloud permissions or access in lower layers elevates the risk throughout an application.
Finally, SAST tools are only as good as they are up-to-date and what they’re specifically made to scan. SAST tools are often limited to one programming language, framework, or sets of libraries. Cloud native apps working with multiple programming languages, different clouds, various APIs, etc. can mean multiple SAST tools to support a comprehensive code scan.
It’s no longer enough to scan code statically – the entire environment needs to be assessed, from how the cloud or container of an app is configured down to the APIs and how each component of an app interacts with each other. SAST solutions no longer have the context of the various microservices, distributed architecture, and services that make up a cloud-native app. New app security testing solutions need to know how a cloud app runs in production and the various components that comprise it.
Looking to learn more about Oxeye? - Book a quick Demo with our experts
.png)
