Domain 6 Β· Lesson 4 of 5

SAST, DAST, SCA & Fuzzing

Kiểm thα»­ BαΊ£o mαΊ­t Ứng dα»₯ng

Application Security Testing Tools

Type What it Scans When Go Tools Pros Cons
SAST
Static Analysis		 Source code (static) β€” no running app needed Pre-build, IDE, CI gosec, Semgrep Early detection; finds secrets in code; no running app needed High false positive rate β€” needs human triage
DAST
Dynamic Analysis		 Running application (black-box from outside) Staging, pre-prod OWASP ZAP, Burp Suite Realistic; finds auth/config/runtime issues Needs running app; may miss code-level issues
IAST
Interactive Analysis		 Runtime with instrumentation agent inside app Testing phase Contrast Security Most accurate; lowest false positive rate; real-time feedback Complex to deploy; performance overhead
SCA
Software Composition		 Third-party dependencies and libraries Every build govulncheck, Snyk, Dependabot Finds CVEs in dependencies you didn't write Only finds known CVEs β€” zero-days not covered
Fuzzing
Mutation Testing		 Random/malformed/unexpected inputs Development phase go-fuzz, AFL Finds unexpected crashes and potential zero-days Time-intensive; requires test harness setup

DevSecOps Pipeline Sequence

pre-commit TruffleHog secrets scan β€” catch secrets before they enter git history
build gosec SAST + Semgrep OWASP rules β€” static analysis of source code
test govulncheck SCA + go test β€” dependency CVE scan + unit/integration tests
container Trivy image scan β€” CVEs in base OS + installed packages
staging OWASP ZAP DAST β€” dynamic scan of running staging APIs
deploy ArgoCD deploy from approved Git SHA β€” only signed, scanned images reach production

Security Gates β€” Block vs Warn

Correct: BLOCK on Critical (exit code 1)

CI pipeline fails. PR cannot merge. Engineer must resolve the finding before the PR proceeds. This is a real security control.

Example: govulncheck || exit 1 β€” merge blocked until CVE is resolved

Wrong: Warning-Only Mode

CI prints a warning but passes with exit code 0. Engineers ignore warnings. Critical CVEs reach production. This is security theater, not a security control.

If SAST/SCA only warns, it provides the illusion of security without the protection.

Code Review Security Checklist

☐Input validation: all user input validated at API boundary
☐Authorization: every endpoint checks permissions server-side
☐Error handling: no stack traces or internal details returned to client
☐Secrets: no hardcoded API keys, passwords, or tokens in code
☐Crypto usage: AES/RSA with correct key sizes (not MD5/DES)
☐Logging: no PII, passwords, or tokens logged
☐SQL queries: parameterized, not string-concatenated
☐Dependencies: new dependencies scanned for known CVEs

Key Terms

