Chapter 7: Application Security & the Security Development Lifecycle (SDL)

Metadata Card

Prerequisites: Chapter 4 (Web Security), Chapter 5 (OS Security), general software development process
Estimated time: 50 minutes
Core difficulty: Advanced
Completion mark: Can explain the stages of SDL, can use the STRIDE model to analyze a system's threats, can distinguish the applicable scenarios of SAST, DAST, and IAST

Your Progress

You've built the defenses of the magic courier routes layer by layer: encryption spells, rune certificate system, web application shields, operating formation isolation, magic conduit monitoring.

But one problem remains: all this defense knowledge has to be learned after each vulnerability appears. One SQL injection is fixed, and another XSS pops up. What you need isn't patching vulnerabilities one by one; you need a systematic approach—thinking about security risks before the magic spells are even written.

Security isn't just adding a WAF in operations; security is an engineering process problem.

Your Task

Understand the Security Development Lifecycle (SDL)—how to embed security into every phase of software development instead of leaving it for last. You'll master threat modeling (STRIDE), security testing (SAST/DAST/IAST), dependency management, and security response planning.

Chapter Layers
Required: SDL seven phases, STRIDE threat modeling (with examples), SAST vs DAST
Optional: SCA (Software Composition Analysis), DevSecOps practices
Advanced: OWASP ASVS standard, Supply Chain Levels for Software Artifacts (SLSA)

Breaking Ground · Tracing the Origin

Problem: Looking back at your experience—almost every vulnerability was discovered after the fact. SQL injection was found after deployment, XSS was discovered when users reported "your page displays weird stuff," SSH port exposure was found by penetration testing.

The problem isn't "not finding vulnerabilities" but "finding them too late." The later a security vulnerability is discovered, the higher the remediation cost:

Requirements phase: 1x cost
Design phase: 6x cost
Implementation phase: 15x cost
Testing phase: 30x cost
Operations phase: 100x+ cost

Core lesson: Security cannot be the last step. It must be a requirement embedded in every phase.

First Piece: SDL (Security Development Lifecycle)

SDL is a methodology introduced by Microsoft in the early 2000s. Its core is embedding security activities into the standard software development flow:

Requirements → Design → Implementation → Verification → Release → Response
     │            │           │              │            │           │
     ├─Security   ├─Threat    ├─SAST         ├─DAST       ├─Security  ├─Vulnerability
     │  requirements│modeling  │              │            │  review   │  response
     ├─Security   ├─Security  ├─Dependency   ├─Pentest    ├─Config    ├─Hotfix
     │  training  │  design   │  check       │            │  baseline │
                  ├─Attack    ├─Secure       ├─Compliance │
                  │  surface  │  coding      │  check     │
                  │  analysis │                         └─Sign + SBOM

Requirements Phase:

Determine security requirements: What security standards must the system meet?
Data classification: What type of data does the system process? PII? Credit card (PCI)?
Security training: Does the development team have sufficient security knowledge?

Design Phase—STRIDE Threat Modeling:

STRIDE is a threat classification model proposed by Microsoft, allowing you to systematically identify security issues during system design.

Category	Threat	Security Attribute Compromised	Example
Spoofing	Identity forgery	Authentication	Forging JWT signatures
Tampering	Data tampering	Integrity	Modifying HTTP request body
Repudiation	Denying actions	Non-repudiation	User denies initiating an action
Information Disclosure	Information disclosure	Confidentiality	Exposing passwords in logs
Denial of Service	Denial of Service	Availability	Frequent requests overwhelming API
Elevation of Privilege	Privilege escalation	Authorization	Regular user performing admin operations

Applying STRIDE to the "Patrol Report System":

System description: A REST API with a frontend displaying patrol reports and a backend connected to PostgreSQL

Data flow diagram (simplified):

User ─→【Frontend】──HTTP──→【API Service】──SQL──→【Database】
                                    │
                                    └──→【Log Service】

STRIDE analysis of each component:

【Frontend】
  S: Attacker forges another user's session
  T: Modifies frontend JS logic
  R: User denies submitting content (needs audit log access)
  I: Session ID exposed in URL
  D: High concurrency requests make frontend unavailable
  E: XSS escalates to other users' permissions on the same site

【API Service】
  S: Forged JWT signature (using weak algorithm "none")
  T: SQL injection to tamper with database
  R: No request logs; user can deny actions
  I: Error messages leak stack traces and table structures
  D: High-concurrency SQL queries exhaust database connection pool
  E: Missing permission checks on API endpoints; can view others' reports

【Database】
  S: Allows passwordless local socket connections
  T: Connected with weak-privilege user, can modify system data
  I: Stores plaintext passwords
  D: Connection limit not set; connections exhausted
  E: Database user has DROP TABLE permissions

