There are many methodologies you can use to detect application vulnerabilities. One of the most common methodologies is Static Application (or Analysis) Security Testing. Before we dive into the shortcomings of SAST solutions, let’s first outline what Static Application Security Testing is.
What is Static Application Security Testing?
SAST is a set of technologies that analyze the application’s code, byte code, and binaries line by line. As the analyzed code is transparent and available to the tool, Static Application Security Testing is a white-box testing technique.
Learn more in our detailed guide to iast.
Static Application Security Testing offers:
- Accuracy when it comes to recognizing flaws in the code
- Identification of vulnerabilities specific to code
- Identification of weaknesses that can become severe security risks if they aren’t remediated
The ability of SAST solutions to find the exact line of code that needs remediation can reduce remediation time and effort for developers.
To learn more about SAST solutions you can check out these resources:
https://www.gartner.com/en/information-technology/glossary/static-application-security-testing-sast
https://owasp.org/www-community/Source_Code_Analysis_Tools
Shortcomings of SAST solutions
Limitation 1: Inability to scan runtime applications
While SAST solutions can detect many common vulnerabilities like XSS, buffer overflow, and SQL Injection, they are limited to vulnerabilities that occur in the code itself. Unfortunately, many vulnerabilities in a runtime application do not actually exist in the code, but only arise when the application is compiled. If you rely solely on SAST solutions, you may release potentially vulnerable applications.
As an exampleStatic Application Security Testing falls short when it comes to finding issues connected to:
- Authentication (is the code vulnerable to brute force attacks, or is a password reset as effective as it can be, etc.)
- Sensitive data storage and transmission (especially in cases when it can’t tell the difference between sensitive and non-sensitive data)
- Privilege escalation and lack of authorization
- Data privacy (making sure it masks certain sensitive information when it’s displayed)
These issues become even more acute when dealing with a microservices environment where much of the code actually sits between the different services.
Learn more in our detailed guide to shift left testing.
Limitation 2: SAST needs access to source code
Some organizations don’t have access to the application’s source code. This is a big issue as Static Application Security Testing is complex. For it to function properly it needs a semantic understanding of the code. This includes the codes’ dependencies, configuration files, etc. and many of other pieces that are always in motion. Most dependencies aren’t even written in the same programming language. Can SAST understand all these moving pieces? While also being swift, accurate, and have a low false-positives rate? Not exactly.
Limitation 3: The need for a different SAST instance for every coding language
When an organization uses multiple code languages, multiple instances of SAST solutions are needed.
That means all of them require separate maintenance and configuration. This adds significant overhead.
Limitation 4: Limited coding language support
In addition to requiring a different SAST instance for each coding language used in an organization, SAST is limited to specific coding languages. While SAST providers are constantly adding support for new languages, there are some languages that will never be supported and others where SAST falls short from providing complete coverage.
As examples, the effectiveness of SAST is reduced when JavaScript, Python, and other dynamically typed languages are used.
JavaScript is the standard programming language of the web, and web is the most used computing platform ever built. SAST’s inability to work well with JavaScript represents a significant limitation. There are over 1.6 billion websites in the world. JavaScript is used in 95% of them.
Learn more in our detailed guide to iast.
Limitation 5: Disadvantages in a Microservices environment
Another issue with Static Application Security Testing tools is the Microservices architecture. SAST solutions can’t work in a world of Microservices. That’s a huge problem as most developers today use microservices architecture. Microservices architecture is highly maintainable and organized around business capabilities.
Check out best ways to test Microservices security.
Limitation 6: False Positives
One of the biggest problems with SAST solutions is that they are prone to false positives. Developers can get results that point out a lot of findings. Only it turns out most weren’t actually exploitable, or relevant. These results take time to examine and see if a flaw can damage your application or not.
Stay tuned for our next post that outlines the comparison between SAST & DAST.
