The difference between SAST, DAST, IAST, and SCA: and where each runs in the SDLC

• SAST (Static Application Security Testing) – analyzes source or bytecode without running it, finding code-level flaws like SQL injection and hardcoded secrets early in the build.
• DAST (Dynamic Application Security Testing) – tests the running application from the outside like an attacker, finding runtime and configuration flaws in a deployed environment.
• IAST (Interactive Application Security Testing) – instruments the running application with an agent during functional tests, combining code-level insight with runtime context.
• SCA (Software Composition Analysis) – inventories third-party and open-source dependencies and flags known vulnerabilities and license risks.
• Complementary – SAST and SCA shift left into the build; IAST runs during testing; DAST validates the deployed system. Relying on only one leaves a blind spot.

What is SAST and how does it work?

SAST (Static Application Security Testing) examines source code, bytecode, or binaries without executing them. It parses the code into an abstract representation and traces how untrusted data flows through it, flagging patterns like SQL built by string concatenation, missing output encoding, and hardcoded secrets.

package com.bank.service;

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.Statement;

public class LoanService {

    // SAST flags this: SQL injection via string concatenation
    public void findLoanBad(Connection conn, String loanId) throws Exception {
        String sql = "SELECT * FROM loans WHERE id = '" + loanId + "'";
        Statement stmt = conn.createStatement();
        stmt.executeQuery(sql);  // SAST finding: tainted input flows to SQL
    }

    // SAST passes this: parameterized query is safe
    public void findLoanGood(Connection conn, String loanId) throws Exception {
        String sql = "SELECT * FROM loans WHERE id = ?";
        PreparedStatement ps = conn.prepareStatement(sql);
        ps.setString(1, loanId);
        ps.executeQuery();
    }
}

# Running SAST with Semgrep in the build
semgrep scan --config=p/java --error src/
# Output:
# src/LoanService.java:9 -- error: sql-injection
#   Untrusted input flows to SQL query via string concatenation

SAST runs in the build or even the IDE. Its strength is early, per-commit feedback pointing at exact file and line. Its weakness is false positives because it cannot always tell if a flagged path is reachable.

What is DAST and how does it work?

DAST (Dynamic Application Security Testing) tests the running application by sending crafted requests the way an external attacker would. It probes for injection, broken authentication, misconfigured headers, and similar issues.

# Running DAST with OWASP ZAP against a deployed staging environment
docker run -t owasp/zap2docker-stable zap-baseline.py \
  -t https://staging.bank.national-bank.in/api/v1/loans

# Example DAST findings:
# WARN: Missing Content-Security-Policy header
# WARN: X-Frame-Options not set
# FAIL: SQL Injection at /api/v1/loans?id=1' OR '1'='1

DAST runs late against a deployed environment, but its findings are real because it actually triggers the behavior. It has very few false positives.

What is IAST and how does it work?

IAST deploys an agent inside the running application. While functional or integration tests exercise the app, the agent observes actual code paths, data flow, and library calls from the inside. It combines SAST-like precision about where the flaw is with DAST-like confidence that it is real.

 How IAST works during integration tests:

 ┌────────────────────────────────┐
 │  Test Suite (JUnit/Selenium)   │
 │  Sends real HTTP requests      │
 └───────────────┬────────────────┘
                 │
                 ▼
 ┌────────────────────────────────┐
 │  Application + IAST Agent      │
 │  Agent instruments bytecode    │
 │  Observes: data flow, taint,   │
 │  library calls, SQL queries    │
 │  Reports: exact class + line   │
 │  with proof it was triggered   │
 └────────────────────────────────┘

IAST's cost is the runtime overhead of the agent and the need for good test coverage. It runs during integration and functional testing.

What is SCA and how does it work?

SCA (Software Composition Analysis) inventories every direct and transitive dependency and matches them against vulnerability databases like the NVD.

<!-- pom.xml with a vulnerable transitive dependency --syn-kw">>
syn-kw"><dependencysyn-kw">>
    syn-kw"><groupIdsyn-kw">>org.apache.logging.log4jsyn-kw"></groupIdsyn-kw">>
    syn-kw"><artifactIdsyn-kw">>log4j-coresyn-kw"></artifactIdsyn-kw">>
    syn-kw"><versionsyn-kw">>2.14.1syn-kw"></versionsyn-kw">>  <!-- CVE-2021-44228 Log4Shell --syn-kw">>
syn-kw"></dependencysyn-kw">>

# Running SCA with OWASP Dependency-Check
mvn org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=9

# Output:
# [ERROR] Dependency log4j-core-2.14.1.jar has CVE-2021-44228 (CVSS: 10.0)
# [ERROR] Build failed: vulnerability score >= 9

# Running SCA with Trivy on a container image
trivy image bank/transfer-service:latest
# Scans OS packages AND application dependencies in the image

SCA runs in the build on every commit and continuously afterward, because new vulnerabilities are disclosed against libraries you already shipped.

How do SAST, DAST, IAST, and SCA compare?

| Aspect | SAST | DAST | IAST | SCA |
|--------|------|------|------|-----|
| What it tests | Your source code | Running app from outside | Running app from inside | Your dependencies |
| When it runs | Build / IDE | Deployed environment | Integration testing | Build + continuous |
| Needs running app? | No | Yes | Yes | No |
| Points to code line? | Yes | No | Yes | No (points to dependency) |
| False positives | High | Low | Low | Low |
| Catches config issues? | No | Yes | Partially | No |
| Example tools | Semgrep, SonarQube | OWASP ZAP, Burp | Contrast, Checkmarx IAST | OWASP Dep-Check, Snyk, Trivy |

Where does each run in the SDLC?

 ┌─────────┐   ┌─────────┐   ┌─────────────────┐   ┌─────────────┐   ┌────────────┐
 │  Code   │──▶│  Build  │──▶│ Integration Test │──▶│   Staging    │──▶│ Production │
 └─────────┘   └─────────┘   └─────────────────┘   └─────────────┘   └────────────┘
      │             │                │                    │                 │
      ▼             ▼                ▼                    ▼                 ▼
   [SAST]     [SAST + SCA]       [IAST]              [DAST]          [Continuous SCA]
   in IDE     in pipeline      with agent         against deploy    new CVEs disclosed

What are common mistakes when choosing security testing tools?

# WRONG: relying on ONLY SAST and thinking you are covered
# SAST misses: runtime config issues, deployment problems, zero-days in dependencies

# WRONG: relying on ONLY DAST and thinking you are covered
# DAST misses: code-level vulnerabilities in paths it cannot reach, dependency CVEs

# CORRECT: layered approach using all four at their appropriate stages
# SAST + SCA in the build for fast per-commit feedback
# IAST during integration testing for precise runtime validation
# DAST against staging for real-world attack simulation
# Continuous SCA to catch newly disclosed vulnerabilities

What should a senior engineer know?

The senior point is that these are complementary, not competing. Each catches a class of flaw the others miss. At National Bank of India, our loan-origination service had three different vulnerabilities that no single tool found: SAST caught a concatenated SQL query, SCA caught a vulnerable transitive logging library, and DAST caught a misconfigured security header that only appeared once deployed. That is why a mature program runs all four at their appropriate stages.