DAST, SAST and SCA: A Practical Guide to Application Security Testing.

Sandeepkomal

6 min read

·

Aug 19, 2026

--

1

Listen

Share

Press enter or click to view image in full size

Modern applications are built using source code, open-source libraries, APIs, containers, and cloud infrastructure. Every layer can introduce security vulnerabilities.

This is where SAST, SCA, and DAST become important.

They provide three different perspectives:

• SAST: Is my source code insecure?
• SCA: Are my dependencies vulnerable?
• DAST: Can my running application be exploited?

Together, they form an important foundation for Application Security (AppSec) and DevSecOps.

1. SAST — Static Application Security Testing

SAST analyzes source code without executing the application.

It is usually performed early in the development lifecycle, such as during development, Pull Requests, or CI pipelines.

SAST looks for insecure coding patterns such as:

• Hardcoded secrets
• SQL injection
• Command injection
• Insecure deserialization
• Arbitrary code execution using eval() / exec()
• Unsafe YAML loading
• Path traversal
• Insecure SSL/TLS configuration
• Weak cryptography such as MD5/SHA-1
• Insecure temporary-file creation
• Debug mode enabled

For example, this SQL pattern is dangerous:

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

User-controlled input is being directly added to the SQL statement.

The recommended solution is to use parameterized queries.

Similarly, code such as:

subprocess.call(user_input, shell=True)

can create command-injection risks when user_input is controlled by an attacker.

Why SAST Matters

The earlier a vulnerability is discovered, the easier and cheaper it is to fix.

Developer → Pull Request → SAST → Fix → Merge

Popular SAST Tools

• SonarQube
• Semgrep
• CodeQL
• Checkmarx
• Fortify
• Bandit

For our example lab, SonarQube can scan the vulnerable Python application.

2. SCA — Software Composition Analysis

Modern applications depend heavily on third-party libraries.

For example, a Python application may use:

Flask
Requests
PyYAML
SQLAlchemy

Even if your own source code is secure, one of these dependencies may contain a known vulnerability.

This is what SCA looks for.

SCA:

• Identifies application dependencies
• Checks package versions
• Matches vulnerabilities against known CVEs and security advisories
• Helps developers identify outdated or vulnerable packages

For Python applications, pip-audit is a simple example:

pip-audit -r requirements.txt

The scan may identify vulnerable versions of packages such as Flask or Requests and recommend upgrading them.

Popular SCA Tools

• pip-audit
• Snyk
• Dependabot
• OWASP Dependency-Check
• Trivy
• Grype

The key lesson is:

Even perfect application code can be insecure because of a vulnerable dependency.

3. DAST — Dynamic Application Security Testing

SAST examines the code.

SCA examines dependencies.

DAST examines the running application.

DAST interacts with an application through its exposed interfaces, usually HTTP/HTTPS, and looks for vulnerabilities from an attacker’s perspective.

A simplified flow is:

DAST Scanner
     ↓
HTTP Requests
     ↓
Running Application
     ↓
HTTP Responses
     ↓
Security Findings

DAST does not require access to the application’s source code.

4. DAST with OWASP ZAP

One of the most popular open-source DAST tools is OWASP ZAP — Zed Attack Proxy.

For our lab, we can use OWASP Juice Shop, a deliberately vulnerable web application.

Start Juice Shop:

docker run -d \
  --name juice-shop \
  -p 3000:3000 \
  bkimminich/juice-shop

Open:

http://localhost:3000

Now the application is running and can be tested.

Run ZAP from the CLI

docker run --rm \
  -v "$(pwd):/zap/wrk" \
  -t ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py \
  -t http://host.docker.internal:3000 \
  -r zap-report.html

ZAP can identify issues such as:

• Security misconfigurations
• Missing security headers
• Information disclosure
• Authentication-related weaknesses
• Injection-related issues
• Cross-site scripting indicators
• Other web application security weaknesses

The exact findings depend on the application and scan configuration.

5. Running ZAP from the UI

ZAP can also be used through its web interface.

Run:

docker run -it \
  -p 8080:8080 \
  ghcr.io/zaproxy/zaproxy:stable \
  zap-webswing.sh

Open:

http://localhost:8080/zap

The UI allows you to explore the application, inspect requests and responses, configure scans, and review security findings.

6. Building a Vulnerable Application

To understand these tools properly, create a small Python application containing intentionally vulnerable code.

For example:

appsec-lab/
├── app.py
├── requirements.txt
└── README.md

The application can intentionally contain:

• Hardcoded secrets
• SQL injection patterns
• Command injection
• Debug mode enabled
• Vulnerable dependency versions

