Application Security: Integrating SAST, DAST, Code Review, and DevSecOps

Subtitle: What each control can see

• Left column - SAST (static):
• Reads code or built artifacts
• Never runs the service
• Catches injection, unsafe calls
• Blind to who may do what
• Fast, cheap: fits early commits

• Right column - DAST (dynamic):
• Probes the running app from outside
• Needs a deployed target
• Sees runtime config gaps
• A valid 200 can hide a flaw
• Slow, contextual: fits later

• Honest test - seed the pipeline:
• 1 planted flaw per control family
• 1 benign near-neighbor each too
• Pass = flaw caught, benign quiet
• Fixer sees file, line, how to repair

• Evidence differs per stage:
• Threat model: design abuse paths
• Secure review: trust bounds, data flow
• Dependency scan: known bad versions
• Secret scan: keys in the repo
• Each control = one kind of evidence

• The flaw both scanners miss:
• API authz bug, no bad syntax
• Static rule sees nothing odd
• DAST gets a valid 200, moves on
• Test: two users, A cannot read B
• Assert invariants, not endpoints

• Shift left, do not pile up:
• Fast high-confidence checks early
• Slow contextual tests later
• More tools add noise, not reach
• Repeatable, owned, near the change
• That is what DevSecOps means

Taped rule strip: Tool count is not coverage.