Web Application Security Fundamentals #06: Secure SDLC & Threat Modeling

Security bukan dapat ditambahkan di akhir. Harus built-in dari design phase. Secure SDLC (Software Development Lifecycle) memastikan setiap tahap development mempertimbangkan security dari awal.

Tujuan Pembelajaran

Anda dapat:

• Menjelaskan fase-fase Secure SDLC (requirements, design, development, testing, deployment)
• Perform threat modeling menggunakan STRIDE atau data flow diagram
• Identify abuse cases dan design defenses
• Integrate security checks di CI/CD pipeline

Secure SDLC Phases

1. Requirements Phase

• Identify security requirements dari awal
• Document asset, threat actor, regulatory compliance
• Example: "Payment endpoint harus encrypt credit card data in transit dan at rest"

2. Design Phase

• Threat modeling (STRIDE, DFD)
• Identify trust boundaries
• Design defense mechanisms
• Security architecture review

Threat Modeling dengan STRIDE:

S - Spoofing: False identity (auth bypass)
T - Tampering: Modify data (injection, CSRF)
R - Repudiation: Deny action (no audit log)
I - Information Disclosure: Expose secret (config leak, error msg)
D - Denial of Service: Unavailable (rate limit missing)
E - Elevation of Privilege: Become admin (broken access control)

3. Development Phase

• Secure coding practices (input validation, output encoding)
• Code review process (peer-based security validation)
• Security unit tests (both positive & negative test cases)
• SAST tools (static analysis finding vulnerabilities)

4. Testing Phase

• Security testing (penetration testing, fuzzing)
• DAST tools (dynamic analysis pada running application)
• Vulnerability scanning
• Threat scenario validation

5. Deployment Phase

• Security checklist (hardening, configuration)
• Secrets management (not hardcoded)
• Infrastructure security (WAF, rate limiting)
• Monitoring & alerting

6. Maintenance Phase

• Vulnerability management (patch management)
• Incident response
• Security monitoring
• Regular assessments

Threat Modeling Example

Asset: Online payment system
Threat Actor: External attacker
Attack Vector: Network

STRIDE Analysis:

• S: Bypass payment authentication → Design: MFA required
• T: Modify transaction amount → Design: Price from DB, not client
• R: Attacker deny payment → Design: Digital signature + audit log
• I: Expose credit card → Design: PCI-DSS compliance, encryption
• D: Payment API down → Design: Rate limit, autoscaling
• E: Become merchant → Design: Multi-factor admin authentication

Secure Coding Checklist

• [ ] Input validation on server-side (not just client-side)
• [ ] Parameterized queries (not string concatenation)
• [ ] Output encoding (context-specific: HTML, URL, JS)
• [ ] Secrets not hardcoded (use secret manager)
• [ ] Least privilege (principle of least authority)
• [ ] Fail secure (default deny, explicit allow)
• [ ] Log security events (without sensitive data)
• [ ] Handle errors gracefully (no stack trace exposure)

CI/CD Security Integration

# .github/workflows/security.yml
name: Security Checks
on: [push, pull_request]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      # SAST - Find vulnerabilities in code
      - uses: github/super-linter@v4
      
      # Dependency check
      - uses: jeremylong/DependencyCheck_Action@main
      
      # Secrets scanning
      - uses: trufflesecurity/trufflehog@main
      
      # Build & run tests
      - run: npm test
      
      # DAST - Run security scanning on running app
      - uses: zaproxy/action-full-scan@v0.3.0

Kesalahan Umum

❌ "Security bisa ditambah nanti"
Fixing security bugs paling mahal di production. Design dulu, implement dulu.

❌ "Threat modeling butuh 3 bulan"
2-3 jam with team members cukup untuk basic threat modeling.

❌ "Developer tidak perlu tahu security"
Secure SDLC = team effort: developers menulis secure code, testers validate.

Kesimpulan

Secure SDLC membuat security sustainable dan scalable. Bukan hanya tergantung security expert, tapi team yang terlatih.

Modul berikutnya (#07) membahas Input Validation sebagai fundamental control.

Referensi

• OWASP: Threat Modeling
• Microsoft: STRIDE Threat Modeling
• OWASP: Secure Coding Practices

Next: #07 - Input Validation & Sanitization