The purpose is to create a controlled environment where you can see how different security tools detect different problems.

Run the application with:

pip install -r requirements.txt
python app.py

For a Flask application, it may run at:

http://localhost:5000

7. What Each Tool Finds

After running the scans, you can compare the findings like this:

Hardcoded Secret

SAST: Yes
SCA: No
DAST: No

Vulnerable Library

SAST: No
SCA: Yes
DAST: No

SQL Injection

SAST: Yes
SCA: No
DAST: Yes

Command Injection

SAST: Yes
SCA: No
DAST: Yes

Runtime Misconfiguration

SAST: No
SCA: No
DAST: Yes

What This Means

SAST focuses on vulnerabilities in your source code.

SCA focuses on vulnerabilities in third-party dependencies and libraries.

DAST focuses on vulnerabilities that can be identified in the running application.

These areas can overlap. A vulnerability may sometimes be detected by more than one security tool, depending on the tool and its configuration.

The important point is that each approach provides a different security perspective.

8. Why We Need All Three

Imagine your code passes SAST.

That does not mean your dependencies are safe.

SCA may discover that your application uses a vulnerable package.

Now imagine SAST and SCA both pass.

Your running application could still expose a vulnerability that becomes visible only through actual HTTP interaction.

DAST can help identify those runtime issues.

Therefore:

SAST → Code Security
SCA  → Dependency Security
DAST → Runtime Security

No single scanner provides complete application security coverage.

9. Fixing the Vulnerabilities

Finding vulnerabilities is only the first step.

The next step is remediation.

Hardcoded Secrets

Instead of storing:

PASSWORD = "secret123"

use environment variables or a dedicated secrets-management solution.

SQL Injection

Replace dynamically constructed SQL with parameterized queries.

Command Injection

Avoid passing untrusted input directly to shell commands and use safer APIs with strict input validation.

Vulnerable Dependencies

Upgrade affected packages to secure versions after reviewing compatibility and testing the application.

Debug Mode

Disable debug mode in production because it can expose sensitive information.

10. Re-Run the Scans

After fixing the issues, don’t stop.

Run the scans again:

Find Vulnerability
       ↓
Fix Vulnerability
       ↓
SAST
       ↓
SCA
       ↓
DAST
       ↓
Compare Results

The goal is to verify that the vulnerabilities have actually been addressed.

11. Integrating Security into DevSecOps

Security tools become much more effective when integrated directly into the CI/CD pipeline.

A typical DevSecOps flow can look like:

Developer
    ↓
Git Commit / Pull Request
    ↓
SAST
    ↓
SCA
    ↓
Build
    ↓
Container Scan
    ↓
Deploy to Test
    ↓
DAST
    ↓
Security Gate
    ↓
Production

Security Tools by Area

SAST — Source Code Security

SonarQube
Semgrep
CodeQL

SCA — Dependency Security

pip-audit
Snyk
Dependabot

DAST — Application Security Testing

OWASP ZAP

Container Security

Trivy
Grype

IaC Security

Checkov
Trivy

Secret Detection

Gitleaks

Kubernetes Security

Kyverno
Falco

You don’t need to use every tool.

Choose tools based on your application’s technology stack, infrastructure, security requirements, and CI/CD environment.

The goal is to make security an automated part of software delivery, rather than a manual check performed only before production.

12. Security Is a Continuous Process

Security should not be treated as a one-time scan before production.

Applications constantly change:

• Developers add new code
• Dependencies receive new CVEs
• APIs change
• Infrastructure changes
• New vulnerabilities are discovered

Therefore, security testing should continuously run as part of development and deployment.

The ideal cycle is:

Write Code
    ↓
Scan
    ↓
Find Vulnerability
    ↓
Fix
    ↓
Test
    ↓
Deploy
    ↓
Monitor
    ↓
Scan Again

Final Takeaway

SAST, SCA, and DAST are complementary security practices.

SAST finds vulnerabilities in your source code.

SCA identifies vulnerabilities in third-party dependencies.

DAST tests the running application from an attacker’s perspective.

Using them together provides much better coverage than relying on a single security tool.

The practical AppSec mindset is simple:

Build it → Scan it → Understand it → Fix it → Scan it again.

That is how security becomes part of DevSecOps rather than something checked only at the end of a release.

⭐ If you found this useful, don’t forget to follow me on GitHub for more projects and DevOps content! → https://github.com/SandeepKomal

#DevSecOps #AppSec #CyberSecurity #SAST #SCA #DAST #SonarQube #OWASP #OWASPZAP #pipAudit #ApplicationSecurity #DevOps #ShiftLeftSecurity #SecureCoding #CICD #CloudSecurity