Skip to content
Security Testing: SAST, DAST, Dependency Scanning, and OWASP Guide

Security Testing: SAST, DAST, Dependency Scanning, and OWASP Guide

DodaTech Updated Jun 20, 2026 6 min read

Security testing evaluates software for vulnerabilities, misconfigurations, and weaknesses that could be exploited by attackers — covering everything from source code analysis to runtime scanning to dependency audits.

What You’ll Learn

  • The difference between SAST, DAST, IAST, and RASP testing approaches
  • How to run dependency scanning with Snyk, Dependabot, and OWASP Dependency-Check
  • The OWASP Top 10 vulnerabilities and how to test for each
  • How to build a security testing pipeline in CI/CD
  • Common security testing mistakes and how to avoid them

Why Security Testing Matters

Security breaches cost companies an average of $4.45 million per incident (IBM 2023). Most breaches exploit known vulnerabilities that could have been caught by automated security testing. Regular security testing catches SQL injection, cross-site scripting, hardcoded secrets, and dependency vulnerabilities before attackers find them. For security software like Durga Antivirus Pro, security testing is not optional — a vulnerability in the scanner itself would compromise every user who relies on it.

Learning Path

    flowchart LR
  A[Static Analysis] --> B[Security Testing<br/>You are here]
  B --> C[Penetration Testing]
  C --> D[Security Monitoring]
  D --> E[Incident Response]
  style B fill:#f90,color:#fff
  

Security Testing Approaches

SAST (Static Application Security Testing)

Analyzes source code without executing it, finding vulnerabilities early in the development lifecycle.

Tools: SonarQube, Semgrep, Checkmarx, Fortify

# Semgrep example — find SQL injection patterns
semgrep --config p/python
# Semgrep flags this as SQL injection
query = f"SELECT * FROM users WHERE id = {user_input}"
cursor.execute(query)

# This passes — parameterized query
query = "SELECT * FROM users WHERE id = %s"
cursor.execute(query, (user_input,))

Best for: Catching injection flaws, hardcoded secrets, insecure crypto, and broken authentication early.

DAST (Dynamic Application Security Testing)

Tests running applications from the outside, like an attacker would, without access to source code.

Tools: OWASP ZAP, Burp Suite, Acunetix

# OWASP ZAP quick scan
docker run -v $(pwd):/zap/wrk/ zaproxy/zap-stable \
  zap-full-scan.py \
  -t https://example.com \
  -r report.html

Best for: Finding runtime vulnerabilities, misconfigurations, and authentication issues.

IAST (Interactive Application Security Testing)

Combines SAST and DAST by instrumenting the application and analyzing code paths during testing.

Tools: Contrast Security, Hdiv

Best for: Accurate results with fewer false positives than SAST or DAST alone.

Dependency Scanning

Analyzes third-party libraries for known vulnerabilities (CVEs).

Tools: Snyk, GitHub Dependabot, OWASP Dependency-Check

# Snyk scan
snyk test --all-projects

# Output example
Testing /home/project...

Tested 342 dependencies for known vulnerabilities, found 8:

Vulnerabilities found:
  [HIGH] Prototype Pollution in lodash@4.17.15
  [MEDIUM] Regular Expression DoS in minimatch@3.0.4
  [LOW] Missing Origin Validation in axios@0.21.1

Upgrade lodash to 4.17.21 to fix.

OWASP Top 10 Vulnerabilities

The OWASP Top 10 is the standard awareness document for web application security:

1. Broken Access Control

Users accessing resources they shouldn’t have permission to.

# BAD: No access control check
@app.route("/api/users/<user_id>")
def get_user(user_id):
    user = db.find_user(user_id)
    return jsonify(user.to_dict())

# GOOD: Verify the requester owns the resource
@app.route("/api/users/<user_id>")
def get_user(user_id):
    if request.current_user.id != int(user_id):
        return jsonify({"error": "Forbidden"}), 403
    user = db.find_user(user_id)
    return jsonify(user.to_dict())

2. Cryptographic Failures

Weak encryption, missing TLS, exposed sensitive data.

3. Injection

SQL, NoSQL, OS command, and LDAP injection attacks.

# BAD: Command injection
import os
user_input = request.args.get("filename")
os.system(f"rm {user_input}")

# GOOD: No shell execution, use safe API
import os
filename = request.args.get("filename")
safe_path = os.path.join(UPLOAD_DIR, filename)
if os.path.exists(safe_path):
    os.remove(safe_path)

