Overview

Security vulnerabilities are bugs. Not special bugs. Just bugs.

You have a thousand bugs in your codebase. Most are "the button is misaligned." A few are "attackers can steal customer data." The difference is severity, not type.

If you're running SAST (Static Application Security Testing) as a separate gate from your normal code quality gates, you're treating them separately. That's wrong. Integrate security into your normal development process, powered by AI, and vulnerabilities become just another class of bug you catch early.

The Three-Layer Approach: SAST, DAST, Runtime

The Cost Principle: Fixing a vulnerability in code review costs $1k. Fixing it in staging costs $10k. Fixing it in production costs $100k+. Every layer of testing you add multiplies your security investment's ROI. SAST at commit-time is the highest ROI security investment.

SAST (Static Application Security Testing)

Analyze source code for security issues. Does the code have SQL injection? Command injection? Hardcoded secrets? Buffer overflows?

SAST runs without executing code. It reads the code and looks for patterns. Modern AI-powered SAST tools like Semgrep, GitHub CodeQL, and others can understand not just syntax, but data flow. They trace user input through your code to see if it could reach a dangerous sink without sanitization.

How AI-Powered SAST Works

Traditional SAST uses pattern matching: "if code contains X, flag it." AI-powered SAST understands context. It knows that a SQL query parameter is dangerous, but a database table name is less dangerous. It knows that input validated with a secure function is okay, but unvalidated input is not.

This means fewer false positives and better catch rate. Tools like CodeQL can ask questions like: "Show me all cases where user input flows to a SQL query without being sanitized." That's not pattern matching. That's understanding data flow.

DAST (Dynamic Application Security Testing)

Test running applications for security issues. Send malicious inputs. See how the app responds. Can you bypass authentication? Can you access other users' data? Can you trigger denial of service?

DAST requires a running system. It's slower than SAST but catches issues that SAST misses (like authentication bypass, session handling flaws, business logic flaws).

AI Improvements in DAST

Traditional DAST is like a robot that follows a script. AI-powered DAST is more like a security engineer. It adapts based on responses. "This endpoint returned 403 Forbidden. Let me try a different attack. This endpoint returned 200 but with redacted data. Let me try to unredact it."

AI-powered DAST can explore your application more like a human would, finding edge cases and business logic flaws that scripted DAST would miss.

Runtime Security

Even after deployment, AI monitors for attacks. Is someone trying to exploit a vulnerability? Is there unusual behavior that looks like a breach? Respond automatically.

Building Your Secure Development Process

Layer 1: SAST in CI/CD

Every commit gets scanned. Vulnerabilities block merge. This is non-negotiable for security-critical code.

For other code, you can have a "report but don't block" mode initially. As your team gets used to fixing issues, move to blocking. The progression looks like: Month 1-2 (report only), Month 3-4 (block on critical), Month 5+ (block on critical and high).

Integration Strategy

Don't run SAST on every file change. That's too slow. Run it on changed files only. Full scan runs nightly. This keeps CI/CD fast while still catching issues.

Layer 2: DAST Pre-Deployment

Before code goes to production, run DAST. Automated attack testing. If it finds major issues, hold deployment. If it finds minor issues, they go on a backlog.

DAST runs on a staging environment that mirrors production. It needs realistic data and realistic scenarios.

Making DAST Effective

DAST only finds what it can test. So give it test accounts, test data, and endpoints to test. Tell it: "Log in as this user, then try to access other users' data. Try to escalate privileges. Try to access admin features."

Layer 3: Runtime Monitoring

After deployment, monitor for attacks. AI detects abnormal behavior. Respond automatically.

Case Study: Financial App SAST Implementation

A fintech company implemented CodeQL for a payment processing app. Week 1: found 47 critical vulnerabilities (SQL injection, hardcoded API keys, insecure deserialization, authentication bypasses). They were shocked. All of this code had been through code review. Some had been in production for months.

Timeline: Week 2-4 fixed all critical and high vulnerabilities (estimated exposure: $5M+ if exploited). Month 2: integrated into CI/CD, now catching new vulnerabilities before merge. Month 6: vulnerability discovery shifted from production (where they previously found 1-2 per quarter via security audits) to development (8-10 per quarter caught in SAST, 0 reaching production).

The shift in metrics shows how important SAST is. Vulnerability cost is exponential: cost to fix in code review = $1k, cost to fix in staging = $10k, cost to fix in production = $100k+ (including breach costs, customer notification, regulatory fines).

Deep Case Study: Enterprise SaaS SAST+DAST Integration

Context: A B2B SaaS company with 100 customers (regulated industry, healthcare data) had a legacy codebase (15 years old, 500k lines of code). No security scanning. Security was handled through annual penetration testing (found 5-10 issues per test). The CTO wanted to shift left (find vulnerabilities earlier).

Month 1: SAST Implementation**

Deployed GitHub CodeQL (free, integrated with their GitHub enterprise). First scan: 283 findings. 41 critical, 89 high, 153 medium/low. The team was overwhelmed. The security lead sampled 20 findings: 15 were legitimate, 5 were false positives. That's a 75% true positive rate (good, but not perfect).

They didn't block on all 283. Instead: (1) Prioritized the 41 critical, (2) Created a backlog ticket for all 283 findings, (3) Committed to fixing 10 critical per week. Month 1 effort: 2 security engineers, 4 product engineers, estimated 300 engineer-hours.

Cost: $30k in labor to clean up existing code.

Month 2-3: Integrate into CI/CD**

Configured CodeQL to run on all commits. Rules: (a) Block merge if critical vulnerability introduced, (b) Warn if high severity, (c) Track all findings. They started with a lenient rule set (medium+ severity) then tightened to high+ after 2 weeks (team was better at avoiding issues).

Month 2: 3 critical vulnerabilities caught before merge (would have reached production). Estimated cost if they'd shipped: $300k (breach + notification + fines).

Month 3: Add DAST**

Integrated OWASP ZAP for DAST. Set it up to run nightly on staging environment. First run: found 12 issues that SAST didn't catch (authentication bypass in a complex multi-step flow, business logic flaw, insecure direct object reference). Estimated risk: another $500k in potential breach costs.

For authentication bypass: took 8 hours to understand and fix. Cost: $1k. If it had reached production and a customer discovered it, remediation cost would have been $50k+.

Month 6: Metrics**

• SAST: 0 critical/high vulnerabilities merged (vs. historical 1-2 per month escaping to staging)
  - DAST: Found 4 business logic flaws in staging (prevented $200k+ potential exposure)
  - New vulnerability introduction rate: down 60% (developers getting better at secure coding as they learn from SAST feedback)
  - Total cost of program: $120k (personnel, tools, integration) + $30k cleanup
  - ROI: Prevented $300k (Month 2) + $500k (Month 3) + ongoing prevention = $800k+ in breach costs avoided in first 6 months

The investment paid for itself 5-6x over.

What made this work:** (1) They didn't expect perfect results immediately, (2) They cleaned up legacy issues before enforcing strict rules on new code, (3) They combined SAST (catch patterns) + DAST (catch logic flaws) + developer training (reduce root causes), (4) They measured impact (vulnerabilities prevented, false positive rate), (5) They had buy-in from engineers (showed them how SAST made their code better)

When SAST Goes Wrong

A startup deployed Semgrep with default rules and blocked all deployments until issues were fixed. Problem: 500+ issues found, most false positives (potential issues that aren't actually exploitable). Team got frustrated and started suppressing warnings indiscriminately. SAST became useless.

Prevention: Start with high-signal rules only. Use tuning, not blocking, initially. Let your security team review findings for the first month. Only add blocking rules after you have <10% false positives. Build confidence in the tool before making it mandatory.

Implementing SAST

False Positives Kill Adoption: Starting with strict rules and thousands of findings will cause your team to suppress warnings and ignore the tool entirely. Start conservative with high-signal rules only. Get buy-in from the team. Only increase strictness after they trust the tool (usually 4-6 weeks in).

Pick a tool:

• Semgrep: Open-source, easy to use, great for patterns, fast
  - GitHub CodeQL: Excellent, free for open-source, requires GitHub, powerful data flow analysis
  - Snyk: Commercial, focuses on dependencies and code, great dashboard
  - Checkmarx: Commercial, enterprise-grade, best for large orgs

Start with open-source (Semgrep or CodeQL). If you outgrow it, upgrade to commercial.

Configure it:

Not all security issues are equal. A hardcoded secret in production code is critical. A potential null pointer dereference is low. Configure severity levels based on your risk appetite.

Integrate into CI/CD:

Add a step in your build that runs SAST. For critical vulnerabilities: fail the build. For high severity: warn but allow merge (with manual approval). For medium/low: log and track.

The CI/CD Integration

stage: security
script:
- semgrep --config=p/security-audit . > semgrep-report.json
- if [ $(jq '.results[] | select(.level=="CRITICAL") | length' semgrep-report.json) -gt 0 ]; then exit 1; fi

Track and fix:

Don't just block and ignore. Track issues in your issue system. Plan to fix them. Measure: how many new vulnerabilities were introduced this month? Trend should be down. How many old ones did you fix? Trend should be up.

Implementing DAST

Start with a simple scanner:

Tools like Burp Suite Community or OWASP ZAP can scan your web app for basic issues. Plug it into your deployment pipeline. This is entry-level but effective.

Create realistic test scenarios:

DAST works better when it has realistic scenarios to test. Can it log in? Can it access protected resources? Can it add items to a cart? DAST needs to understand your app's user flows.

Set up test accounts with different permission levels. Set up test data (products, orders, users). Teach DAST the happy path, then let it try to break it.

Example: E-Commerce DAST

Give DAST two accounts: admin and customer. It should log in as customer, browse products, add to cart, checkout. During this flow, it tries to:

• Access admin pages
  - Manipulate prices
  - Order as a different customer
  - Bypass payment
  - Access other customer data

It finds things like: "I was able to change the order total before payment" or "I could see another customer's address."

Treat findings like bug reports:

DAST finds issues. Triage them. Fix the critical ones before deployment (block release). Log the high/medium ones for next sprint. Track metrics: issues found, issues fixed, time to fix.

Runtime Security

Use WAF (Web Application Firewall):

A WAF watches HTTP traffic and blocks obvious attacks (SQL injection payloads, XSS attempts, etc.). Modern WAFs use ML to detect novel attack patterns.

Configure your WAF to:

• Block known attack signatures
  - Detect unusual request patterns
  - Rate-limit suspicious IPs
  - Block requests that look like scanning

Monitor for anomalies:

Is traffic pattern normal? Are error rates normal? Is someone scanning your application? AI detects anomalies. A normal request is "GET /api/products/123". An anomalous one is "GET /api/products/123'; DROP TABLE users --".

Incident response:

When an attack is detected, respond. Rate-limit the attacker. Block the IP. Notify the team. Collect forensic data. Log what you learned.

When Security Scanning Goes Wrong

Scenario 1: The False Positive Avalanche**

A company deployed SAST with strict default rules and got 2,000+ findings from their codebase. The team spent weeks triaging and quickly realized 80% were false positives (code that looked vulnerable but wasn't actually exploitable). The tool lost credibility. Engineers started suppressing warnings automatically. SAST became worse than useless. It created noise.

Prevention: Start with conservative rules. Run in report-only mode for 2-4 weeks. Tune based on actual false positive rate. Only block on critical findings you've validated as real. Build credibility before enforcing strictly.

Scenario 2: Vulnerability Debt Too Large**

A legacy codebase had 500+ high-severity vulnerabilities found by SAST. The team spent 3 months just fixing them (pulling 2 engineers off product work). The time cost ($150k) exceeded any security benefit. They should have scoped the initial SAST run better.

Prevention: For legacy codebases, run SAST on new code only initially. Create a backlog for legacy issues and fix incrementally. Don't let security debt paralyze development.

Scenario 3: DAST False Positives Breaking Deployments**

DAST reported a "vulnerability" during automated testing: "I can see error messages in the response." The deployment was blocked. On investigation: the error message was expected behavior (API returning 404 for missing resource). DAST had no context about what was expected vs. actual vulnerabilities.

Prevention: Tune DAST to your application. Baseline: run it and document what's expected (certain error messages, certain pages must require auth, etc.). Only flag deviations as vulnerabilities.

What to Do Monday Morning

• Pick a SAST tool (start with Semgrep or CodeQL)
  - Run it against your current codebase locally. What does it find?
  - Review the findings. What's real? What's noise?
  - Triage findings. Fix critical issues immediately. Document others on your backlog.
  - Integrate SAST into your CI/CD pipeline (fail build on critical)
  - Make SAST gate required for all new code merges
  - Track metrics: vulnerabilities found, vulnerabilities fixed, false positive rate
  - Plan DAST implementation (next week)

FAQ

Q: Won't SAST create too many false positives?

A: Yes, initially. Tune the tool. Disable noisy rules. Focus on high-signal findings. After a month, you'll have good signal-to-noise ratio. Create a "security findings" dashboard to make patterns obvious.

Q: How do we know SAST is actually helping?

A: Track two metrics: (1) vulnerabilities found in SAST before production, (2) vulnerabilities found in production. After SAST implementation, metric 2 should drop significantly. Compare the vulnerability severity of bugs caught by SAST vs. bugs found in production. SAST-caught bugs should be more severe (because you're catching them before exploit).

Q: What about dependencies? Are they covered?

A: SAST finds vulnerabilities in your code. For dependency vulnerabilities, use a tool like Snyk or Dependabot. Both use AI to analyze your dependencies and alert when new CVEs are published for your libraries.

Q: Can we use open-source SAST?

A: Absolutely. CodeQL and Semgrep are excellent and free (with commercial options if you want enterprise support). Open-source tools are competitive with paid tools for most organizations.

Q: How long does SAST take to run?

A: Depends on codebase size. For a typical app (100k LOC), Semgrep takes 10-30 seconds. CodeQL is slower (1-5 minutes). Both are acceptable for CI/CD. Run incremental scans during development, full scans nightly.

Q: What if we have too many findings to fix? (The real problem.)

A: Prioritize ruthlessly. Fix critical issues immediately. High issues in the next sprint. Medium/low issues: track but don't block releases. Focus on reducing new issues (don't let them into the codebase) while fixing old ones incrementally. Most teams reach acceptable levels in 2-3 months.

Q: How do we convince the team that security scanning isn't blocking progress?

A: Show metrics. "Before SAST: 1-2 security vulnerabilities found per quarter in production (requiring emergency patches). After SAST: 0 reaching production. We're shipping faster AND safer." Numbers convince people better than speeches.

Q: If security is critical, shouldn't everything be blocking? Why have warning-only rules?**

A: Because false positives destroy adoption. If engineers see 50 warnings every day and 45 are false alarms, they stop paying attention. They'll disable the scanner or suppress warnings automatically. By having strict blocking rules for critical issues and warning-level rules for medium/low, you: (1) protect against truly dangerous vulnerabilities, (2) educate engineers about security anti-patterns, (3) maintain engineer morale (they're not constantly blocked). The enterprise SaaS case study showed this works: start with reporting, move to warnings, then enforce strictly on high/critical after the team understands the tool.

Q: Won't our developers resent security gates slowing them down?**

A: They will if you frame it as "security team blocking engineers." Frame it differently: "These gates catch bugs before they cause customer issues and emergency patches." When developers see "oh, I almost shipped a SQL injection vulnerability," it clicks. Security is another form of code quality, like unit tests. Good engineers want to ship secure code once they understand the cost of not doing so.

Key Insight

Security vulnerabilities are bugs that happen to have security impact. Treat them like bugs: catch them early with SAST, test them with DAST, prevent them at runtime with WAF and monitoring. Integrate security into normal development, not as a separate gate. In three months, you'll move from finding vulnerabilities in production to finding them in code review. That shift reduces breach risk dramatically.

On This Page

Watch the Lecture
Three-Layer Approach
Building Secure Development Process
Implementing SAST
Implementing DAST
Runtime Security
Monday Morning Action
FAQ

Chapter Details

Part ofChapter 4