While everyone still draws attention to the need for protection from cyber-attacks and the need for firewalls, intrusion prevention systems, and similar tools, recent highly publicized breaches have been raising awareness on weaknesses in software developed and used. The market is now forced to focus on how to identify and remediate vulnerabilities within applications themselves as things like buffer overruns, SQL injections, cross-site scripting, hard-coded passwords, memory leaks, uninitialized variables, division by zero, and integer overflows can have devastating results.
This is quite a change from the way things used to be. Rather than being an afterthought, security in software design is now becoming an increasingly important concern during development as applications are becoming more and more accessible and hence becoming vulnerable to a wide variety of threats. There is much concern over the likelihood of unauthorized code manipulating applications to access, steal, modify, or delete sensitive data.
You may be looking to incorporate Application Security Testing (AST) into your security program. Perhaps you have heard of various approaches and are trying to determine how best to proceed. As a first step, you may want to be familiar with the different approaches available in the marketplace today:
- Static AST (SAST) – analyzes source code for vulnerabilities during programming and the testing software life cycle (SLC). Think of this as testing the application from inside out.
- Dynamic AST (DAST) – analyzes the running state of applications during testing or when application is operational. Think of this approach as testing the application from outside in, probing and prodding it in unexpected ways to find security vulnerabilities.
- Interactive AST (IAST) – combines SAST and DAST together.
- Mobile AST – combines SAST and DAST plus behavioral analysis.
DAST and SAST are the most widely accepted approaches with high adoption and maturity rates out of the four types today. IAST and Mobile AST have only recently emerged and don’t have the same adoption as of yet.
Most organizations with limited resources have traditionally taken the route to implement DAST, primarily due to the thinking that it is cheaper and does not take a long time to implement and train the developers. However, this approach has usually fallen short in the more progressive development methods due to its inherent limitations. DAST tools can’t be used on source code or un-compiled application code, delaying the security deployment till the latter stages of development.
While the norm today in the market is that performing some application security testing is better than not performing any at all, organizations should consider combining SAST with DAST to combat the security challenges they face today. After all, application-layer attacks are growing at a stunning pace while organizations are trying to figure out how to adequately improve application security programs giving the bad guys the upper hand to do harm.