【Log Service】
  S: Forged log entries
  T: External writes to logs (log injection)
  R: Logs deleted, can't trace
  I: Logs contain sensitive data (tokens/passwords)
  D: Log files fill the disk

After completing the STRIDE analysis, assign priorities and countermeasures to each threat:

Threat	Severity	Response	Measure
SQL injection	High	Mitigate	Parameterized queries
Unauthorized access	High	Mitigate	Add permission checks
JWT weak algorithm	Medium	Mitigate	Force RS256, validate algorithm whitelist
Logs contain tokens	Medium	Mitigate	Log filter auto-redaction
Plaintext passwords	High	Mitigate	Hash with Argon2
Database DROP permission	Medium	Mitigate	Least-privilege user

Second Piece: Security Testing Tools

SAST (Static Application Security Testing)

SAST performs static analysis at the code level, without running the program. It's like checking ore purity before forging a weapon—you don't need to wait for the final product to find problems:

bash

# SonarQube (community edition supports Java/C#/Python/JS etc.)
sonar-scanner \
  -Dsonar.projectKey=patrol-report \
  -Dsonar.sources=. \
  -Dsonar.host.url=http://localhost:9000

# Bandit (Python-specific)
pip install bandit
bandit -r src/ -f json -o bandit-report.json

# SpotBugs + FindSecBugs (Java)
mvn compile
mvn com.github.spotbugs:spotbugs-maven-plugin:spotbugs

Issues SAST can detect:

Hardcoded passwords and keys
SQL injection (detecting string concatenation)
Insecure random number usage
Dangerous function calls (eval(), exec())
Outdated dependency libraries

DAST (Dynamic Application Security Testing)

DAST tests a running application from the outside. It simulates an attacker's perspective—no need to see your design documents, just knock on the city gates and see which defenses are weak:

bash

# OWASP ZAP (most popular open-source DAST)
docker run -u zap -p 8080:8080 -i ghcr.io/zaproxy/zaproxy \
  zap.sh -port 8080 -host 0.0.0.0

# Passive scan (via proxy listening to traffic)
# Active scan
docker run -v $(pwd):/zap/wrk/:rw -t ghcr.io/zaproxy/zaproxy \
  zap-cli quick-scan --self-contained \
  --start-options '-config api.disablekey=true' \
  http://localhost:8081/supply-app/

Issues DAST can detect:

XSS (reflected and stored)
CSRF
Insecure HTTP headers
SQL injection (triggered via requests)
Directory traversal
Open redirect

SAST vs DAST:

Dimension	SAST	DAST
Source code needed	Yes	No
App running needed	No	Yes
Discovery phase	Implementation	Testing
False positive rate	Higher (needs manual confirmation)	Lower (trigger-based verification)
Coverage	All code paths	Runtime-reachable paths
Configuration complexity	Low	Medium (needs app runtime environment)
Typical tools	SonarQube, Bandit, Checkmarx	OWASP ZAP, Burp Suite, Acunetix

IAST (Interactive Application Security Testing):

Combines the advantages of SAST and DAST—instruments the running application with agents to monitor code execution paths from the inside during DAST scanning.

DAST sends test requests from outside
            │
            ▼
App running ──→ IAST agent captures code execution paths
            │                │
            ▼                ▼
      Return results    Analyze actual code paths executed
                        Flag vulnerable code

IAST's advantage: it knows which code paths were actually executed, so it has far fewer false positives than SAST. It can also detect deep logic that DAST cannot cover (like business logic flaws that DAST can't see).

Third Piece: Dependency Management and Supply Chain Security

Over 90% of a modern application's code comes from third-party dependencies. A compromised dependency is like opening a backdoor in your fortress.

SCA (Software Composition Analysis):

bash

# OWASP Dependency-Check
dependency-check --scan target/ --format HTML

# npm audit (JavaScript dependency check)
npm audit --json

# Trivy (supports multiple languages and container images)
trivy fs src/
trivy image my-app:latest

SCA's core function is checking known vulnerability databases (CVE / NVD)—if your dependency has a CVE-2023-xxxxx, SCA prevents release in CI.

SBOM (Software Bill of Materials):

An SBOM is a manifest listing all components and dependencies in your software. After supply chain attacks (like SolarWinds), SBOMs are already a basic requirement for critical infrastructure.

json

{
  "$schema": "https://raw.githubusercontent.com/CycloneDX/specification/master/schema/bom-1.4.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "components": [
    {
      "type": "library",
      "name": "fastapi",
      "version": "0.104.0",
      "purl": "pkg:pypi/fastapi@0.104.0",
      "licenses": [{"license": {"id": "MIT"}}],
      "hashes": [{"alg": "SHA-256", "content": "..."}]
    }
  ]
}