SAST DAST IAST SCA Fuzzing gosec Semgrep OWASP ZAP govulncheck Trivy TruffleHog DevSecOps Security Gate
Exam Tips
  1. SAST = source code analysis (high false positive rate β€” requires human triage). Does NOT need a running app.
  2. DAST = live running application, tested from outside (fewer false positives β€” tests what's actually running at runtime).
  3. SCA = third-party libraries and dependencies (CVEs in code you didn't write). SAST = YOUR source code.
  4. Fuzzing = random/malformed inputs to find unexpected behavior (crashes, memory corruption, potential zero-days).
  5. Security gates MUST block (exit code 1) on Critical findings β€” warning-only mode is not a security control.
Work Application β€” Platform C GitHub Actions Security Gates

Platform C Go services pipeline (all steps block on failure):

  1. gosec Go SAST β€” block on HIGH/CRITICAL findings (not advisory mode)
  2. Semgrep with OWASP Go rules β€” block on p0 (critical priority) findings
  3. govulncheck SCA β€” block on Critical CVEs in Go modules
  4. TruffleHog β€” block if any secret detected in git commit history (scan all commits, not just latest)
  5. Trivy container scan β€” block if Critical CVE in Docker image

Platform A Java legacy: Add OWASP Dependency Check Maven plugin β€” run weekly (not every build β€” too slow). Priority: audit for Log4j 1.x and Log4j 2.x < 2.17.1. Replace with Logback/SLF4J. Target: Java 21 migration to get modern tooling support.

Practice Quiz

Q1. SAST vs SCA β€” which one finds CVEs in third-party libraries, and which analyzes your own source code?

β–Ό Reveal Answer
SCA (Software Composition Analysis) finds CVEs in third-party libraries (your dependencies). SAST (Static Application Security Testing) analyzes your own source code for security bugs.
SAST reads your code files and looks for patterns like string concatenation in SQL, hard-coded credentials, or insecure crypto calls. SCA reads your dependency manifest (go.sum, package-lock.json) and looks up each dependency in a CVE database. You need both: SAST because you write buggy code sometimes; SCA because the libraries you use may have known vulnerabilities. They're complementary, not substitutes.

Q2. Why does DAST find authentication and authorization issues that SAST typically misses?

β–Ό Reveal Answer
DAST tests the actual running application β€” it sends real HTTP requests as an attacker would, tests actual authentication flows, and observes the real responses. SAST reads source code and may miss issues that only manifest at runtime (e.g., a misconfigured JWT middleware, missing authorization header check, or session fixation in the framework).
Authentication vulnerabilities like "JWT not validated in route X" or "CORS misconfiguration allows all origins" are often undetectable by SAST because they appear correct in code but are wrong in runtime behavior. DAST discovers them by actually trying: sending requests without auth, sending expired tokens, trying cross-origin requests. This is why DAST complements SAST β€” SAST finds what's wrong in the code, DAST finds what's wrong in the running system.

Q3. An engineer configures gosec to run in warning-only mode (exit 0 even on Critical findings) to reduce CI failures. Why is this a security problem?

β–Ό Reveal Answer
Warning-only mode is not a security control β€” it's security theater. Critical findings will be printed in CI logs but will not block merges. Engineers will ignore warnings over time. Vulnerable code will reach production as if gosec didn't exist.
The purpose of a security gate is to prevent insecure code from advancing in the pipeline. If the gate allows code through regardless of findings, it provides zero protection. The signal-to-noise ratio of SAST tools is already challenging β€” engineers already have difficulty prioritizing real findings from false positives. Advisory-only mode accelerates "alert fatigue" and renders the tool useless as a control. Gates must block (exit 1) on Critical/High to be meaningful.

Q4. What does TruffleHog detect, and why must it scan the full git history rather than just the latest commit?

β–Ό Reveal Answer
TruffleHog detects secrets (API keys, passwords, tokens, private keys) in git commit history. It must scan the full history because a secret that was committed and then deleted in a later commit still exists in git history β€” it can be extracted by anyone with repo access using git log or git show on older commits.
Git is append-only β€” deleting a file in a new commit doesn't remove it from history. A developer who commits AWS credentials, realizes the mistake, and deletes them in the next commit has still exposed those credentials to everyone who ever clones that repository. TruffleHog scans all commits for high-entropy strings and known secret patterns. If a secret is found: assume it's compromised, rotate it immediately, then use git filter-branch or BFG Repo Cleaner to purge the history.

Q5. Fuzzing β€” what type of security bugs does it find that SAST and SCA cannot?

β–Ό Reveal Answer
Fuzzing finds crashes, panics, hangs, memory corruption, and unexpected behavior from malformed inputs β€” including potential zero-day vulnerabilities. SAST finds known bad patterns; SCA finds known CVEs. Fuzzing discovers unknown issues by exercising code paths that normal testing never reaches.
Fuzzing works by sending random, mutated, or boundary-value inputs (e.g., negative numbers, empty strings, extremely long strings, malformed JSON, null bytes) and observing whether the program crashes or behaves unexpectedly. It's particularly effective for parsers, network protocol handlers, and any code that processes external data. In Go: go test -fuzz runs built-in fuzzing. AFL (American Fuzzy Lop) is a classic C/C++ fuzzer. Fuzzing is the most common way to find memory safety vulnerabilities and denial-of-service issues.
← Lesson 3: OWASP Top 10 Lesson 5: Audit & SOC 2 β†’