422.52 SAST and DAST

Use both static and dynamic testing strategies to detect vulnerabilities in software before and after it runs.

Overview

Secure software development requires both static and dynamic analysis techniques to detect vulnerabilities. These techniques allow developers to identify issues early in development (before the code is run) and also catch problems that appear during execution.

• Static Application Security Testing (SAST) scans source code, bytecode, or binaries for insecure patterns without running the program.

• Dynamic Application Security Testing (DAST) interacts with the running application, simulating real-world attacks to test how it behaves in practice.

Using both SAST and DAST together improves coverage and reduces the chance of undetected vulnerabilities reaching production.

Targets

In this topic, students learn to:

• Distinguish between SAST and DAST and explain how they work

• Identify what types of vulnerabilities each method detects

• Evaluate the strengths and limitations of each testing strategy

• Use testing tools to identify insecure code and system behaviour

Syllabus references

Secure software architecture

Developing secure code

• Apply and evaluate strategies used by software developers to manage the security of programming code, including – static application security testing (SAST) – dynamic application security testing (DAST)

What is SAST?

SAST is a white-box testing technique. It scans code without executing it, identifying vulnerabilities early in development.

Examples of vulnerabilities detected:

• Hardcoded passwords or secrets

• Unsafe string concatenation (e.g. SQL injection)

• Missing input validation

• Deprecated or dangerous function use

Common tools:

• SonarQube

• Bandit (Python)

• Semgrep

• ESLint Security plugins

• Fortify SCA

Sample detection (Python):

query = "SELECT * FROM users WHERE name = '" + user_input + "'"

A SAST tool would flag this as vulnerable to SQL injection.

What is DAST?

DAST is a black-box testing technique. It runs against a live application to simulate attacks and analyse real-world behaviour.

Examples of vulnerabilities detected:

• Misconfigured authentication

• Insecure error handling

• Cross-site scripting (XSS)

• Session management issues

• Unhandled server errors or timeout behaviour

Common tools:

• OWASP ZAP

• Burp Suite

• Arachni

• Nikto

DAST is useful when source code is not available or when testing production or staging environments.

Key differences

Feature	SAST	DAST
Access to source code	Required	Not required
When it runs	During development (early)	During or after deployment
Test method	White-box	Black-box
Detects	Code structure flaws	Runtime behaviour and configuration
Best for	Finding logic errors early	Validating user experience security

When to use each method

• Use SAST during development to:

  • Catch unsafe coding patterns early

  • Enforce secure coding standards

  • Reduce technical debt

• Use DAST during staging or post-deployment to:

  • Test system resilience under real-world conditions

  • Simulate attacker behaviour

  • Validate security controls (e.g. error messages, redirects)

Combined approach

SAST and DAST should be used together for complete security testing:

• SAST finds flaws in source code before they become vulnerabilities

• DAST identifies what an attacker could exploit once the application is running

Summary

• SAST scans code statically, helping catch issues early in development

• DAST tests the running application from the outside, simulating attacker behaviour

• Both methods are essential for finding different types of vulnerabilities

• Together, they form the foundation of a strong secure development pipeline