Humans create applications.
Aren’t we also an app?
We have a specific set of functions and life cycles like an application. We have weaknesses. And that makes us vulnerable. So, do we also seek security like an application?
In this article, I want to blend our inner and outer world to understand the fundamental difference between SAST (Static Application Security Testing) and DAST (Dynamic Application Security Testing).
Disclaimer – Please don’t validate whether this article is spiritual or philosophical. All my articles intend to understand the technology and core concepts with subtle strokes of creativity and perspective.
SAST (Static Application Security Testing)
You have to turn inwards to find your weakness.
SAST is a tool that uses an inside-out approach to find application vulnerabilities in the build time environment.
You can think of application source code as you. The more you know yourself from the inside, the better you do outside. From this context, finding vulnerabilities in an application’s source code increases the probability of secure deployment in production.
The whole idea of SAST is shifting security left in the DevOps pipeline. Because it saves money and time, you are aware of your vulnerabilities in advance. You can never win the game if you don’t know your weaknesses.
If you have a terrible memory to remember your wedding anniversary, it’s better to put the reminder. Similarly, addressing critical vulnerabilities in the early stages of the software development life cycle is the beginning of security.
The vital thing to note is you can fix yourself from the inside. Therefore, SAST can scan everything. However, it has no business beyond the source code.
SAST doesn’t help to find vulnerabilities for 3rd parties. That’s where DAST comes into the picture.
DAST (Dynamic Application Security Testing)
Once the arrow is out of the bow, it’s no longer under your control. The same thing happens with production deployment.
Once your application is live, you have to deal with it. No matter what.
DAST has nothing to do with the application’s source code. Instead, it scans the entire application’s dynamic code or whatever is running in the production. It is a tool that deals with vulnerabilities in the run time environment. Therefore, it uses an outside-in approach. You can think of judging yourself while you look in the mirror.
You can also connect about the cosmetic industry I mentioned earlier with DAST. People are not happy with the way they look outside to the world. It makes them vulnerable. Beauty products are nothing but fixing vulnerabilities from the outside. However, the problem could have been addressed much earlier, from the inside.
Please don’t try to match the analogy. The critical thing to note with the above example is when you ignore security in the early stages of the DevOps pipeline; you have to pay the price sooner or later. Therefore, DAST approach is costly and has limitations. It can only scan web applications and web services.
The Fundamental Difference
SAST is a developer tool like a meditation. It deals with your inner-self (source code) before you approach the outer world (production). DAST is a hacker’s tool. It deals with your outer self.
Internal scans work best in silence (SAST in build time). Once the application is live, you have to deal with the noise and cost (DAST in run time).
SAST is a white guy (white-box testing), while DAST is a black guy (black-box testing)