Generating an SBOM:

bash

# Python project
pip install cyclonedx-bom
cyclonedx-py requirements.txt --output bom.json

# Node.js project
npm install -g @cyclonedx/cyclonedx-npm
cyclonedx-npm --output-file bom.json

Fourth Piece: Vulnerability Response

Even with all precautions, vulnerabilities still happen. The key is response speed when they do.

Vulnerability discovered
   │
   ├── Assess severity (CVSS score)
   │    CVSS 3.1: AccessVector + AttackComplexity + PrivilegesRequired + UserInteraction
   │    → Critical (9.0-10.0) / High (7.0-8.9) / Medium (4.0-6.9) / Low (0.1-3.9)
   │
   ├── Determine fix plan
   │    Critical: Fix within 24 hours
   │    High: Within 1 week
   │    Medium: Fix in next release cycle
   │
   ├── Apply patch / hotfix
   │
   ├── Publish security advisory (if users are affected)
   │
   └── Post-mortem (Root Cause Analysis)
        └── Update SDL process to prevent recurrence

Quickly query known vulnerability info in Python:

python

import requests

# NVD API (National Vulnerability Database)
def get_cve_details(cve_id):
    url = f"https://services.nvd.nist.gov/rest/json/cves/2.0?cveId={cve_id}"
    resp = requests.get(url)
    data = resp.json()
    
    cve = data['vulnerabilities'][0]['cve']
    metrics = cve.get('metrics', {})
    
    # Get CVSS 3.1 score
    cvss_v3 = metrics.get('cvssMetricV31', [{}])[0].get('cvssData', {})
    
    return {
        'id': cve_id,
        'description': cve['descriptions'][0]['value'],
        'severity': cvss_v3.get('baseSeverity'),
        'score': cvss_v3.get('baseScore'),
        'vector': cvss_v3.get('vectorString'),
    }

print(get_cve_details("CVE-2021-44228"))  # Log4Shell

Common Pitfalls

Security testing only done once before release. Security is a continuous process, not a pre-holiday cleanup. Integrate SAST/DAST into CI/CD; check every commit.
Vulnerability scanning equals security testing. Many organizations' "security testing" is just running a vulnerability scanner once. This is far from real security engineering—threat modeling, penetration testing, code review, and dependency analysis all need to be covered.
Thinking cloud providers are responsible for security. Cloud security follows the Shared Responsibility Model. AWS/Azure/GCP are responsible for cloud infrastructure security ("security of the cloud"), you are responsible for applications deployed in the cloud ("security in the cloud").
Dependency scanning done only once. Dependency vulnerabilities are continuously discovered. npm audit or trivy should run on every CI build.
No security fallback plan. When you discover a critical 0-day vulnerability, does your team know what to do first? Is there a playbook? Are key contacts reachable?—These should be pre-defined in the security response plan.
Ignoring business logic vulnerabilities. Scanners can find SQL injection and XSS, but they can't find "users can transfer money to themselves" or "users can return more items than purchased." These require threat modeling, code review, and penetration testing.

Pass Challenges

Warm-up: For an internal system you're familiar with, do a complete STRIDE threat modeling analysis. Identify at least 5 potential threats and rank them by severity.
Challenge: Integrate SAST and dependency checking into a CI pipeline. Using GitHub Actions or GitLab CI, add Bandit (Python) or SonarQube, and Trivy dependency scanning. Configure: Critical/high severity findings block merges (MR).
Observe: Run OWASP ZAP for a passive scan against a locally running web application, read the scan report, find at least one vulnerability and confirm its fix.
Troubleshoot: Your SAST scan report has 100 alerts. You handle the 10 critical ones, but the remaining 90 low-risk alerts fill up subsequent Sprints. How do you create a strategy to gradually eliminate these alerts? (Hint: consider zero-tolerance for new code + staged legacy debt handling)

Traveler's Notes

SDL embeds security into every phase: requirements, design, development, testing, release, response
Threat modeling (STRIDE) is a systematic way to find security issues in the design phase
SAST (static analysis) finds issues at the code stage; DAST (dynamic testing) simulates attacks at runtime
IAST combines the advantages of both, detecting vulnerabilities on actual execution paths
SCA and SBOM address supply chain security—know what dependencies are in your software
The vulnerability response plan must be prepared before vulnerabilities occur

Next Stop Preview

You've learned how to protect the system. One last question: what about the user data stored in the system? Data is not code—it has legal personality and compliance requirements. Next chapter, we look at privacy and data protection—GDPR, data anonymization, data lifecycle management.