Static analysis security testing (SAST) is a technique and class of solutions that performs automated testing and analysis of program source code to identify security flaws in applications. SAST is a powerful security tool that offers a variety of advantages. For example, because it does not rely on runtime environments, it can be used to test code during development, catching vulnerabilities early on.
Organizations may be tempted to regard SAST as a complete response to application security precisely because it’s such a powerful tool. However, there is no one complete answer to security. SAST will not detect all vulnerabilities, and some types of application flaws are outside its scope. The first principle of security is that security should be built into applications — and, indeed, all processes — from the outset.
Putting Application Code on the Security Test Bench
As Rohit Sethi reported at Infosec Island, static analysis security testing solutions are widely used by organizations to bench-test application code.
In addition to their independence from specific runtime conditions, SAST solutions are automated and therefore easily scale to testing large blocks of application code. That allows them to cover more code than could ever be subjected to manual testing. Moreover, SAST is capable of identifying vulnerabilities that could not be detected by dynamic testing.
But the proper use of SAST can be technically demanding. The tools must gain a semantic understanding of the code, including its dependencies and configuration files, some of which may be written in a different programming language from the primary source code. And dynamically typed languages such as JavaScript pose an additional challenge since compile-time analyses may not reveal an object’s type or class.
Bugs Versus Flaws: The Multiple Sources of Vulnerabilities
It is important to understand that no single technique, including SAST, is a cure-all for failings in application security. As Brian Chess and Jacob West noted in their book, “Secure Programming with Static Analysis,” “no one claims that source code review is capable of identifying all problems.”
Chess and West observed that not all flaws in applications are software bugs that can be detected through code analysis. Many security vulnerabilities “are built into the design” of applications, rather than the specific coding into a computer language. For example, if confidential data is not “programmatically discernible” from less sensitive information, no code analysis can ensure that it is given special security treatment.
Other potential risks that may elude static analysis security testing include poor password management, vulnerability to brute-force attacks, the mishandling of authorization and compliance issues such as blanking out credit card numbers.
The Bottom Line on Static Analysis Security Testing
While SAST is a powerful security tool for safeguarding applications, organizations cannot simply implement it and assume their applications will be fully secure. Application security needs to be built into programs by design and from the outset, not bolted on as an afterthought.
Security-conscious design will be responsive to the vulnerabilities that static analysis security testing alone cannot detect. It will also allow SAST to function in its most effective role as a powerful tool for catching app and software vulnerabilities that might slip through even the most thorough security design process.
Rick Robinson is a writer and blogger, with a current 'day job' focus on the tech industry and a particular interest in the interplay of tech-driven factors ...