Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

SAST vs. DAST: What’s the Best Method For Application Security Testing?

2 425 vues

Publié le

High profile security breaches are leading to heightened organizational security concerns. Firms around the world are now observing the consequences of security breaches that are becoming more widespread and more advanced. Due to this, firms are ready to identify vulnerabilities in their applications and mitigate the risks.

Two ways to go about this are static application security testing (SAST) and dynamic application security testing (DAST). These application security testing methodologies are used to find the security vulnerabilities that make your organization’s applications susceptible to attack.

The two methodologies approach applications very differently. They are most effective at different phases of the software development life cycle (SDLC) and find different types of vulnerabilities. For example, SAST detects critical vulnerabilities such as cross-site scripting (XSS), SQL injection, and buffer overflow earlier in the SDLC. DAST, on the other hand, uses an outside-in penetration testing approach to identify security vulnerabilities while web applications are running.

Let us guide you through your application security testing journey with more key differences between SAST and DAST:

Publié dans : Logiciels
  • Soyez le premier à commenter

SAST vs. DAST: What’s the Best Method For Application Security Testing?

  1. 1. Static application security testing (SAST) and dynamic application security testing (DAST) are both methods of testing for security vulnerabilities, but are used very differently. Here are some key differences between the two: Static Application Security Testing (SAST)Static Application Security Testing (SAST) Dynamic Application Security Testing (DAST)Dynamic Application Security Testing (DAST) SASTSAST DASTDAST vs.vs. White box security testingWhite box security testing Black box security testingBlack box security testing Requires source codeRequires source code Requires a running applicationRequires a running application Finds vulnerabilities earlier in the SDLC Finds vulnerabilities earlier in the SDLC Finds vulnerabilities towards the end of the SDLC Finds vulnerabilities towards the end of the SDLC Less expensive to fix vulnerabilities Less expensive to fix vulnerabilities More expensive to fix vulnerabilities More expensive to fix vulnerabilities Runtime and environment- related issues can’t be discovered Runtime and environment- related issues can’t be discovered Runtime and environment- related issues can be discovered Runtime and environment- related issues can be discovered Typically supports all kinds of software Typically supports all kinds of software Typically scans only apps like web applications and web services. Typically scans only apps like web applications and web services. Tester has access to the underlying framework, design, and implementation. Tests the application from the inside-out. The developer approach. Tests the application from the outside-in. The hacker approach. Tester has no knowledge of the technologies or frameworks that the application is built on. Doesn’t require a deployed application. Analyzes source code or binaries without executing the application. Analyzes software by executing it. Doesn’t require source code or binaries. The scan can be executed as soon as code is deemed feature-complete. Vulnerabilities can be discovered after the development cycle is complete. Since vulnerabilities are found earlier in the SDLC, it’s easier and faster to get the vulnerability remediated. Findings can often be fixed before the code enters the QA cycle. Since vulnerabilities are found towards the end of the SDLC, remediation often gets pushed into the next cycle. Critical vulnerabilities may be fixed as an emergency release. Since the tool scans static code, runtime vulnerabilities can’t be discovered. Since the tool uses dynamic analysis on an application, it is able to find runtime vulnerabilities. Examples include web applications, web services, and thick clients. DAST is not useful for other types of software. SAST and DAST techniques complement each other. Both need to be carried out for comprehensive testing. To learn how to create a comprehensive application security testing program, visit www.cigital.com.

×