Static Application Security Testing (SAST): Is the process of testing the source code, binary or byte code of an application. In SAST you do not need a running system. It is ideal for helping to reduce the number of security defects in an application introduced during the code writing and unit testing phases of SDLC.
Pros:
SAST can pin point the code where the flaw is.
You can detect vulnerabilities before it is deployed: SAST does not need a running application.
Using SAST you can find vulnerabilities in an earlier phase of the Application’s development
SAST ensure secure coding policies are followed, hence increase coding standard company wide which helps in company long run.
SAST project the root causes of vulnerabilities in source code.
Cons:
SAST cannot discover vulnerabilities related to web server and app server.
Its almost impossible to find out vulnerabilities like Privilege Escalation, Potential File upload, CSRF, session related vulnerabilities and many more.
SAST fails to find vulnerabilities located outside the code or in third party interfacing
SAST cannot find out vulnerabilities related to operational deployment
Business Logic vulnerabilities cannot be discovered by a typical SAST automated tool
SAST is more expensive and has higher overhead
To do SAST you need resources having good secure coding knowledge for each technology used by company.
You need to provide the source code or binaries for SAST
Myths about SAST:
Myth 1: SAST gives better coverage: It is a myth that SAST gives better coverage. SAST cannot find vulnerabilities in Business Logic or in third party code/interfacing.
Myth 2: SAST has lower false positive: This is not true. All tools throw out a lot of false positives irrespective of SAST or DAST. Human augmentation is the only way to remove all false positives.
Dynamic Application Security Testing (DAST): Is the process of testing an application during its running state. In DAST you do not need the source code or the binaries. It is a method to probe from outside just like a hacker.
Pros:
DAST can detect vulnerabilities related to operational deployment
Business Logic Flaws can be figured out by DAST if you are using Hybrid Testing (with manual augmentation)
Does not need access to code.
DAST is easier to adopt, lower in cost and is more mature in terms of industry adoption
DAST can find vulnerabilities located outside the code or in third party interfacing
Cons:
DAST cannot pin point the exact location of vulnerability in the code.
Coding quality or adherence to coding guidelines cannot be understood easily.
Manual Security Testing (MST): Above mentioned both security testing approach can be done manually. But as we all know there are automated tools available in market for both but none of them gives full coverage for their respective approaches. So to use these approaches effectively with 100% coverage we should always integrate manual process in it.
Manual audit covers vulnerabilities like: Session Management, CSRF Attack, Privilege escalation, Weak Password Policy, Man in Middle attack etc.
Conclusion: SAST, DAST and MST should be used for different purposes, because they are adept to identifying different classes of vulnerabilities, and at different stages of the Software Development Life-Cycle (SDLC). That is precisely why SAST, DAST and MST should be considered complementary (SAST+DAST+MST), and NOT competitive with one another(SAST Vs DAST Vs MST). As when performing most tasks, to achieve the best results you need the combination of three.
Pros:
SAST can pin point the code where the flaw is.
You can detect vulnerabilities before it is deployed: SAST does not need a running application.
Using SAST you can find vulnerabilities in an earlier phase of the Application’s development
SAST ensure secure coding policies are followed, hence increase coding standard company wide which helps in company long run.
SAST project the root causes of vulnerabilities in source code.
Cons:
SAST cannot discover vulnerabilities related to web server and app server.
Its almost impossible to find out vulnerabilities like Privilege Escalation, Potential File upload, CSRF, session related vulnerabilities and many more.
SAST fails to find vulnerabilities located outside the code or in third party interfacing
SAST cannot find out vulnerabilities related to operational deployment
Business Logic vulnerabilities cannot be discovered by a typical SAST automated tool
SAST is more expensive and has higher overhead
To do SAST you need resources having good secure coding knowledge for each technology used by company.
You need to provide the source code or binaries for SAST
Myths about SAST:
Myth 1: SAST gives better coverage: It is a myth that SAST gives better coverage. SAST cannot find vulnerabilities in Business Logic or in third party code/interfacing.
Myth 2: SAST has lower false positive: This is not true. All tools throw out a lot of false positives irrespective of SAST or DAST. Human augmentation is the only way to remove all false positives.
Dynamic Application Security Testing (DAST): Is the process of testing an application during its running state. In DAST you do not need the source code or the binaries. It is a method to probe from outside just like a hacker.
Pros:
DAST can detect vulnerabilities related to operational deployment
Business Logic Flaws can be figured out by DAST if you are using Hybrid Testing (with manual augmentation)
Does not need access to code.
DAST is easier to adopt, lower in cost and is more mature in terms of industry adoption
DAST can find vulnerabilities located outside the code or in third party interfacing
Cons:
DAST cannot pin point the exact location of vulnerability in the code.
Coding quality or adherence to coding guidelines cannot be understood easily.
Manual Security Testing (MST): Above mentioned both security testing approach can be done manually. But as we all know there are automated tools available in market for both but none of them gives full coverage for their respective approaches. So to use these approaches effectively with 100% coverage we should always integrate manual process in it.
Manual audit covers vulnerabilities like: Session Management, CSRF Attack, Privilege escalation, Weak Password Policy, Man in Middle attack etc.
Conclusion: SAST, DAST and MST should be used for different purposes, because they are adept to identifying different classes of vulnerabilities, and at different stages of the Software Development Life-Cycle (SDLC). That is precisely why SAST, DAST and MST should be considered complementary (SAST+DAST+MST), and NOT competitive with one another(SAST Vs DAST Vs MST). As when performing most tasks, to achieve the best results you need the combination of three.