4-10

Other categories include Insecure Design, Security Misconfiguration, Vulnerable Components, Authentication Failures, Data Integrity Failures, Logging & Monitoring Failures, and SSRF.

Security Testing Pipeline

Integrate security checks into your CI/CD pipeline:

# .github/workflows/security.yml
name: Security Scan
on:
  push:
    branches: [main]
  pull_request:

jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Semgrep SAST
        uses: semgrep/semgrep-action@v1
        with:
          config: p/default
          publishToken: ${{ secrets.SEMGREP_TOKEN }}

  dependency-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Snyk Scan
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

  dast:
    runs-on: ubuntu-latest
    needs: [deploy-staging]
    steps:
      - name: OWASP ZAP Scan
        uses: zaproxy/action-full-scan@v0.4.0
        with:
          target: "https://staging.example.com"

Secret Detection

Prevent hardcoded secrets from reaching the repository:

# Using git-secrets
git secrets --scan
git secrets --scan-history
# Using truffleHog in CI
- name: Secret Scanning
  uses: trufflesecurity/trufflehog@v3
  with:
    extra_args: --only-verified

Common Security Testing Mistakes

1. Only Scanning Before Release

Security testing should be continuous — every commit, not every release.

Fix: Run SAST and dependency scanning on every PR.

2. Ignoring False Positives

False positives lead to alert fatigue. Teams stop reading security reports.

Fix: Configure severity thresholds, suppress known false positives with proper documentation, and review reports regularly.

3. No DAST in the Pipeline

SAST catches source-level issues but misses runtime vulnerabilities.

Fix: Add DAST scanning to your staging deployment pipeline.

4. Not Scanning Dependencies

Third-party libraries account for 70-90% of modern codebases and a large share of vulnerabilities.

Fix: Use Dependabot or Snyk with automated PR creation for vulnerable dependencies.

5. Scanning but Not Remediating

Finding vulnerabilities without fixing them wastes the testing effort.

Fix: Set SLA-based remediation targets (critical: 24 hours, high: 7 days, medium: 30 days).

6. Ignoring Infrastructure as Code

Security misconfigurations in Terraform, Docker, and Kubernetes are a major attack vector.

Fix: Use Checkov or tfsec to scan IaC templates.

7. No Security Testing for APIs

Modern applications expose dozens of API endpoints, each a potential attack surface.

Fix: Use API-specific security tools (42Crunch, APIsec) or include API endpoints in DAST scans.

Practice Questions

1. What is the difference between SAST and DAST?

SAST analyzes source code without executing it (white-box, early in pipeline). DAST tests running applications from outside (black-box, later in pipeline).

2. What is the OWASP Top 10?

A standard awareness document listing the ten most critical web application security risks, updated every 3-4 years.

3. Why is dependency scanning important?

Third-party libraries constitute most of a modern codebase and are a common attack vector. One vulnerable dependency can compromise the entire application.

4. What is secret detection and when should it run?

Secret detection scans code for hardcoded credentials, API keys, and tokens. It should run on every commit and scan the full git history.

5. How quickly should critical vulnerabilities be remediated?

Within 24 hours for critical, 7 days for high severity vulnerabilities.

Challenge: Set up a complete security pipeline using GitHub Actions with Semgrep (SAST), OWASP ZAP (DAST), and Snyk (dependency scanning). Run it against a deliberately vulnerable application like WebGoat.

FAQ

Do I need all three (SAST, DAST, dependency scanning)?
Yes — they catch different types of vulnerabilities. SAST catches code issues, DAST catches runtime issues, and dependency scanning catches library vulnerabilities.
Can security testing replace penetration testing?
No. Automated tools catch known vulnerability patterns. Penetration testing finds business logic flaws, chained exploits, and novel vulnerabilities that automated tools miss.
How many false positives do security tools generate?
It varies by tool and configuration. SAST tools typically have 10-30% false positive rates. Tuning rules and suppressing known false positives reduces this.
When should I run DAST in the pipeline?
After the application is deployed to staging. DAST needs a running instance to test.
What is the most important security test to start with?
Dependency scanning — it’s the easiest to set up, catches real vulnerabilities, and has the lowest false positive rate.

What’s Next

TutorialWhat You’ll Learn
Quality Metrics and MeasurementMeasuring security posture over time
Continuous Testing in CI/CDAutomating security checks in the pipeline
Static Code Analysis ToolsDeeper look at SAST tools and configuration

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro. Updated 2026-06-20.

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro