CSY203 Week 13 Intermediate

Integrate security tools into your pipeline and prove they work end-to-end.

Secure Software & Web Security

Track your progress through this week's content

Opening Framing: Shift-Left Security

Modern security programs are preventive, not reactive. Instead of finding vulnerabilities late, Secure SDLC practices detect them as code is written and tested. This reduces risk, cost, and incident response time.

This week focuses on integrating security into CI/CD pipelines using SAST, DAST, and SCA, plus DevSecOps practices that make security repeatable and measurable.

Key insight: The safest vulnerabilities are the ones never released.

Building on Prior Knowledge

This capstone week brings together defensive concepts from across CSY203:

  • CSY101 Week 13: Threat modeling principles applied to secure design review and architecture patterns
  • CSY203 Weeks 03-10: All vulnerability classes (auth, SQLi, XSS, etc.) that SAST/DAST tools detect
  • CSY203 Defensive Sections: Secure coding patterns and architecture from previous weeks
  • CSY302 Week 09: IaC security and CI/CD pipeline hardening for cloud deployments

1) Secure SDLC Overview

Security belongs in every phase of development: 

Secure SDLC stages:
1. Requirements  - define security objectives and abuse cases
2. Design        - threat modeling and architecture review
3. Build         - secure coding standards + peer review
4. Test          - SAST/DAST/SCA automation
5. Release       - security gates + monitoring
6. Operate       - patching and continuous improvement

Key insight: Continuous security beats one-time assessments.

2) SAST: Static Application Security Testing

SAST analyzes source code without running it to identify insecure patterns and unsafe APIs. 

Common SAST tools:
- Semgrep (language-agnostic rules)
- CodeQL (GitHub Advanced Security)
- SonarQube (quality + security)
- Checkmarx (enterprise)

SAST best practices: 

- Run on every pull request
- Baseline existing issues
- Fail builds on critical findings
- Track false positives and tune rules

3) DAST: Dynamic Application Security Testing

DAST tests a running application like an attacker would, scanning endpoints and analyzing responses. 

Common DAST tools:
- OWASP ZAP (baseline and active scan)
- Burp Suite CI integration
- Nuclei (template-based scans)

DAST considerations: 

- Run against staging environments
- Authenticate scans for deeper coverage
- Use allowlists to prevent unsafe actions
- Record baseline findings per release

4) SCA: Software Composition Analysis

SCA identifies vulnerable dependencies, licensing risks, and supply-chain exposure in third-party code. 

SCA tools:
- Snyk
- OWASP Dependency-Check
- GitHub Dependabot
- Syft/Grype + SBOMs

SCA best practices: 

- Generate SBOMs
- Block builds on critical CVEs
- Pin and update dependencies regularly
- Monitor dependency confusion risks

5) CI/CD Security Gates

Security gates ensure risky code never ships: 

Security gates:
- Secrets scanning (pre-commit + CI)
- SAST/DAST/SCA thresholds
- Approval workflow for high-risk changes
- Audit logs and release provenance

Key insight: Security gates are enforceable policy, not optional guidance.

Real-World Context: SolarWinds 2020

SolarWinds attackers compromised the build pipeline and injected malicious code into signed updates. Lessons learned: secure build systems, enforce least privilege, monitor pipeline integrity, and validate artifact provenance.

Key insight: CI/CD is a high-value target. Protect the pipeline.

Guided Lab: Secure SDLC Integration

Build a secure CI/CD pipeline with automated security checks.

Step 1: Add SAST

# Add Semgrep or CodeQL to CI
# Run on each pull request
# Fail build on critical findings

Step 2: Add DAST

# Run OWASP ZAP baseline scan
# Target staging URL
# Store reports as build artifacts

Step 3: Add SCA

# Use Snyk or Dependency-Check
# Generate SBOM
# Block build on critical CVEs

Step 4: Enforce Security Gates

# Configure thresholds:
# - Fail on critical vulnerabilities
# - Require approval for high-risk changes
# - Log all security findings

Reflection (mandatory)

  1. Which security check caught the most issues?
  2. What false positives did you encounter?
  3. How would you handle vulnerabilities in legacy code?
  4. Which gate is most important in your pipeline?

Week 13 Outcome Check

By the end of this week, you should be able to:

Final step: update the course index and curriculum documentation.

🎯 Hands-On Labs (Free & Essential)

Integrate security tools into your pipeline and prove they work end-to-end.

🧪 Lab: SAST with Semgrep or CodeQL

What you'll do: Add a SAST workflow to CI, scan every pull request, and fix the top five findings.
Why it matters: SAST catches vulnerabilities before runtime and prevents unsafe code from landing.
Time estimate: 2-3 hours

Start Semgrep →

🧪 Lab: DAST with OWASP ZAP

What you'll do: Run an automated ZAP baseline scan in CI and publish the report as a build artifact.
Why it matters: DAST validates real application behavior and catches runtime issues.
Time estimate: 2-3 hours

Start ZAP Baseline →

🧪 Lab: SCA with Snyk or Dependency-Check

What you'll do: Scan dependencies, generate an SBOM, and remediate critical CVEs.
Why it matters: Third-party code is the #1 source of known vulnerabilities.
Time estimate: 2-3 hours

Start Dependency-Check →

🧪 Lab: Security Gates and Secrets Scanning

What you'll do: Add secret scanning and enforce build failures on high-severity findings.
Why it matters: Secrets in repos and unblocked vulnerabilities create immediate risk.
Time estimate: 2-3 hours

Start Secret Scanning →

💡 Lab Strategy: Start with SAST, then add DAST and SCA, and finish with security gates. This progression builds a complete DevSecOps pipeline: 1,000 total XP, 8-12 hours.

Reading Resources (Free + Authoritative)

Complete the required resources to build your foundation.

Lab: Secure SDLC Integration Project

Goal: Build an end-to-end DevSecOps pipeline with automated security testing and release gates.

Part 1: SAST Integration

  1. Add SAST tool to CI
  2. Baseline existing findings
  3. Fail builds on new critical findings

Part 2: DAST Integration

  1. Run DAST against staging
  2. Publish HTML reports
  3. Automate scheduled scans

Part 3: SCA Integration

  1. Generate SBOM
  2. Block critical CVEs
  3. Automate dependency updates

Part 4: Security Gates

  1. Define thresholds for release
  2. Implement approval workflow
  3. Log findings and actions

Deliverable (submit):

Week 13 Quiz

Test your understanding of Secure SDLC, SAST, DAST, and DevSecOps.

Format: 10 multiple-choice questions. Passing score: 70%. Time: Untimed.

Take Quiz

Checkpoint Questions

  1. What is the difference between SAST and DAST?
  2. Why are SBOMs important for security?
  3. What is a security gate in CI/CD?
  4. How do you handle false positives from security scans?
  5. What risks are unique to CI/CD pipelines?
  6. Why should security testing run on every pull request?

Weekly Reflection

Reflection Prompt (200-300 words):

This week you integrated security into the SDLC. You deployed SAST, DAST, and SCA tools and defined security gates that prevent vulnerable code from reaching production.

Reflect on these questions:

A strong reflection will connect tooling decisions to measurable security outcomes and team workflows.

Verified Resources & Videos

Secure SDLC integration is how security scales. Automated testing, security gates, and continuous monitoring turn security from a bottleneck into a predictable engineering practice. This concludes CSY203—next, update the course index and curriculum documentation.

← Previous: Week 12 Back to Course Overview →