diff --git a/README.md b/README.md
index 7a833ce0..70ccf3e3 100644
--- a/README.md
+++ b/README.md
@@ -1,93 +1,974 @@
# ๐ Introduction to DevSecOps: Principles, Practices & Secure Delivery
-[](#lab-based-learning-experience)
-[](#evaluation-framework)
-[](#lab-based-learning-experience)
-[](#course-roadmap)
+[](#-lab-based-learning-experience)
+[](#-evaluation-framework)
+[](#-lab-based-learning-experience)
+[](#-course-roadmap)
-Welcome to the **Introduction to DevSecOps Course**, where you will learn how to integrate security seamlessly into modern software development and operations.
-This course is designed for bachelor-level students who want to build a strong foundation in DevSecOps culture, practices, and tooling.
-
-Through **hands-on labs and focused lectures**, youโll gain experience with secure coding, automated testing, infrastructure-as-code, container security, and vulnerability management โ the same approaches used by leading engineering teams worldwide.
+Welcome to the **Introduction to DevSecOps Course**, where you will learn to **integrate security seamlessly into modern software development and operations**.
+This course is designed to provide a comprehensive understanding of DevSecOps culture, practices, and tooling for building secure software systems.
+Through **hands-on labs and focused lectures**, you'll gain experience with secure coding, automated testing, infrastructure-as-code security, container hardening, and vulnerability management โ the same approaches used by leading engineering teams worldwide.
---
## ๐ Course Roadmap
-Practical modules designed for incremental skill development:
-
-| # | Module | Key Topics & Technologies |
-|----|-------------------------------------------|------------------------------------------------------------------------------------------|
-| 1 | **Foundations & Secure SDLC** | DevSecOps principles, shift-left culture, OWASP Top 10, secure coding practices |
-| 2 | **Threat Modeling & Security Requirements** | STRIDE, attack surfaces, risk analysis, integrating requirements into agile workflows |
-| 3 | **Secure Git & Secrets Management** | Git security, signed commits, secret scanning, vaulting secrets |
-| 4 | **CI/CD Security & Build Hardening** | Secure pipelines, artifact integrity, quality gates |
-| 5 | **Application Security Testing Basics** | SAST, DAST, SCA, tool integration into pipelines |
-| 6 | **Infrastructure-as-Code Security** | Terraform/Ansible, misconfiguration scanning, policy-as-code |
-| 7 | **Containers & Kubernetes Security** | Docker/K8s fundamentals, image scanning, RBAC, PodSecurity, runtime protection |
-| 8 | **Software Supply Chain Security & SBOM** | Dependency risk, SBOM generation (CycloneDX/SPDX), artifact signing, provenance |
-| 9 | **Monitoring, Compliance & Improvement** | Logging/metrics, KPIs (MTTR, vuln age), GDPR/NIST/ISO basics, maturity models |
-| 10 | **Vulnerability Management & Testing** | Lifecycle (discovery โ triage โ remediation โ reporting), CVSS, SAST/DAST/SCA workflows |
+**10-module intensive course** with practical labs designed for incremental skill development:
+
+> **Note:** Labs 11-12 are **optional bonus labs** for extra credit. Complete them to boost your grade or explore advanced security hardening techniques!
+
+| Lab | Module | Key Topics & Technologies |
+|-----|---------------------------------------------|------------------------------------------------------------------------------------------|
+| 1 | **Foundations & Secure SDLC** | DevSecOps principles, shift-left culture, OWASP Top 10, secure coding practices |
+| 2 | **Threat Modeling & Security Requirements** | STRIDE analysis, attack surfaces, risk assessment, agile security integration |
+| 3 | **Secure Git & Secrets Management** | Git security, signed commits, secret scanning, vault integration, secure workflows |
+| 4 | **CI/CD Security & Build Hardening** | Secure pipelines, artifact integrity, quality gates, SBOM generation, SCA integration |
+| 5 | **Application Security Testing** | SAST, DAST, IAST, security tool integration, automated testing pipelines |
+| 6 | **Infrastructure-as-Code Security** | Terraform/Pulumi/Ansible scanning, misconfiguration detection, policy-as-code |
+| 7 | **Container & Kubernetes Security** | Docker/K8s fundamentals, image scanning, RBAC, PodSecurity, runtime protection |
+| 8 | **Software Supply Chain Security** | Dependency analysis, SBOM (CycloneDX/SPDX), artifact signing, provenance verification |
+| 9 | **Monitoring, Compliance & Improvement** | Security metrics, KPIs (MTTR, vuln age), GDPR/NIST/ISO basics, maturity models |
+| 10 | **Vulnerability Management & Response** | Discovery, triage, remediation workflows, CVSS scoring, security testing orchestration |
+| โ | **๐ Bonus: Reverse Proxy Hardening** | Nginx security headers, TLS termination, rate limiting, timeout configuration |
+| โ | **๐ Bonus: VM-backed Container Isolation** | Kata Containers, runtime comparison, isolation testing, security/performance tradeoffs |
+
+---
+
+## ๐๏ธ Lecture Slide Overview
+
+Index extracted from `lectures/lec*.md`. Each lecture links to its source file and shows an approximate slide count.
+
+
+๐ Lecture 1 - DevSecOps Foundations & Secure SDLC (48 slides)
+
+- ๐ Slide 1 โ ๐ What is DevSecOps?
+- ๐ Slide 2 โ ๐ Why Security in DevOps Matters
+- ๐ Slide 3 โ ๐งโ๐คโ๐ง DevOps Culture & Security Culture
+- ๐ Slide 4 โ ๐ฐ๏ธ The โShift-Leftโ Philosophy
+- ๐ Slide 5 โ ๐ Industry Reports & Trends
+- ๐ Slide 6 โ ๐๏ธ What is the Secure Software Development Life Cycle (Secure SDLC)?
+- ๐ Slide 7 โ ๐ History of SDLC Models
+- ๐ Slide 8 โ ๐งฉ Secure SDLC Phases (Overview)
+- ๐ Slide 9 โ โ๏ธ Traditional SDLC vs Secure SDLC
+- ๐ Slide 10 โ ๐งฎ Key Standards & Frameworks
+- ๐ Slide 11 โ ๐ Introduction to OWASP
+- ๐ Slide 12 โ ๐ Evolution of OWASP Top 10
+- ๐ Slide 13 โ ๐ฅ OWASP Top 10 (2021) Categories
+- ๐ Slide 14 โ โก Real Incidents Mapped to OWASP Top 10
+- ๐ Slide 15 โ ๐ What Are Vulnerabilities?
+- ๐ Slide 16 โ ๐ SQL Injection (SQLi)
+- ๐ Slide 17 โ ๐ Cross-Site Scripting (XSS)
+- ๐ Slide 18 โ ๐ Authentication & Session Vulnerabilities
+- ๐ Slide 19 โ ๐ Cross-Site Request Forgery (CSRF)
+- ๐ Slide 20 โ ๐๏ธ Insecure Deserialization & Logic Bugs
+- ๐ Slide 21 โ โ๏ธ Misconfigurations (Cloud, Servers, Containers)
+- ๐ Slide 22 โ ๐งฉ Case Study Examples for Vulnerabilities
+- ๐ Slide 23 โ ๐ Security as Code
+- ๐ Slide 24 โ โ๏ธ Security Champions & Roles in Teams
+- ๐ Slide 25 โ ๐งช Security by Design
+- ๐ Slide 26 โ ๐ ๏ธ Tooling Ecosystem Overview (High-Level)
+- ๐ Slide 27 โ ๐ Knowledge Sources
+- ๐ Slide 28 โ ๐ป What is Secure Coding?
+- ๐ Slide 29 โ ๐ Secure Coding Guidelines
+- ๐ Slide 30 โ ๐งโ๐ป Common Coding Mistakes
+- ๐ Slide 31 โ ๐ Languages & Secure Coding
+- ๐ Slide 32 โ ๐ Code Review & Pair Programming
+- ๐ Slide 33 โ ๐งญ What is MITRE ATT\&CK?
+- ๐ Slide 34 โ ๐ MITRE ATT\&CK Matrix
+- ๐ Slide 35 โ ๐ ๏ธ Examples of ATT\&CK Techniques
+- ๐ Slide 36 โ ๐ What is MITRE ATLAS?
+- ๐ Slide 37 โ ๐ค AI-Specific Threat Examples
+- ๐ Slide 38 โ ๐ Using ATT\&CK/ATLAS in DevSecOps
+- ๐ Slide 39 โ ๐ข Case Study: Equifax Breach (2017)
+- ๐ Slide 40 โ โ๏ธ Case Study: Capital One Breach (2019)
+- ๐ Slide 41 โ ๐ Case Study: Log4Shell (2021)
+- ๐ Slide 42 โ ๐ณ Case Study: Heartbleed (2014)
+- ๐ Slide 43 โ ๐ก Case Study: SolarWinds (2020)
+- ๐ Slide 44 โ ๐ Recommended Books
+- ๐ Slide 45 โ ๐ Certifications & Training
+- ๐ Slide 46 โ ๐ก๏ธ Maturity Models for DevSecOps
+- ๐ Slide 47 โ ๐ KPIs & Metrics for DevSecOps
+- ๐ Slide 48 โ ๐ Future of DevSecOps
+
+
+
+
+๐ Lecture 2 - Threat Modeling & Security Requirements (30 slides)
+
+- ๐ Slide 1 โ ๐งญ What Is Threat Modeling?
+- ๐ Slide 2 โ ๐ Why It Matters (Outcomes & Fresh Stats)
+- ๐ Slide 3 โ ๐ท๏ธ Assets, Threats, Vulnerabilities, Risk (Clear Terms)
+- ๐ Slide 4 โ ๐งฑ Trust Boundaries & ๐ Data Sensitivity
+- ๐ Slide 5 โ ๐ Attack Surface 101 (What Expands It?)
+- ๐ Slide 6 โ ๐ Where Threat Modeling Fits (SDLC & Agile)
+- ๐ Slide 7 โ ๐บ๏ธ Data Flow Diagrams (DFDs) Essentials
+- ๐ Slide 8 โ ๐งญ Scoping & Assumptions
+- ๐ Slide 9 โ ๐งฉ STRIDE Framework Intro
+- ๐ Slide 10 โ ๐ชช S = Spoofing
+- ๐ Slide 11 โ ๐งช T = Tampering
+- ๐ Slide 12 โ ๐งพ STRIDE Letters in Practice (Setup)
+- ๐ Slide 13 โ ๐งพ R = Repudiation
+- ๐ Slide 14 โ ๐ I = Information Disclosure
+- ๐ Slide 15 โ ๐ D = Denial of Service (DoS)
+- ๐ Slide 16 โ ๐งฐ E = Elevation of Privilege (EoP)
+- ๐ Slide 17 โ ๐ต๏ธโโ๏ธ LINDDUN Overview
+- ๐ Slide 18 โ ๐ LINDDUN Methods & Aids
+- ๐ Slide 19 โ ๐งช LINDDUN Use Cases
+- ๐ Slide 20 โ ๐๏ธ PASTA Overview
+- ๐ Slide 21 โ ๐งช PASTA 7 Stages in Detail
+- ๐ Slide 22 โ ๐ PASTA Case Study
+- ๐ Slide 23 โ ๐ VAST Overview
+- ๐ Slide 24 โ ๐ VAST Integrations & Use Cases
+- ๐ Slide 25 โ ๐น FAIR Overview
+- ๐ Slide 26 โ ๐งฎ FAIR in Practice
+- ๐ Slide 27 โ ๐งฑ Threagile Overview
+- ๐ Slide 28 โ ๐งฐ Threagile Workflow & Use Cases
+- ๐ Slide 29 โ ๐ OWASP Threat Dragon Overview
+- ๐ Slide 30 โ ๐งช Threat Dragon Workflow & Use Cases
+
+
+
+
+๐ Lecture 3 - Secure Git & Secrets Management (40 slides)
+
+- ๐ Slide 1 โ ๐ Brief History of Git
+- ๐ Slide 2 โ ๐ Why Git Security is Important
+- ๐ Slide 3 โ ๐๏ธ Version Control System (VCS) Basics Recap
+- ๐ Slide 4 โ ๐จ Common Git-Related Security Incidents
+- ๐ Slide 5 โ ๐งพ Commit Identity Basics
+- ๐ Slide 6 โ ๐๏ธ Signed Commits Explained
+- ๐ Slide 7 โ ๐ PGP/GPG Keys in Git
+- ๐ Slide 8 โ ๐ชช SSH Signing of Commits
+- ๐ Slide 9 โ ๐ก๏ธ Verification of Commits in Platforms
+- ๐ Slide 10 โ โ๏ธ GPG vs SSH Commit Signing
+- ๐ Slide 11 โ ๐ข Organizational Enforcement of Signed Commits
+- ๐ Slide 12 โ โ What Are โSecretsโ?
+- ๐ Slide 13 โ ๐ How Secrets Leak into Git Repositories
+- ๐ Slide 14 โ ๐ Examples of Leaked Secrets in Public Repos
+- ๐ Slide 15 โ ๐ Impact of Secret Leaks
+- ๐ Slide 16 โ โ ๏ธ Why Deleting from Git History Is Not Enough
+- ๐ Slide 17 โ ๐ Manual vs Automated Secret Scanning
+- ๐ Slide 18 โ ๐ ๏ธ GitGuardian for Secret Scanning
+- ๐ Slide 19 โ ๐ ๏ธ TruffleHog for Secret Scanning
+- ๐ Slide 20 โ ๐ ๏ธ Gitleaks for Secret Scanning
+- ๐ Slide 21 โ ๐ฆ Built-in Scanners in Git Platforms
+- ๐ Slide 22 โ ๐ Stats & Trends of Secret Leaks
+- ๐ Slide 23 โ ๐งฐ History of Secret Storage
+- ๐ Slide 24 โ ๐ Environment Variables for Secrets
+- ๐ Slide 25 โ ๐ Config Files & .gitignore
+- ๐ Slide 26 โ ๐ก๏ธ Secrets Vaulting Tools Overview
+- ๐ Slide 27 โ โก Secret Rotation & Lifecycle Management
+- ๐ Slide 28 โ ๐งฉ Integrating Vaults with CI/CD Pipelines
+- ๐ Slide 29 โ ๐ Dynamic vs Static Secrets
+- ๐ Slide 30 โ ๐งน Cleaning Git History of Secrets
+- ๐ Slide 31 โ ๐ฆ Pre-Commit Hooks for Preventing Leaks
+- ๐ Slide 32 โ ๐ ๏ธ Secrets Scanning in CI/CD Pipelines
+- ๐ Slide 33 โ ๐ธ๏ธ Zero-Trust Approach to Git Security
+- ๐ Slide 34 โ ๐ Emerging Trends: P2P & Blockchain Git
+- ๐ Slide 35 โ ๐ฎ Future of Git Security & Secret Management
+- ๐ Slide 36 โ ๐ข Case Study: GitHub Token Leaks
+- ๐ Slide 37 โ ๐จ Case Study: Supply-Chain Attacks via Repos
+- ๐ Slide 38 โ ๐ Industry Standards & Compliance Requirements
+- ๐ Slide 39 โ ๐ Best Practices Checklist for Developers
+- ๐ Slide 40 โ ๐ฏ Summary & Hands-On Practice
+
+
+
+
+๐ Lecture 4 - CI/CD Security & Build Hardening (40 slides)
+
+- ๐ Slide 1 โ ๐๏ธ What is CI/CD? (Continuous Integration/Continuous Deployment)
+- ๐ Slide 2 โ ๐ Evolution of CI/CD: From Manual Builds to Modern Pipelines
+- ๐ Slide 3 โ ๐๏ธ CI/CD Architecture Components & Trust Boundaries
+- ๐ Slide 4 โ โ๏ธ Popular CI/CD Platforms Overview (Jenkins, GitHub Actions, GitLab CI, Azure DevOps)
+- ๐ Slide 5 โ ๐จ Why CI/CD Pipelines Became High-Value Attack Targets
+- ๐ Slide 6 โ ๐ The OWASP Top 10 CI/CD Security Risks (2024)
+- ๐ Slide 7 โ ๐ Supply Chain Attacks via CI/CD: Famous Case Studies
+- ๐ Slide 8 โ ๐ Authentication & Authorization in CI/CD Pipelines
+- ๐ Slide 9 โ ๐ญ Role-Based Access Control (RBAC) for Pipeline Resources
+- ๐ Slide 10 โ ๐ Service Account Security & Credential Management
+- ๐ Slide 11 โ ๐ก๏ธ Multi-Factor Authentication (MFA) for Pipeline Access
+- ๐ Slide 12 โ โ๏ธ Principle of Least Privilege in CI/CD Workflows
+- ๐ Slide 13 โ ๐ธ๏ธ Zero-Trust Approaches to Pipeline Security
+- ๐ Slide 14 โ ๐ Infrastructure-as-Code (IaC) for Pipeline Configuration
+- ๐ Slide 15 โ ๐ Securing Pipeline Configuration Files (YAML/JSON Security)
+- ๐ Slide 16 โ ๐ฐ Build Environment Isolation & Sandboxing
+- ๐ Slide 17 โ ๐ซ Preventing Poisoned Pipeline Execution (PPE) Attacks
+- ๐ Slide 18 โ ๐ Network Segmentation for CI/CD Infrastructure
+- ๐ Slide 19 โ ๐ Secure Artifact Storage & Repository Management
+- ๐ Slide 20 โ ๐งน Container Security in Build Environments
+- ๐ Slide 21 โ โฑ๏ธ Resource Limits & Denial of Service Prevention
+- ๐ Slide 22 โ ๐ฆ Secure Artifact Creation & Packaging
+- ๐ Slide 23 โ ๐ Digital Signing & Verification of Build Artifacts
+- ๐ Slide 24 โ ๐ Software Bill of Materials (SBOM) Generation
+- ๐ Slide 25 โ ๐ท๏ธ Container Image Signing with Cosign/Notary
+- ๐ Slide 26 โ ๐งช Build Reproducibility & Deterministic Builds
+- ๐ Slide 27 โ ๐ Integrity Checks: Checksums, Hashes, and Verification
+- ๐ Slide 28 โ ๐ Artifact Provenance & Supply Chain Transparency
+- ๐ Slide 29 โ ๐ฆ Quality Gates: Definition and Implementation
+- ๐ Slide 30 โ ๐ Security Gates vs. Quality Gates in CI/CD
+- ๐ Slide 31 โ โก Automated Security Controls in Pipelines
+- ๐ Slide 32 โ ๐ Policy-as-Code for Build Security
+- ๐ Slide 33 โ ๐ Breaking Builds on Security Policy Violations
+- ๐ Slide 34 โ ๐ Security Metrics & KPIs for Pipeline Health
+- ๐ Slide 35 โ ๐ Third-Party Dependency Security Risks
+- ๐ Slide 36 โ ๐ Software Composition Analysis (SCA) in Build Pipelines
+- ๐ Slide 37 โ โ ๏ธ Vulnerability Scanning of Dependencies
+- ๐ Slide 38 โ ๐ License Compliance Scanning & Management
+- ๐ Slide 39 โ ๐ Automated Dependency Updates & Patch Management
+- ๐ Slide 40 โ ๐ธ๏ธ Dependency Confusion & Typosquatting Prevention
+
+
+
+
+๐ Lecture 5 - Application Security Testing Basics (26 slides)
+
+- ๐ Slide 1 โ ๐ What is Application Security Testing? (AST Overview)
+- ๐ Slide 2 โ ๐ Evolution of Application Security Testing
+- ๐ Slide 3 โ ๐ฏ Types of Security Vulnerabilities We're Testing For
+- ๐ Slide 4 โ โ๏ธ Static vs. Dynamic vs. Interactive Testing Comparison
+- ๐ Slide 5 โ ๐งฉ The Testing Pyramid for Application Security
+- ๐ Slide 6 โ ๐ฌ Deep Dive into SAST: Definition and Core Concepts
+- ๐ Slide 7 โ ๐ ๏ธ Popular SAST Tools and Platform Overview
+- ๐ Slide 8 โ โก SAST Strengths and Limitations
+- ๐ Slide 9 โ ๐ฏ SAST Implementation Best Practices
+- ๐ Slide 10 โ ๐ง Hands-on SAST: Tool Configuration and Output Analysis
+- ๐ Slide 11 โ ๐ Deep Dive into DAST: Black-box Runtime Testing
+- ๐ Slide 12 โ ๐ ๏ธ Popular DAST Tools and Platform Overview
+- ๐ Slide 13 โ โก DAST Strengths and Limitations
+- ๐ Slide 14 โ ๐ฏ DAST Implementation Best Practices
+- ๐ Slide 15 โ ๐ง Hands-on DAST: OWASP ZAP Configuration and Testing
+- ๐ Slide 16 โ ๐งฌ Deep Dive into IAST: Runtime Instrumentation Testing
+- ๐ Slide 17 โ ๐ ๏ธ Popular IAST Tools and Platform Overview
+- ๐ Slide 18 โ โก IAST Strengths and Limitations
+- ๐ Slide 19 โ ๐ฏ IAST Implementation Best Practices
+- ๐ Slide 20 โ ๐ง Hands-on IAST: Agent-based Testing Setup
+- ๐ Slide 21 โ ๐ Integrating Security Testing into CI/CD Pipelines
+- ๐ Slide 22 โ ๐ Tool Orchestration and Security Dashboard Creation
+- ๐ Slide 23 โ โ๏ธ Balancing Security and Development Velocity
+- ๐ Slide 24 โ ๐ Advanced Integration Patterns and GitOps
+- ๐ Slide 25 โ ๐ Modern Trends and Future of Application Security Testing
+- ๐ Slide 26 โ ๐ฏ Summary & Key Takeaways
+
+
+
+
+๐ Lecture 6 - Infrastructure-as-Code Security (19 slides)
+
+- ๐ Slide 1 โ ๐ What is Infrastructure-as-Code (IaC)?
+- ๐ Slide 2 โ ๐จ Why IaC Security Matters
+- ๐ Slide 3 โ ๐ IaC Tool Landscape Overview
+- ๐ Slide 4 โ ๐ Common IaC Security Risks
+- ๐ Slide 5 โ ๐งญ IaC in the DevSecOps Pipeline
+- ๐ Slide 6 โ ๐๏ธ Terraform Deep Dive & Security Concerns
+- ๐ Slide 7 โ ๐ Managing Secrets in Terraform
+- ๐ Slide 8 โ ๐ก๏ธ Terraform Security Best Practices
+- ๐ Slide 9 โ ๐ป Hands-On: Secure Terraform Workflow
+- ๐ Slide 10 โ ๐ Pulumi Overview & Security Model
+- ๐ Slide 11 โ ๐งฉ Pulumi Policy-as-Code (CrossGuard)
+- ๐ Slide 12 โ ๐ป Hands-On: Secure Pulumi Deployment
+- ๐ Slide 13 โ โ๏ธ Ansible Overview & Security Challenges
+- ๐ Slide 14 โ ๐ก๏ธ Ansible Security Best Practices
+- ๐ Slide 15 โ ๐ป Hands-On: Secure Ansible Playbook
+- ๐ Slide 16 โ ๐ IaC Security Scanning Tools Deep Dive
+- ๐ Slide 17 โ ๐ Policy-as-Code Frameworks
+- ๐ Slide 18 โ โ๏ธ Compliance & Security Standards
+- ๐ Slide 19 โ ๐ฏ Case Studies, Future Trends & Summary
+
+
+
+
+๐ Lecture 7 - Container & Kubernetes Security (18 slides)
+
+- ๐ Slide 1 โ ๐ณ Container Technology Overview & Evolution
+- ๐ Slide 2 โ ๐๏ธ Docker Architecture & Security Model
+- ๐ Slide 3 โ ๐ฆ Container Images & Layered Filesystem
+- ๐ Slide 4 โ ๐ Container Image Security Scanning
+- ๐ Slide 5 โ ๐ก๏ธ Container Runtime Security
+- ๐ Slide 6 โ ๐ Secrets Management in Containers
+- ๐ Slide 7 โ ๐ Container Compliance & Hardening
+- ๐ Slide 8 โ โธ๏ธ Kubernetes Architecture & Components
+- ๐ Slide 9 โ ๐ Kubernetes Authentication & Authorization
+- ๐ Slide 10 โ ๐ช Kubernetes Admission Control & Policies
+- ๐ Slide 11 โ ๐ก๏ธ Pod Security & Isolation
+- ๐ Slide 12 โ ๐ Kubernetes Secrets & ConfigMaps
+- ๐ Slide 13 โ ๐ Kubernetes Auditing & Monitoring
+- ๐ Slide 14 โ ๐ Kubernetes Security Scanning
+- ๐ Slide 15 โ ๐ Kubernetes Network Security
+- ๐ Slide 16 โ ๐๏ธ Secure Kubernetes CI/CD Pipelines
+- ๐ Slide 17 โ ๐จ Kubernetes Attack Scenarios & Defense
+- ๐ Slide 18 โ ๐ฎ Future Trends & Security Checklist
+
+
+
+
+๐ Lecture 8 - Software Supply Chain Security (20 slides)
+
+- ๐ Slide 1 โ ๐ What is Software Supply Chain Security?
+- ๐ Slide 2 โ ๐ฅ Famous Supply Chain Breaches & Incidents
+- ๐ Slide 3 โ ๐ฏ Supply Chain Attack Vectors
+- ๐ Slide 4 โ ๐ก๏ธ Supply Chain Security Frameworks
+- ๐ Slide 5 โ ๐ Supply Chain Security in DevSecOps Pipeline
+- ๐ Slide 6 โ ๐ Software Composition Analysis (SCA) Deep Dive
+- ๐ Slide 7 โ ๐๏ธ Vulnerability Databases & Tracking
+- ๐ Slide 8 โ ๐ ๏ธ Dependency Management Best Practices
+- ๐ Slide 9 โ ๐ป Hands-On: Advanced SCA Tools
+- ๐ Slide 10 โ ๐ SBOM Formats: SPDX vs CycloneDX Deep Dive
+- ๐ Slide 11 โ ๐ SBOM Consumption & Auditing
+- ๐ Slide 12 โ ๐ SBOM Diff Analysis & Change Tracking
+- ๐ Slide 13 โ ๐ป Hands-On: SBOM-Driven Vulnerability Analysis
+- ๐ Slide 14 โ โ๏ธ Code Signing & Artifact Integrity
+- ๐ Slide 15 โ ๐ Sigstore: Modern Signing Revolution
+- ๐ Slide 16 โ ๐ Provenance & Build Attestations
+- ๐ Slide 17 โ ๐ป Hands-On: Signing & Provenance Verification
+- ๐ Slide 18 โ ๐ฏ SLSA Framework Implementation
+- ๐ Slide 19 โ ๐ Securing the Build Pipeline
+- ๐ Slide 20 โ ๐ Runtime Supply Chain Security
+
+
+
+
+๐ Lecture 9 - Monitoring, Compliance & Improvement (23 slides)
+
+- ๐ Slide 1 โ ๐ Security Monitoring in DevSecOps
+- ๐ Slide 2 โ ๐ What to Monitor: Logs, Metrics, Traces
+- ๐ Slide 3 โ ๐ ๏ธ Security Monitoring Tools & Platforms
+- ๐ Slide 4 โ ๐ Security Metrics vs Vanity Metrics
+- ๐ Slide 5 โ โฑ๏ธ Time-Based KPIs: MTTD, MTTR, MTTA
+- ๐ Slide 6 โ ๐ Program Health KPIs
+- ๐ Slide 7 โ ๐ป Hands-On: Building Security Dashboards
+- ๐ Slide 8 โ โ๏ธ Compliance Basics for Developers
+- ๐ Slide 9 โ ๐ช๐บ GDPR Essentials
+- ๐ Slide 10 โ ๐๏ธ NIST Cybersecurity Framework
+- ๐ Slide 11 โ ๐ ISO 27001 Basics
+- ๐ Slide 12 โ ๐ณ Other Key Frameworks (Quick Overview)
+- ๐ Slide 8 โ โ๏ธ Compliance Basics for Developers
+- ๐ Slide 9 โ ๐ช๐บ GDPR (General Data Protection Regulation)
+- ๐ Slide 10 โ ๐๏ธ NIST Cybersecurity Framework
+- ๐ Slide 11 โ ๐ ISO 27001 Information Security Management
+- ๐ Slide 12 โ ๐ณ Other Key Frameworks (Overview)
+- ๐ Slide 13 โ ๐ฏ Security Maturity Model Concepts
+- ๐ Slide 14 โ ๐ฆ
OWASP SAMM (Software Assurance Maturity Model)
+- ๐ Slide 15 โ ๐ BSIMM (Building Security In Maturity Model)
+- ๐ Slide 16 โ ๐ DevSecOps Maturity Assessment
+- ๐ Slide 17 โ ๐ Feedback Loops & Security Improvement
+- ๐ Slide 18 โ ๐ค Compliance as Code & Automation
+
+
+
+
+๐ Lecture 10 - Vulnerability Management & Response (17 slides)
+
+- ๐ Slide 1 โ ๐ Vulnerability Discovery Methods
+- ๐ Slide 2 โ ๐ ๏ธ Security Testing Orchestration
+- ๐ Slide 3 โ ๐ Centralized Vulnerability Management
+- ๐ Slide 4 โ ๐ CVSS Scoring Deep Dive
+- ๐ Slide 5 โ โก Advanced Prioritization: EPSS, KEV, SSVC
+- ๐ Slide 6 โ ๐ฏ Risk-Based Prioritization
+- ๐ Slide 7 โ ๐จ Triage Workflows & Decisions
+- ๐ Slide 8 โ ๐ง Remediation Strategies
+- ๐ Slide 9 โ โฑ๏ธ SLA Management & Tracking
+- ๐ Slide 10 โ ๐ Remediation Tracking & Verification
+- ๐ Slide 11 โ ๐ป Hands-On: Automated Remediation Pipelines
+- ๐ Slide 12 โ ๐ Vulnerability Lifecycle Overview
+- ๐ Slide 13 โ ๐ Backlog Management & Health
+- ๐ Slide 14 โ โก Velocity & Continuous Improvement
+- ๐ Slide 15 โ ๐ฅ Incident Response Framework
+- ๐ Slide 16 โ ๐ฅ IR Team Roles & Escalation
+- ๐ Slide 17 โ ๐ Blameless Post-Mortems
+
+
---
-## ๐ผ Module Flow Diagram
+## ๐บ๏ธ DevSecOps Learning Journey
+
+
+๐ณ View Skill Tree Structure
+
+```mermaid
+graph TB
+ ROOT[๐ DevSecOps Mastery]
+
+ %% Foundation Branch
+ ROOT --- FOUND[๐๏ธ Foundation]
+ FOUND --- A[๐ Lab 1: DevSecOps Intro
โข Secure SDLC
โข Shift-Left Culture
โข OWASP Top 10]
+ FOUND --- B[๐ฏ Lab 2: Threat Modeling
โข STRIDE Analysis
โข Attack Surfaces
โข Risk Assessment]
+
+ %% Development Branch
+ ROOT --- DEV[๐จโ๐ป Development]
+ DEV --- C[๐ Lab 3: Secure Git
โข Signed Commits
โข Secrets Management
โข Secure Workflows]
+ DEV --- D[๐ Lab 4: CI/CD Security
โข Secure Pipelines
โข Build Hardening
โข Quality Gates]
+
+ %% Testing Branch
+ ROOT --- TEST[๐งช Testing]
+ TEST --- E[๐ Lab 5: AppSec Testing
โข SAST/DAST/SCA
โข Tool Integration
โข Automated Security]
+ TEST --- J[๐ฏ Lab 10: Vuln Management
โข Discovery & Triage
โข CVSS Scoring
โข Remediation Workflows]
+
+ %% Infrastructure Branch
+ ROOT --- INFRA[๐๏ธ Infrastructure]
+ INFRA --- F[โ๏ธ Lab 6: IaC Security
โข Terraform/Ansible
โข Config Scanning
โข Policy as Code]
+ INFRA --- G[๐ฆ Lab 7: Container Security
โข Docker/K8s Security
โข Image Scanning
โข Runtime Protection]
+
+ %% Supply Chain Branch
+ ROOT --- SUPPLY[๐ Supply Chain]
+ SUPPLY --- H[๐ Lab 8: SBOM & Provenance
โข Dependency Analysis
โข Artifact Signing
โข Supply Chain Security]
+
+ %% Operations Branch
+ ROOT --- OPS[๐ Operations]
+ OPS --- I[๐ Lab 9: Monitoring & Compliance
โข Security Metrics
โข GDPR/NIST/ISO
โข Maturity Models]
+
+ %% Styling
+ classDef rootStyle fill:#1a1a1a,stroke:#ffffff,stroke-width:3px,color:#ffffff
+ classDef branchStyle fill:#2c3e50,stroke:#e74c3c,stroke-width:2px,color:#ffffff
+ classDef foundationModule fill:#fdf2e9,stroke:#e67e22,stroke-width:2px,color:#2c3e50
+ classDef devModule fill:#eaf2f8,stroke:#3498db,stroke-width:2px,color:#2c3e50
+ classDef testModule fill:#f4ecf7,stroke:#9b59b6,stroke-width:2px,color:#2c3e50
+ classDef infraModule fill:#e8f8f5,stroke:#16a085,stroke-width:2px,color:#2c3e50
+ classDef supplyModule fill:#fdedec,stroke:#e74c3c,stroke-width:2px,color:#2c3e50
+ classDef opsModule fill:#fff3cd,stroke:#f1c40f,stroke-width:2px,color:#2c3e50
+
+ class ROOT rootStyle
+ class FOUND,DEV,TEST,INFRA,SUPPLY,OPS branchStyle
+ class A,B foundationModule
+ class C,D devModule
+ class E,J testModule
+ class F,G infraModule
+ class H supplyModule
+ class I opsModule
+```
+
+
+
+
+๐๏ธ View Security Integration Layers
```mermaid
-flowchart TD
- A[Foundations & Secure SDLC] --> B[Threat Modeling]
- B --> C[Secure Git & Secrets Management]
- C --> D[CI/CD Security]
- D --> E[AppSec Testing Basics]
- E --> F[IaC Security]
- F --> G[Containers & K8s Security]
- G --> H[Supply Chain & SBOM]
- H --> I[Monitoring & Compliance]
- I --> J[Vulnerability Management & Testing]
+flowchart LR
+ subgraph "๐ Supply Chain & Operations"
+ direction LR
+ H[๐ Lab 8: SBOM & Provenance
Dependency Security]
+ I[๐ Lab 9: Monitoring
Security Metrics]
+ end
+
+ subgraph "๐๏ธ Infrastructure Security"
+ direction LR
+ F[โ๏ธ Lab 6: IaC Security
Config Management]
+ G[๐ฆ Lab 7: Container Security
Runtime Protection]
+ end
+
+ subgraph "๐งช Security Testing"
+ direction LR
+ E[๐ Lab 5: AppSec Testing
SAST/DAST/SCA]
+ J[๐ฏ Lab 10: Vuln Management
Remediation Workflows]
+ end
+
+ subgraph "๐จโ๐ป Secure Development"
+ direction LR
+ C[๐ Lab 3: Secure Git
Secrets & Signing]
+ D[๐ Lab 4: CI/CD Security
Pipeline Hardening]
+ end
+
+ subgraph "๐๏ธ Foundation Layer"
+ direction LR
+ A[๐ Lab 1: DevSecOps
Principles & SDLC]
+ B[๐ฏ Lab 2: Threat Modeling
Risk Analysis]
+ end
+
+ A --> C
+ B --> C
+ C --> E
+ D --> E
+ D --> F
+ E --> F
+ F --> G
+ G --> H
+ H --> I
+ E --> J
+ J --> I
+
+ classDef foundation fill:#fdf2e9,stroke:#e67e22,stroke-width:3px,color:#2c3e50
+ classDef development fill:#eaf2f8,stroke:#3498db,stroke-width:3px,color:#2c3e50
+ classDef testing fill:#f4ecf7,stroke:#9b59b6,stroke-width:3px,color:#2c3e50
+ classDef infrastructure fill:#e8f8f5,stroke:#16a085,stroke-width:3px,color:#2c3e50
+ classDef operations fill:#fdedec,stroke:#e74c3c,stroke-width:3px,color:#2c3e50
+
+ class A,B foundation
+ class C,D development
+ class E,J testing
+ class F,G infrastructure
+ class H,I operations
```
+
+
---
## ๐ Lab-Based Learning Experience
-**80% of your grade comes from hands-on labs** โ each one builds practical security skills:
+**80% of your grade comes from 10 hands-on labs** โ each designed to build real-world security skills.
+
+### Lab Structure
+
+* **Task-oriented security challenges** with clear objectives and deliverables
+* **Safe environments** using containers, local VMs, or cloud platforms
+* **Real-world workflows** mirroring professional DevSecOps practices
+* **Progressive difficulty** building on previous security concepts
+* **Industry-standard tools** used in production environments
+
+### Lab Overview
+
+
+๐ View All Lab Topics
+
+**Required Labs (1-10):**
+
+1. **Foundations & Secure SDLC** โ DevSecOps principles, OWASP Top 10, shift-left security
+2. **Threat Modeling** โ STRIDE analysis, attack surface mapping, risk assessment
+3. **Secure Git** โ Signed commits, secret scanning, secure collaboration workflows
+4. **CI/CD Security** โ Pipeline hardening, artifact integrity, quality gates, SBOM
+5. **AppSec Testing** โ SAST/DAST/SCA integration, automated security testing
+6. **IaC Security** โ Terraform/Pulumi/Ansible scanning, policy-as-code enforcement
+7. **Container Security** โ Docker/Kubernetes hardening, image scanning, runtime protection
+8. **Supply Chain** โ SBOM generation, dependency analysis, artifact signing
+9. **Monitoring & Compliance** โ Security metrics, GDPR/NIST/ISO basics, maturity assessment
+10. **Vulnerability Management** โ Discovery, triage, remediation, CVSS scoring
+
+**Bonus Labs (Optional):**
+
+11. **๐ Nginx Reverse Proxy Hardening** โ Security headers (XFO, XCTO, HSTS, CSP), TLS configuration, rate limiting, timeout management
+12. **๐ Kata Containers Sandboxing** โ VM-backed isolation, runtime comparison (runc vs kata), performance analysis, security tradeoffs
+
+> **Bonus Lab Benefits:**
+> - Extra credit toward final grade
+> - Advanced security hardening techniques
+> - Real-world operational security skills
+> - Optional but highly recommended for security professionals
+
+
+
+### Submission Workflow
+
+```mermaid
+graph LR
+ A[Fork Repo] --> B[Create Branch]
+ B --> C[Complete Tasks]
+ C --> D[Push to Fork]
+ D --> E[Open PR to Course Repo]
+ E --> F[Submit PR Link via Moodle]
+ F --> G[Receive Feedback]
+
+ style A fill:#e8f8f5,stroke:#16a085,color:#2c3e50
+ style B fill:#e8f8f5,stroke:#16a085,color:#2c3e50
+ style C fill:#fef9e7,stroke:#f39c12,color:#2c3e50
+ style D fill:#eaf2f8,stroke:#3498db,color:#2c3e50
+ style E fill:#f4ecf7,stroke:#9b59b6,color:#2c3e50
+ style F fill:#fdedec,stroke:#e74c3c,color:#2c3e50
+ style G fill:#e8f6f3,stroke:#1abc9c,color:#2c3e50
+```
+
+
+๐ Detailed Submission Process
+
+**Step-by-Step Guide:**
+
+1. **Fork the course repository** to your GitHub account
+
+2. **Clone your fork locally:**
+ ```bash
+ git clone https://github.com/YOUR_USERNAME/REPO_NAME.git
+ cd REPO_NAME
+ ```
+
+3. **Create and work on your lab branch:**
+ ```bash
+ git switch -c feature/labX
+ # Complete lab tasks, create submission files
+ git add labs/submissionX.md
+ git commit -m "docs: add labX submission"
+ git push -u origin feature/labX
+ ```
+
+4. **Open PR from your fork โ course repository main branch**
+ - Navigate to the course repository on GitHub
+ - Click "New Pull Request"
+ - Select: `base: course-repo/main` โ `compare: your-fork/feature/labX`
+ - Fill in the PR template with task completion checklist
+
+5. **Copy the PR URL and submit via Moodle before deadline**
+
+**โ ๏ธ Important:** PRs must target the **course repository's main branch**, not your fork's main branch.
+
+
+
+### Grading Policy
+
+
+๐ฏ Lab Grading Breakdown
+
+**Each lab (1-10) is worth 8 points:**
+
+* **Perfect Submissions (8/8):**
+ - All tasks completed with thorough security analysis
+ - Clear documentation and understanding demonstrated
+ - Security tools configured and used correctly
+ - Submitted on time
+ - **Benefit:** Counts toward exam exemption
+
+* **Strong Submissions (6-7/8):**
+ - All tasks completed with minor issues
+ - Good security analysis and documentation
+ - Minor improvements needed
+
+* **Passing Submissions (5-6/8):**
+ - Core security tasks completed
+ - Basic documentation present
+ - Some areas need improvement
+
+* **Below Passing (<5/8):**
+ - Incomplete security analysis
+ - Insufficient documentation
+ - Major gaps in understanding
-1. **Lab Structure**
+**Bonus Labs (11-12):**
+- Worth **10 points each**
+- **Maximum 20 bonus points total** (capped to maintain grade scale)
+- **Can replace the exam requirement** if both completed
+- Same quality standards as required labs
+- No penalty for not completing them
- * Realistic, task-oriented challenges with clear goals
- * Safe environments using containers, local VMs, or cloud credits
+**Late Submissions (Required Labs Only):**
+- Maximum score: 5/8
+- Accepted within 1 week after deadline
+- No credit after 1 week
-2. **Submission Workflow**
+
- * Fork course repository โ Create lab branch โ Complete tasks
- * Push to fork โ Open Pull Request โ Receive feedback & evaluation
+
+๐ Exam Exemption Policy
-3. **Grading Advantage**
+**Path 1: Bonus Labs Replace Exam**
- * **Perfect Labs (10/10)**: Exam exemption + bonus points toward A
- * **On-Time (โฅ6/10)**: Guaranteed pass (C or higher)
- * **Late**: Maximum 6/10
+Complete **both Lab 11 AND Lab 12** with passing scores:
+- No exam requirement
+- Bonus points replace the 20 exam points
+- Must still complete all 10 required labs
+
+**Path 2: Maximum Score Strategy**
+
+Combine all components:
+- Complete 10 required labs (80 pts)
+- Take exam (20 pts)
+- Complete bonus labs (20 pts)
+- Total: 120 pts available (capped at 100 for final grade)
+
+**Important Notes:**
+- **Completing only 10 labs = 80% maximum** (B grade)
+- Need exam OR bonus labs to reach A grade
+- Bonus labs provide safety buffer for required lab scores
+- Late required lab submissions max out at 5/8 points
+
+
---
## ๐ Evaluation Framework
-*Transparent assessment for skill validation*
-
### Grade Composition
-* Labs (10 ร 8 points each): **80%**
-* Final Exam (comprehensive): **20%**
+| Component | Points | Details |
+|-----------|--------|---------|
+| **Required Labs (1-10)** | 80 points | 10 labs ร 8 points each (80% of grade) |
+| **Final Exam** | 20 points | Comprehensive assessment OR skip if both bonus labs completed |
+| **Bonus Labs (11-12)** | +20 points max | Lab 11: 10 pts, Lab 12: 10 pts (capped at 20 total) |
+| **Total Base** | 100 points | Required to pass: 60+ points |
+| **Maximum Possible** | 120 points | With bonus labs (capped at 100% for final grade) |
### Performance Tiers
-* **A (90-100)**: Mastery with innovative solutions
-* **B (75-89)**: Consistent completion, minor improvement needed
-* **C (60-74)**: Basic competency, some gaps
-* **D (0-59)**: Fundamental gaps, re-attempt required
+
+๐ Grading Scale
+
+| Grade | Range | Description |
+|-------|---------|-----------------------------------------------------------------------------|
+| **A** | 90-100 | Mastery of security concepts, innovative solutions, exceptional analysis |
+| **B** | 75-89 | Consistent completion, solid security understanding, minor improvements |
+| **C** | 60-74 | Basic security competency demonstrated, needs reinforcement |
+| **D** | 0-59 | Fundamental security gaps, re-attempt required |
+
+**Grade Calculation Examples:**
+
+**Scenario 1: Standard Path (Labs + Exam)**
+```
+Required Labs: 70/80 points (8 labs at 8pts, 2 at 5pts)
+Exam: 18/20 points
+Total: 88/100 = B+
+```
+
+**Scenario 2: Labs Only (80% Maximum)**
+```
+Required Labs: 80/80 points (perfect scores)
+No Exam: 0/20 points
+Total: 80/100 = B (cannot exceed 80% without exam/bonus)
+```
+
+**Scenario 3: Labs + Bonus (No Exam)**
+```
+Required Labs: 72/80 points
+Bonus Lab 11: 10/10 points
+Bonus Lab 12: 10/10 points
+Total: 92/100 = A (bonus labs replace exam)
+```
+
+**Scenario 4: Maximum Score**
+```
+Required Labs: 80/80 points
+Exam: 20/20 points
+Bonus Labs: 20/20 points
+Total: 120 points โ capped at 100/100 = A+ with buffer
+```
+
+
---
## โ
Success Path
-> *"Complete all labs with โฅ6/10 to pass. Perfect lab submissions grant exam exemption and bonus points toward an A."*
+> **"Complete all 10 required labs to earn 80%. Add exam (20%) OR both bonus labs (20%) to reach higher grades. Maximum 120 points available, capped at 100% for final grade."**
+
+
+๐ก Tips for Success
+
+**Lab Completion Strategy:**
+1. Start each lab early - security analysis takes time
+2. Read instructions thoroughly before beginning
+3. Test all security tools and configurations
+4. Document findings with screenshots and explanations
+5. Review vulnerability reports carefully
+
+**Security-Specific Tips:**
+1. **Understand the "Why"** - Don't just run tools, understand what they detect
+2. **Analyze Results** - Explain security implications, not just tool outputs
+3. **Think Like an Attacker** - Consider how vulnerabilities could be exploited
+4. **Prioritize Findings** - Use CVSS scores and risk assessment
+5. **Remediate Properly** - Provide secure alternatives, not just "fix this"
+
+**Documentation Best Practices:**
+1. Use clear Markdown formatting with security-focused headers
+2. Include both tool outputs AND your security analysis
+3. Explain attack vectors and business impact
+4. Screenshot critical vulnerabilities with annotations
+5. Organize findings by severity (Critical, High, Medium, Low)
+
+**Git Workflow:**
+1. Always work on feature branches for security labs
+2. Use descriptive commit messages (e.g., `security: add SAST scan results`)
+3. Push regularly to avoid losing vulnerability reports
+4. Open PRs to the course repository, not your fork
+5. Review the security checklist before submitting
+
+**Time Management:**
+1. Allocate 4-6 hours per lab (security analysis is thorough)
+2. Break labs into: setup, scanning, analysis, documentation
+3. Use lab deadlines visible in Moodle
+4. Review previous labs before starting new security modules
+5. Don't rush vulnerability analysis - accuracy matters
+
+**Getting Help:**
+1. Review lab guidelines and security tool documentation
+2. Check OWASP and CWE resources for vulnerability context
+3. Discuss security concepts with classmates (collaboration encouraged)
+4. Attend office hours with specific security questions
+5. Submit questions early - security troubleshooting takes time
+
+
+
+
+๐
Recommended Study Schedule
+
+**Per-Lab Pattern:**
+
+**Days 1-2: Setup & Understanding**
+- Attend lecture on security topic
+- Review lab requirements and security objectives
+- Install and configure security tools
+- Read documentation for scanners/analyzers
+
+**Days 3-5: Execution & Scanning**
+- Run security scans and collect results
+- Perform vulnerability assessments
+- Test security controls
+- Capture evidence (screenshots, logs)
+
+**Day 6: Analysis & Documentation**
+- Analyze security findings
+- Prioritize vulnerabilities by severity
+- Research remediation strategies
+- Document security insights
+
+**Day 7: Review & Submit**
+- Proofread security analysis
+- Verify all evidence is included
+- Review checklist for completeness
+- Submit PR via Moodle
+
+**Before Each Lab:**
+1. Review previous security concepts
+2. Ensure security tools are updated
+3. Read entire lab instructions first
+4. Identify prerequisites or installations needed
+
+**After Each Lab:**
+1. Reflect on key security learnings
+2. Note security challenges for future reference
+3. Review instructor feedback when provided
+4. Connect vulnerabilities to real-world incidents
+
+**Exam Preparation (if needed):**
+- Review all lab security findings
+- Revisit key vulnerability types
+- Practice security tool commands
+- Focus on understanding attack vectors, not memorization
+
+
+
+---
+
+## ๐ Additional Resources
+
+
+๐ Essential Links
+
+**Course Materials:**
+- [Moodle Course Page](https://moodle.innopolis.university/) - Lectures, deadlines, grades
+- [Course Repository](https://github.com/your-org/devsecops-course) - Lab assignments and resources
+
+**DevSecOps Fundamentals:**
+- [OWASP DevSecOps Guideline](https://owasp.org/www-project-devsecops-guideline/)
+- [NIST Secure Software Development Framework](https://csrc.nist.gov/Projects/ssdf)
+- [The DevSecOps Playbook](https://www.redhat.com/en/resources/devsecops-culture-process-and-tools-ebook)
+
+**Security Standards & Frameworks:**
+- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
+- [CWE Top 25](https://cwe.mitre.org/top25/)
+- [NIST Cybersecurity Framework](https://www.nist.gov/cyberframework)
+- [CIS Controls](https://www.cisecurity.org/controls)
+
+**Application Security Testing:**
+- [OWASP Testing Guide](https://owasp.org/www-project-web-security-testing-guide/)
+- [SAST vs DAST vs IAST](https://www.synopsys.com/blogs/software-security/sast-vs-dast-difference/)
+- [Security Testing in CI/CD](https://owasp.org/www-project-devsecops-guideline/latest/02a-Integrate-Security-into-Development)
+
+**Infrastructure Security:**
+- [Terraform Security Best Practices](https://www.terraform.io/docs/cloud/guides/recommended-practices/index.html)
+- [Kubernetes Security Best Practices](https://kubernetes.io/docs/concepts/security/)
+- [Docker Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html)
+
+**Vulnerability Management:**
+- [CVSS Calculator](https://www.first.org/cvss/calculator/3.1)
+- [National Vulnerability Database](https://nvd.nist.gov/)
+- [CVE Details](https://www.cvedetails.com/)
+
+**Supply Chain Security:**
+- [SBOM Standards (SPDX/CycloneDX)](https://www.cisa.gov/sbom)
+- [SLSA Framework](https://slsa.dev/)
+- [Sigstore Documentation](https://docs.sigstore.dev/)
+
+
+
+
+๐ ๏ธ Required Tools & Software
+
+**Core Tools (Needed for most labs):**
+- Git (version control with security features)
+- Docker (containerization and security scanning)
+- Text editor with Markdown support (VS Code recommended)
+- Web browser (Chrome, Firefox)
+- Terminal/Command line
+
+**Security Tools (Install as needed per lab):**
+- **Lab 1-2:** OWASP ZAP, threat modeling tools
+- **Lab 3:** Git-secrets, Gitleaks, signed commit setup
+- **Lab 4:** GitHub Actions, quality gates, SBOM generators
+- **Lab 5:** SAST tools (Semgrep, Bandit), DAST tools (ZAP)
+- **Lab 6:** Terraform, Checkov, KICS, Terrascan
+- **Lab 7:** Docker, Trivy, Snyk, Kubernetes (kind/minikube)
+- **Lab 8:** Syft, Grype, Cosign
+- **Lab 9:** Prometheus, Grafana, compliance scanners
+- **Lab 10:** Vulnerability management platforms
+
+**Installation Guides:**
+- Most security tools run in Docker containers (minimal setup)
+- Cloud services use free tiers (no payment required)
+- Tool-specific installation instructions provided in each lab
+
+
+
+
+๐ Learning Resources by Topic
+
+**Labs 1-2: DevSecOps & Threat Modeling**
+- [DevSecOps Manifesto](https://www.devsecops.org/)
+- [STRIDE Threat Modeling](https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats)
+- [OWASP Threat Modeling](https://owasp.org/www-community/Threat_Modeling)
+
+**Lab 3: Secure Git**
+- [Git Security Best Practices](https://www.git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work)
+- [Secrets Management Guide](https://owasp.org/www-project-devsecops-guideline/latest/02c-Secret-Management)
+- [GitHub Security Features](https://docs.github.com/en/code-security)
+
+**Lab 4: CI/CD Security**
+- [Secure CI/CD Practices](https://www.cisa.gov/sites/default/files/publications/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF)
+- [GitHub Actions Security](https://docs.github.com/en/actions/security-guides)
+- [SBOM Generation Guide](https://www.cisa.gov/sbom)
+
+**Lab 5: AppSec Testing**
+- [OWASP SAMM](https://owaspsamm.org/)
+- [Static Analysis Tools List](https://owasp.org/www-community/Source_Code_Analysis_Tools)
+- [Dynamic Analysis Guide](https://owasp.org/www-project-web-security-testing-guide/)
+
+**Lab 6: IaC Security**
+- [IaC Security Best Practices](https://owasp.org/www-project-devsecops-guideline/latest/02d-Infrastructure-as-Code-Scanning)
+- [KICS Documentation](https://docs.kics.io/)
+- [Checkov Documentation](https://www.checkov.io/1.Welcome/Quick%20Start.html)
+
+**Lab 7: Container Security**
+- [Docker Security Best Practices](https://docs.docker.com/develop/security-best-practices/)
+- [Kubernetes Security](https://kubernetes.io/docs/concepts/security/overview/)
+- [Container Security Guide](https://www.nist.gov/publications/application-container-security-guide)
+
+**Lab 8: Supply Chain**
+- [SLSA Framework](https://slsa.dev/spec/v1.0/)
+- [SBOM Tool](https://github.com/kubernetes-sigs/bom)
+- [Sigstore Tutorial](https://edu.chainguard.dev/open-source/sigstore/)
+
+**Lab 9: Monitoring & Compliance**
+- [Security Metrics Guide](https://www.sans.org/white-papers/55/)
+- [GDPR for Developers](https://www.smashingmagazine.com/2017/07/privacy-by-design-framework/)
+- [NIST SP 800-53](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)
+
+**Lab 10: Vulnerability Management**
+- [Vulnerability Management Lifecycle](https://owasp.org/www-community/Vulnerability_Management_Lifecycle)
+- [CVSS Guide](https://www.first.org/cvss/user-guide)
+- [Remediation Best Practices](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)
+
+
+
+---
+
+## ๐ Course Completion
+
+Upon successful completion of this course, you will have:
+
+โ
**Practical DevSecOps Skills** โ Hands-on experience with industry-standard security tools
+โ
**Security Portfolio** โ 10 documented security analysis projects showcasing your abilities
+โ
**Secure SDLC Knowledge** โ Understanding of shift-left security and secure development practices
+โ
**AppSec Testing Experience** โ SAST, DAST, and SCA tool integration expertise
+โ
**IaC Security Mastery** โ Configuration scanning and policy-as-code enforcement skills
+โ
**Container Security** โ Docker and Kubernetes hardening and scanning knowledge
+โ
**Supply Chain Awareness** โ SBOM generation and dependency security analysis
+โ
**Vulnerability Management** โ Discovery, triage, and remediation workflow proficiency
+โ
**Compliance Understanding** โ GDPR, NIST, and ISO security framework basics
+โ
**Threat Modeling Skills** โ STRIDE analysis and risk assessment capabilities
+
+---
diff --git a/labs/lab1.md b/labs/lab1.md
index 5d33263f..bccdc593 100644
--- a/labs/lab1.md
+++ b/labs/lab1.md
@@ -4,174 +4,200 @@
-> **Goal:** Run an OWASP Juice Shop locally, complete a triage report, and standardize PR submissions.
-> **Deliverable:** A PR from `feature/lab1` containing `labs/submission1.md`, issues created, and the PR template in place.
+> **Goal:** Run OWASP Juice Shop locally, complete a triage report, and standardize PR submissions.
+> **Deliverable:** A PR from `feature/lab1` to the course repo with `labs/submission1.md` containing triage report and PR template setup. Submit the PR link via Moodle.
---
## Overview
In this lab you will practice:
+- Launching **OWASP Juice Shop** for security testing
+- Capturing a **triage report** covering version, URL, health check, exposure, risks, and next actions
+- Bootstrapping a **repeatable PR workflow** with a template
-* Launching a **Juice Shop App**.
-* Capturing a **triage report** โ version, URL, health check, exposure, risks, and next actions.
-* Bootstrapping a **repeatable PR workflow** with a template.
-
-> We **do not** copy Juice Shop code into the repo. Youโll run the official Docker image and keep **only lab artifacts** in your fork. Run instructions come from Juice Shopโs docs; weโll pin a known release tag. ([pwning.owasp-juice.shop][1], [GitHub][2], [Docker Hub][3])
+> We **do not** copy Juice Shop code into the repo. You'll run the official Docker image and keep **only lab artifacts** in your fork.
---
## Tasks
-### Task 1 โ Triage (Juice Shop) (6 pts)
+### Task 1 โ OWASP Juice Shop Deployment (6 pts)
-**Objective:** Run a Juice Shop locally and complete a Triage report to capture the deployment, quick health, exposure, and top risks.
+**Objective:** Run Juice Shop locally and complete a Triage report capturing deployment, health check, exposure, and top risks.
-1. **Create the submission file**
+#### 1.1: Deploy Juice Shop Container
- * Create `labs/submission1.md` with these fields:
+```bash
+docker run -d --name juice-shop \
+ -p 127.0.0.1:3000:3000 \
+ bkimminich/juice-shop:v19.0.0
+```
- * `image: bkimminich/juice-shop:19.0.0`
- * release date (from GitHub Releases) and a link to the release notes.
+#### 1.2: Initial Verification
-2. **Run the container (detached)**
+- Browse to `http://localhost:3000` and confirm the app loads
+- Verify API responds: `curl -s http://127.0.0.1:3000/rest/products | head`
- ```bash
- docker run -d --name juice-shop \
- -p 127.0.0.1:3000:3000 \
- bkimminich/juice-shop:19.0.0
- ```
+#### 1.3: Complete Triage Report
- * Browse to `http://localhost:3000` and confirm the app loads.
+Create `labs/submission1.md` using this template:
-3. **Quick health check**
+```markdown
+# Triage Report โ OWASP Juice Shop
- * Verify the API responds:
+## Scope & Asset
+- Asset: OWASP Juice Shop (local lab instance)
+- Image: bkimminich/juice-shop:v19.0.0
+- Release link/date: โ
+- Image digest (optional):
- ```bash
- curl -s http://127.0.0.1:3000/rest/products | head
- ```
- * Take a screenshot of the home page or paste the first 5โ10 JSON lines from the API.
+## Environment
+- Host OS:
+- Docker:
-4. **Fill the Triage report**
+## Deployment Details
+- Run command used: `docker run -d --name juice-shop -p 127.0.0.1:3000:3000 bkimminich/juice-shop:v19.0.0`
+- Access URL: http://127.0.0.1:3000
+- Network exposure: 127.0.0.1 only [ ] Yes [ ] No (explain if No)
- * In `labs/submission1.md`, copy/paste this template and fill it out:
+## Health Check
+- Page load: attach screenshot of home page (path or embed)
+- API check: first 5โ10 lines from `curl -s http://127.0.0.1:3000/rest/products | head`
- ```markdown
- # Triage Report โ OWASP Juice Shop
+## Surface Snapshot (Triage)
+- Login/Registration visible: [ ] Yes [ ] No โ notes: <...>
+- Product listing/search present: [ ] Yes [ ] No โ notes: <...>
+- Admin or account area discoverable: [ ] Yes [ ] No โ notes: <...>
+- Client-side errors in console: [ ] Yes [ ] No โ notes: <...>
+- Security headers (quick look โ optional): `curl -I http://127.0.0.1:3000` โ CSP/HSTS present? notes: <...>
- ## Scope & Asset
- - Asset: OWASP Juice Shop (local lab instance)
- - Image: bkimminich/juice-shop:19.0.0
- - Release link/date: โ
- - Image digest (optional):
+## Risks Observed (Top 3)
+1)
+2)
+3)
+```
- ## Environment
- - Host OS:
- - Docker:
+In `labs/submission1.md`, document:
+- Complete triage report using provided template
+- Screenshots or API output demonstrating working deployment
+- Environment details and security observations
+- Analysis of top 3 security risks identified during assessment
- ## Deployment Details
- - Run command used: `docker run -d --name juice-shop -p 127.0.0.1:3000:3000 bkimminich/juice-shop:19.0.0`
- - Access URL: http://127.0.0.1:3000
- - Network exposure: 127.0.0.1 only [ ] Yes [ ] No (explain if No)
+---
- ## Health Check
- - Page load: attach screenshot of home page (path or embed)
- - API check: first 5โ10 lines from `curl -s http://127.0.0.1:3000/rest/products | head`
+### Task 2 โ PR Template Setup (4 pts)
- ## Surface Snapshot (Triage)
- - Login/Registration visible: [ ] Yes [ ] No โ notes: <...>
- - Product listing/search present: [ ] Yes [ ] No โ notes: <...>
- - Admin or account area discoverable: [ ] Yes [ ] No โ notes: <...>
- - Client-side errors in console: [ ] Yes [ ] No โ notes: <...>
- - Security headers (quick look โ optional): `curl -I http://127.0.0.1:3000` โ CSP/HSTS present? notes: <...>
+**Objective:** Standardize submissions so every lab PR has the same sections and checks.
- ## Risks Observed (Top 3)
- 1)
- 2)
- 3)
+#### 2.1: Create PR Template
- ```
+Create `.github/pull_request_template.md` with:
+- Sections: **Goal**, **Changes**, **Testing**, **Artifacts & Screenshots**
+- Checklist (3 items): clear title, docs updated if needed, no secrets/large temp files
-> Resources: Juice Shop Docker image on Docker Hub; official run docs. ([Docker Hub][3], [pwning.owasp-juice.shop][1])
+```bash
+# Commit message example:
+git commit -m "docs: add PR template"
+```
----
+#### 2.2: Verify Template Application
-### Task 2 โ PR Template (4 pts)
+```bash
+git checkout -b feature/lab1
+git add labs/submission1.md
+git commit -m "docs(lab1): add submission1 triage report"
+git push -u origin feature/lab1
+```
-**Objective:** Standardize submissions so every lab PR has the same sections and checks.
+Verify that:
+- PR description auto-fills with sections & checklist
+- Fill in **Goal / Changes / Testing / Artifacts & Screenshots** and tick checkboxes
+- Screenshots and API snippet are embedded in `labs/submission1.md`
+
+In `labs/submission1.md`, document:
+- PR template creation process and verification
+- Evidence that template auto-fills correctly
+- Analysis of how templates improve collaboration workflow
+
+
+One-time Bootstrap Note
-> โ ๏ธ **One-time bootstrap:** GitHub loads PR templates from the **default branch of your fork (`main`)**. Add the template to `main` first, then open your lab PR from `feature/lab1`.
+GitHub loads PR templates from the **default branch of your fork (`main`)**. Add the template to `main` first, then open your lab PR from `feature/lab1`.
-1. **Create the PR template on `main`**
- Path: `.github/pull_request_template.md`
- Commit message: `docs: add PR template`
- Include exactly these sections and checklist:
+
- * Sections: **Goal**, **Changes**, **Testing**, **Artifacts & Screenshots**
- * Checklist (3 items): clear title, docs updated if needed, no secrets/large temp files
+---
+
+## How to Submit
-2. **Create your lab branch, add your submission file, open PR**
+1. Create a branch for this lab and push it to your fork:
```bash
- git checkout -b feature/lab1
- # add labs/submission1.md
+ git switch -c feature/lab1
+ # create labs/submission1.md with your findings
git add labs/submission1.md
- git commit -m "docs(lab1): add submission1 triage report"
+ git commit -m "docs: add lab1 submission"
git push -u origin feature/lab1
```
- * Open a PR from `feature/lab1` โ `main` **in your fork**.
+2. Open a PR from your fork's `feature/lab1` branch โ **course repository's main branch**.
-3. **Verify the template is applied**
+3. In the PR description, include:
- * The PR description should auto-fill with your sections & checklist.
- * Fill in **Goal / Changes / Testing / Artifacts & Screenshots** and tick the checkboxes.
- * Ensure your screenshots and API snippet are embedded or referenced in `labs/submission1.md`.
-
-### Acceptance Criteria
+ ```text
+ - [x] Task 1 done โ OWASP Juice Shop deployment + triage report
+ - [x] Task 2 done โ PR template setup + verification
+ ```
-* โ
`labs/submission1.md` exists and includes: image `bkimminich/juice-shop:19.0.0` with release link/date; environment; deployment details; access URL; working health check evidence (screenshot or API snippet); surface snapshot; top 3 risks.
-* โ
3โ5 **Issues** exist in the repo labeled `backlog` (derived from your triage next actions) and linked from `labs/submission1.md`.
-* โ
`.github/pull_request_template.md` exists on **`main`**.
-* โ
A PR from `feature/lab1` โ `main` is open and **auto-filled** with the template, including **Goal / Changes / Testing / Artifacts & Screenshots** (boxes ticked).
-* โ
**No Juice Shop source code** is copied into the repoโonly lab artifacts.
+4. **Copy the PR URL** and submit it via **Moodle before the deadline**.
---
-## How to Submit
-
-1. Complete all tasks.
-2. Push `feature/lab1` to your fork.
-3. Open a PR from `feature/lab1` โ `main` in **your fork**.
-4. In the PR description, include:
+## Acceptance Criteria
- ```text
- - [x] Task 1 done
- - [x] Task 2 done
- - [x] Screenshots attached
- ```
+- โ
Branch `feature/lab1` exists with commits for each task
+- โ
File `labs/submission1.md` contains required triage report for Tasks 1-2
+- โ
OWASP Juice Shop successfully deployed and documented
+- โ
File `.github/pull_request_template.md` exists on **main** branch
+- โ
PR from `feature/lab1` โ **course repo main branch** is open
+- โ
PR link submitted via Moodle before the deadline
+- โ
**No Juice Shop source code** copied into repoโonly lab artifacts
---
## Rubric (10 pts)
-| Criterion | Points |
-| --------------------------------------------------------- | -----: |
-| Task 1 โ Triage in `labs/submission1.md` + image running | **6** |
-| Task 2 โ PR template in effect + PR opened | **4** |
-| **Total** | **10** |
+| Criterion | Points |
+| -------------------------------------------------------- | -----: |
+| Task 1 โ OWASP Juice Shop deployment + triage report | **6** |
+| Task 2 โ PR template setup + verification | **4** |
+| **Total** | **10** |
---
-## Hints
+## Guidelines
-> ๐ **Why pin the version?** Juice Shop changes challenges between releases; pinning (e.g., `:19.0.0`) keeps labs reproducible for everyone. Check the **GitHub Releases** page for the date and notes. ([GitHub][2])\
-> ๐งช **Health check tip:** The official guide uses `-p 127.0.0.1:3000:3000`; always include `127.0.0.1` to avoid exposing the app beyond localhost by accident. ([pwning.owasp-juice.shop][1])\
-> ๐ซ **Donโt add app code:** All labs use the official Docker image from Docker Hubโyour repo holds configs, reports, and CI only. ([Docker Hub][3])
+- Use clear Markdown headers to organize sections in `submission1.md`
+- Include both command outputs and written analysis for each task
+- Document deployment process and security observations
+- Ensure screenshots and evidence demonstrate working setup
----
+
+Security Notes
+
+- Always bind to `127.0.0.1` to avoid exposing the app beyond localhost
+- Pin specific Docker image versions for reproducibility
+- Never commit application source codeโonly lab artifacts and reports
+
+
+
+
+Deployment Tips
+
+- Check GitHub Releases page for specific version dates and notes
+- Verify API endpoints respond before completing triage report
+- Document all observed security issues in the triage template
+- Keep deployment commands simple and well-documented
-[1]: https://pwning.owasp-juice.shop/companion-guide/latest/part1/running.html?utm_source=chatgpt.com "Running OWASP Juice Shop"
-[2]: https://github.com/juice-shop/juice-shop/releases/?utm_source=chatgpt.com "Releases ยท juice-shop/juice-shop - GitHub"
-[3]: https://hub.docker.com/r/bkimminich/juice-shop/?utm_source=chatgpt.com "bkimminich/juice-shop - Docker Image | Docker Hub"
+
\ No newline at end of file
diff --git a/labs/lab10.md b/labs/lab10.md
new file mode 100644
index 00000000..378b56a5
--- /dev/null
+++ b/labs/lab10.md
@@ -0,0 +1,209 @@
+# Lab 10 โ Vulnerability Management & Response with DefectDojo
+
+
+
+
+
+> Goal: Stand up DefectDojo locally, import prior lab findings (ZAP, Semgrep, Trivy/Grype, Nuclei), and produce a stakeholder-ready reporting & metrics package.
+> Deliverable: A PR from `feature/lab10` with `labs/submission10.md` summarizing setup evidence, import results, metrics snapshot highlights, and links to exported artifacts. Submit the PR link via Moodle.
+
+---
+
+## Overview
+
+In this lab you will practice:
+- Standing up OWASP DefectDojo locally via Docker Compose
+- Organizing findings across products/engagements/tests
+- Importing findings from multiple tools (ZAP, Semgrep, Trivy, Nuclei)
+- Generating reports that non-technical stakeholders can consume
+- Deriving basic program metrics (open/closed status, severity mix, SLA outlook)
+
+> Primary platform: OWASP DefectDojo (open source, 2025)
+
+---
+
+## Prerequisites
+
+- Docker with Compose V2 (`docker compose` available)
+- `git`, `curl`, `jq`
+- Prior lab outputs available locally (paths below)
+
+Create working directories:
+```bash
+mkdir -p labs/lab10/{setup,imports,report}
+```
+
+---
+
+## Tasks
+
+### Task 1 โ DefectDojo Local Setup (2 pts)
+Objective: Run DefectDojo locally and prepare the structure for managing findings.
+
+#### 1.1: Clone and start DefectDojo
+```bash
+# Clone upstream
+git clone https://github.com/DefectDojo/django-DefectDojo.git labs/lab10/setup/django-DefectDojo
+cd labs/lab10/setup/django-DefectDojo
+
+# Optional: check compose compatibility
+./docker/docker-compose-check.sh || true
+
+# Build and start (first run can take a bit)
+docker compose build
+docker compose up -d
+
+# Verify containers are healthy
+docker compose ps
+# UI: http://localhost:8080
+```
+
+#### 1.2: Get admin credentials (no manual superuser needed)
+```bash
+# Watch initializer logs until the admin password is printed
+docker compose logs -f initializer
+# In a second terminal, extract the password once available:
+docker compose logs initializer | grep "Admin password:"
+
+# Login to the UI at http://localhost:8080 with:
+# Username: admin
+# Password:
+```
+---
+
+### Task 2 โ Import Prior Findings (4 pts)
+Objective: Import findings from your previous labs into the engagement.
+
+Use the importer script below; no manual API calls are required. The script will autoโcreate the product type/product/engagement if missing.
+
+#### 2.1: Get API token and set variables
+```bash
+# In the UI: Profile โ API v2 Key โ copy your token
+export DD_API="http://localhost:8080/api/v2"
+export DD_TOKEN="REPLACE_WITH_YOUR_API_TOKEN"
+
+# Target context (adjust names if you prefer)
+export DD_PRODUCT_TYPE="Engineering"
+export DD_PRODUCT="Juice Shop"
+export DD_ENGAGEMENT="Labs Security Testing"
+# The import script will auto-detect importer names from your instance.
+```
+
+#### 2.2: Required reports (expected paths)
+- ZAP: `labs/lab5/zap/zap-report-noauth.json`
+- Semgrep: `labs/lab5/semgrep/semgrep-results.json`
+- Trivy: `labs/lab4/trivy/trivy-vuln-detailed.json`
+- Nuclei: `labs/lab5/nuclei/nuclei-results.json`
+- Grype (optional): `labs/lab4/syft/grype-vuln-results.json`
+
+#### 2.3: Run the importer script
+```bash
+bash labs/lab10/imports/run-imports.sh
+```
+The script auto-detects importer names, auto-creates context if missing, imports any reports found at the paths above, and saves responses under `labs/lab10/imports/`.
+---
+
+### Task 3 โ Reporting & Program Metrics (4 pts)
+Objective: Turn raw imports into an easy-to-understand report and metrics package that a stakeholder can consume without prior Dojo experience.
+
+#### 3.1: Create a baseline progress snapshot
+- From the engagement dashboard, note the counts for Active, Verified, and Mitigated findings.
+- Use the โFiltersโ sidebar to group by severity; grab a screenshot or jot the numbers.
+- Record the snapshot using the template below:
+ ```bash
+ mkdir -p labs/lab10/report
+ cat > labs/lab10/report/metrics-snapshot.md <<'EOF'
+ # Metrics Snapshot โ Lab 10
+
+ - Date captured:
+ - Active findings:
+ - Critical:
+ - High:
+ - Medium:
+ - Low:
+ - Informational:
+ - Verified vs. Mitigated notes:
+ EOF
+ ```
+
+#### 3.2: Generate governance-ready artifacts
+- In the Engagement โ Reports page, choose a human-readable template (Executive, Detailed, or similar) and generate a PDF or HTML report.
+ - Save it to `labs/lab10/report/dojo-report.pdf` or `.html`.
+- Download the โFindings list (CSV)โ from the same page and store it as `labs/lab10/report/findings.csv` for spreadsheet analysis.
+
+#### 3.3: Extract key metrics for `labs/submission10.md`
+- From the report or dashboard, capture:
+ - Open vs. Closed counts by severity.
+ - Findings per tool (ZAP, Semgrep, Trivy, Nuclei, and Grype).
+ - Any SLA breaches or items due within the next 14 days.
+ - Top recurring CWE/OWASP categories.
+- Summarize these in prose (3โ5 bullet points) inside `labs/submission10.md`.
+
+Deliverables for this task:
+- `labs/lab10/report/metrics-snapshot.md`
+- `labs/lab10/report/dojo-report.(pdf|html)`
+- `labs/lab10/report/findings.csv`
+- Metric summary bullets in `labs/submission10.md`
+
+---
+
+## Acceptance Criteria
+
+- โ
DefectDojo runs locally and an admin user can log in
+- โ
Product Type, Product, and Engagement are configured
+- โ
Imports completed for ZAP, Semgrep, Trivy (plus Nuclei/Grype if available)
+- โ
Reporting artifacts generated: metrics snapshot, Dojo report, findings CSV, and summary bullets in `labs/submission10.md`
+- โ
All artifacts saved under `labs/lab10/`
+
+---
+
+## How to Submit
+
+1. Create a branch for this lab and push it to your fork:
+```bash
+git switch -c feature/lab10
+# create labs/submission10.md with your findings
+git add labs/lab10/ labs/submission10.md
+git commit -m "docs: lab10 โ DefectDojo vuln management"
+git push -u origin feature/lab10
+```
+2. Open a PR from your forkโs `feature/lab10` โ course repoโs `main`.
+3. Include this checklist in the PR description:
+```text
+- [x] Task 1 โ Dojo setup and structure
+- [x] Task 2 โ Imports completed (multi-tool)
+- [x] Task 3 โ Report + metrics package
+```
+4. Submit the PR URL via Moodle before the deadline.
+
+---
+
+## Rubric (10 pts)
+
+| Criterion | Points |
+| ------------------------------------------------------------ | -----: |
+| Task 1 โ DefectDojo local setup | 2.0 |
+| Task 2 โ Import prior findings (multi-tool) | 4.0 |
+| Task 3 โ Reporting & metrics package | 4.0 |
+| Total | 10.0 |
+
+---
+
+## Guidelines
+
+- Keep sensitive data out of uploads; use lab outputs only
+- Prefer JSON formats for robust importer support
+- If you explore deduplication, note the algorithm choice (helps explain numbers)
+- Be explicit when marking false positives (add justification)
+- Keep SLAs realistic but time-bound; reference calendar dates
+
+
+References
+
+- DefectDojo: https://github.com/DefectDojo/django-DefectDojo
+- Importers list: check your UI Import Scan page for exact `scan_type` names
+- Local API v2 docs: http://localhost:8080/api/v2/doc/ (after startup)
+- Official docs (Open Source): https://docs.defectdojo.com/en/open_source/
+- CVSS v3.1 Calculator: https://www.first.org/cvss/calculator/3.1
+
+
diff --git a/labs/lab10/imports/run-imports.sh b/labs/lab10/imports/run-imports.sh
new file mode 100644
index 00000000..0f0e33c9
--- /dev/null
+++ b/labs/lab10/imports/run-imports.sh
@@ -0,0 +1,134 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Batch import helper for Lab 10
+# - Auto-detects scan_type names from your Dojo instance
+# - Imports whichever files exist among ZAP, Semgrep, Trivy, Nuclei (and optional Grype)
+#
+# Usage:
+# export DD_API="http://localhost:8080/api/v2"
+# export DD_TOKEN=""
+# # Optional overrides (defaults shown)
+# export DD_PRODUCT_TYPE="${DD_PRODUCT_TYPE:-Engineering}"
+# export DD_PRODUCT="${DD_PRODUCT:-Juice Shop}"
+# export DD_ENGAGEMENT="${DD_ENGAGEMENT:-Labs Security Testing}"
+# bash labs/lab10/imports/run-imports.sh
+
+here_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+out_dir="$here_dir"
+
+require_env() {
+ local name="$1"
+ if [[ -z "${!name:-}" ]]; then
+ echo "ERROR: env var $name is required" >&2
+ exit 1
+ fi
+}
+
+require_env DD_API
+require_env DD_TOKEN
+
+DD_PRODUCT_TYPE="${DD_PRODUCT_TYPE:-Engineering}"
+DD_PRODUCT="${DD_PRODUCT:-Juice Shop}"
+DD_ENGAGEMENT="${DD_ENGAGEMENT:-Labs Security Testing}"
+
+echo "Using context:"
+echo " DD_API=$DD_API"
+echo " DD_PRODUCT_TYPE=$DD_PRODUCT_TYPE"
+echo " DD_PRODUCT=$DD_PRODUCT"
+echo " DD_ENGAGEMENT=$DD_ENGAGEMENT"
+
+have_jq=true
+command -v jq >/dev/null 2>&1 || have_jq=false
+if ! $have_jq; then
+ echo "WARN: jq not found; falling back to defaults for scan_type names." >&2
+fi
+
+# Discover scan type names from your instance if jq is available
+SCAN_ZAP="${SCAN_ZAP:-}"
+SCAN_SEMGREP="${SCAN_SEMGREP:-}"
+SCAN_TRIVY="${SCAN_TRIVY:-}"
+SCAN_NUCLEI="${SCAN_NUCLEI:-}"
+
+if $have_jq; then
+ echo "Discovering importer names from /test_types/ ..."
+ mapfile -t types < <(curl -sS -H "Authorization: Token $DD_TOKEN" "$DD_API/test_types/?limit=2000" | jq -r '.results[].name')
+ choose_type() {
+ local pat="$1"
+ local fallback="$2"
+ local val=""
+ for t in "${types[@]}"; do
+ if [[ "$t" =~ $pat ]]; then val="$t"; break; fi
+ done
+ if [[ -z "$val" ]]; then val="$fallback"; fi
+ echo "$val"
+ }
+ SCAN_ZAP="${SCAN_ZAP:-$(choose_type '^ZAP' 'ZAP Scan')}"
+ SCAN_SEMGREP="${SCAN_SEMGREP:-$(choose_type '^Semgrep' 'Semgrep JSON Report')}"
+ SCAN_TRIVY="${SCAN_TRIVY:-$(choose_type '^Trivy' 'Trivy Scan')}"
+ SCAN_NUCLEI="${SCAN_NUCLEI:-$(choose_type '^Nuclei' 'Nuclei Scan')}"
+ # Grype importer (commonly named "Anchore Grype")
+ if [[ -z "${SCAN_GRYPE:-}" ]]; then
+ SCAN_GRYPE=$(printf '%s\n' "${types[@]}" | grep -i '^Anchore Grype' | head -n1)
+ if [[ -z "$SCAN_GRYPE" ]]; then
+ SCAN_GRYPE=$(printf '%s\n' "${types[@]}" | grep -i 'Grype' | head -n1)
+ fi
+ fi
+else
+ SCAN_ZAP="${SCAN_ZAP:-ZAP Scan}"
+ SCAN_SEMGREP="${SCAN_SEMGREP:-Semgrep JSON Report}"
+ SCAN_TRIVY="${SCAN_TRIVY:-Trivy Scan}"
+ SCAN_NUCLEI="${SCAN_NUCLEI:-Nuclei Scan}"
+fi
+SCAN_GRYPE="${SCAN_GRYPE:-Anchore Grype}"
+
+echo "Importer names:"
+echo " ZAP = $SCAN_ZAP"
+echo " Semgrep = $SCAN_SEMGREP"
+echo " Trivy = $SCAN_TRIVY"
+echo " Nuclei = $SCAN_NUCLEI"
+echo " Grype = $SCAN_GRYPE"
+
+import_scan() {
+ local scan_type="$1"; shift
+ local file="$1"; shift
+ if [[ ! -f "$file" ]]; then
+ echo "SKIP: $scan_type file not found: $file"
+ return 0
+ fi
+ local base out
+ base="$(basename "$file")"
+ out="$out_dir/import-${base//[^A-Za-z0-9_.-]/_}.json"
+ echo "Importing $scan_type from $file"
+ curl -sS -X POST "$DD_API/import-scan/" \
+ -H "Authorization: Token $DD_TOKEN" \
+ -F "scan_type=$scan_type" \
+ -F "file=@$file" \
+ -F "product_type_name=$DD_PRODUCT_TYPE" \
+ -F "product_name=$DD_PRODUCT" \
+ -F "engagement_name=$DD_ENGAGEMENT" \
+ -F "auto_create_context=true" \
+ -F "minimum_severity=Info" \
+ -F "close_old_findings=false" \
+ -F "push_to_jira=false" \
+ | tee "$out"
+}
+
+# Candidate paths per tool
+zap_file="labs/lab5/zap/zap-report-noauth.json"
+semgrep_file="labs/lab5/semgrep/semgrep-results.json"
+trivy_file="labs/lab4/trivy/trivy-vuln-detailed.json"
+nuclei_file="labs/lab5/nuclei/nuclei-results.json"
+
+# Grype
+grype_file="labs/lab4/syft/grype-vuln-results.json"
+
+import_scan "$SCAN_ZAP" "$zap_file"
+import_scan "$SCAN_SEMGREP" "$semgrep_file"
+import_scan "$SCAN_TRIVY" "$trivy_file"
+import_scan "$SCAN_NUCLEI" "$nuclei_file"
+
+# Grype
+import_scan "$SCAN_GRYPE" "$grype_file"
+
+echo "Done. Import responses saved under $out_dir"
diff --git a/labs/lab11.md b/labs/lab11.md
new file mode 100644
index 00000000..4ada0627
--- /dev/null
+++ b/labs/lab11.md
@@ -0,0 +1,285 @@
+# Lab 11 โ Reverse Proxy Hardening: Nginx Security Headers, TLS, and Rate Limiting
+
+
+
+
+
+> Goal: Place OWASP Juice Shop behind an Nginx reverse proxy and harden it with security headers, TLS, and request rate limiting โ without changing app code.
+> Deliverable: A PR from `feature/lab11` with `labs/submission11.md` including command evidence, header/TLS scans, rate-limit test results, and a short analysis of trade-offs.
+
+---
+
+## Overview
+
+You will:
+- Deploy Juice Shop behind a reverse proxy using Docker Compose
+- Add and verify essential security headers (XFO, XCTO, HSTS, Referrer-Policy, Permissions-Policy, COOP/CORP)
+- Enable TLS with a local self-signed certificate and verify configuration
+- Implement request rate limiting and timeouts to reduce brute-force/DoS risk
+
+This lab is designed to be practical and educational, focusing on changes operations teams can make without touching application code.
+
+---
+
+## Prerequisites
+
+Before starting, ensure you have:
+- โ
Docker installed and running (`docker --version`)
+- โ
Docker Compose installed (`docker compose version`)
+- โ
`curl` and `jq` for testing and JSON parsing
+- โ
At least 2GB free disk space
+- โ
~45-60 minutes available
+
+**Quick Setup Check:**
+```bash
+# Pull images in advance (optional)
+docker pull bkimminich/juice-shop:v19.0.0
+docker pull nginx:stable-alpine
+docker pull alpine:latest
+docker pull drwetter/testssl.sh:latest
+
+# Create working directories
+mkdir -p labs/lab11/{reverse-proxy/certs,logs,analysis}
+```
+
+**Files provided in this repo:**
+- `labs/lab11/docker-compose.yml` - Stack configuration
+- `labs/lab11/reverse-proxy/nginx.conf` - Pre-configured with security headers, TLS, rate limiting
+
+---
+
+## Tasks
+
+### Task 1 โ Reverse Proxy Compose Setup (2 pts)
+โฑ๏ธ **Estimated time:** 10 minutes
+
+**Objective:** Run Juice Shop behind Nginx (no app port exposed directly).
+
+#### 1.1: Prepare certs and start the stack
+```bash
+# Navigate to lab11 directory
+cd labs/lab11
+
+# Generate a local self-signed cert with SAN for localhost so Nginx can start
+docker run --rm -v "$(pwd)/reverse-proxy/certs":/certs \
+ alpine:latest \
+ sh -c "apk add --no-cache openssl && cat > /tmp/san.cnf << 'EOF' && \
+cat /tmp/san.cnf && \
+openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
+ -keyout /certs/localhost.key -out /certs/localhost.crt \
+ -config /tmp/san.cnf -extensions v3_req
+[ req ]
+default_bits = 2048
+distinguished_name = req_distinguished_name
+x509_extensions = v3_req
+prompt = no
+
+[ req_distinguished_name ]
+CN = localhost
+
+[ v3_req ]
+subjectAltName = @alt_names
+
+[ alt_names ]
+DNS.1 = localhost
+IP.1 = 127.0.0.1
+IP.2 = ::1
+EOF"
+
+# Start services
+docker compose up -d
+docker compose ps
+
+# Verify HTTP (should redirect to HTTPS)
+curl -s -o /dev/null -w "HTTP %{http_code}\n" http://localhost:8080/
+```
+
+Expected: `HTTP 308` (redirect to HTTPS).
+
+#### 1.2: Confirm no direct app exposure
+```bash
+# Only Nginx should have published host ports; Juice Shop should have none
+docker compose ps
+```
+
+In `labs/submission11.md`, document:
+
+**Task 1 Requirements:**
+ - Explain why reverse proxies are valuable for security (TLS termination, security headers injection, request filtering, single access point)
+ - Explain why hiding direct app ports reduces attack surface
+ - Include the `docker compose ps` output showing only Nginx has published host ports (Juice Shop shows none)
+
+---
+
+### Task 2 โ Security Headers (3 pts)
+โฑ๏ธ **Estimated time:** 10 minutes
+
+**Objective:** Review the essential headers at the proxy and verify theyโre present over HTTP/HTTPS.
+
+Headers configured in `nginx.conf`:
+ - `X-Frame-Options: DENY`
+ - `X-Content-Type-Options: nosniff`
+ - `Referrer-Policy: strict-origin-when-cross-origin`
+ - `Permissions-Policy: camera=(), geolocation=(), microphone=()`
+ - `Cross-Origin-Opener-Policy: same-origin`
+ - `Cross-Origin-Resource-Policy: same-origin`
+ - `Content-Security-Policy-Report-Only: default-src 'self'; img-src 'self' data:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'`
+
+Note: CSP is set in Report-Only mode to avoid breaking Juice Shop functionality.
+
+โฑ๏ธ ~10 minutes
+
+#### 2.1: Verify headers (HTTP)
+```bash
+curl -sI http://localhost:8080/ | tee analysis/headers-http.txt
+```
+
+#### 2.2: Verify headers (after TLS in Task 3)
+```bash
+curl -skI https://localhost:8443/ | tee analysis/headers-https.txt
+```
+
+In `labs/submission11.md`, document:
+
+**Task 2 Requirements:**
+ - Paste relevant security headers from `headers-https.txt`
+ - For each header, explain what it protects against:
+ - **X-Frame-Options**: ---
+ - **X-Content-Type-Options**: ---
+ - **Strict-Transport-Security (HSTS)**: ---
+ - **Referrer-Policy**: ---
+ - **Permissions-Policy**: ---
+ - **COOP/CORP**: ---
+ - **CSP-Report-Only**: ---
+---
+
+### Task 3 โ TLS, HSTS, Rate Limiting & Timeouts (5 pts)
+โฑ๏ธ **Estimated time:** 20 minutes
+
+**Objective:** Confirm HTTPS and HSTS behavior, scan TLS, and validate rate limiting and timeouts to reduce brute-force and slowloris risks.
+
+#### 3.1: Scan TLS (testssl.sh)
+Use one of the following, depending on your OS:
+```bash
+# Linux: use host networking to reach localhost:8443
+docker run --rm --network host drwetter/testssl.sh:latest https://localhost:8443 \
+ | tee analysis/testssl.txt
+
+# Mac/Windows (Docker Desktop): target host.docker.internal
+docker run --rm drwetter/testssl.sh:latest https://host.docker.internal:8443 \
+ | tee analysis/testssl.txt
+```
+
+---
+
+#### 3.2: Validate rate limiting on login
+Login rate limit is configured on `/rest/user/login` with Nginx `limit_req` and `limit_req_status 429`.
+
+##### Trigger rate limiting
+```bash
+for i in $(seq 1 12); do \
+ curl -sk -o /dev/null -w "%{http_code}\n" \
+ -H 'Content-Type: application/json' \
+ -X POST https://localhost:8443/rest/user/login \
+ -d '{"email":"a@a","password":"a"}'; \
+done | tee analysis/rate-limit-test.txt
+```
+Expected: Some responses return `429` once the burst+rate thresholds are exceeded.
+
+In `labs/submission11.md`, document:
+
+**Task 3 Requirements:**
+- TLS/testssl summary:
+ - Summarize TLS protocol support from testssl scan (which versions are enabled)
+ - List cipher suites that are supported
+ - Explain why TLSv1.2+ is required (prefer TLSv1.3)
+ - Note any warnings or vulnerabilities from testssl output
+ - Confirm HSTS header appears only on HTTPS responses (not HTTP)
+
+Note on dev certificates: On localhost you should still expect these โNOT okโ items with a selfโsigned cert: chain of trust (selfโsigned), OCSP/CRL/CT/CAA, and OCSP stapling not offered. To eliminate them, either trust a local CA (e.g., mkcert) or use a real domain and a public CA (e.g., Letโs Encrypt) and then enable OCSP stapling (comments in nginx.conf).
+
+- Rate limiting & timeouts:
+ - Show rate-limit test output (how many 200s vs 429s)
+ - Explain the rate limit configuration: `rate=10r/m`, `burst=5`, and why these values balance security vs usability
+ - Explain timeout settings in nginx.conf: `client_body_timeout`, `client_header_timeout`, `proxy_read_timeout`, `proxy_send_timeout`, with trade-offs
+ - Paste relevant lines from access.log showing 429 responses
+
+---
+
+## Acceptance Criteria
+
+- โ
Nginx reverse proxy running; Juice Shop not directly exposed
+- โ
Security headers present over HTTP/HTTPS; HSTS only on HTTPS
+- โ
TLS enabled and scanned; HSTS verified; outputs captured
+- โ
Rate limiting returns 429 on excessive login attempts; logs captured; timeouts discussed
+- โ
All outputs committed under `labs/lab11/`
+
+---
+
+## Cleanup
+
+After completing the lab:
+
+```bash
+# Stop and remove containers
+cd labs/lab11 # if not already there
+docker compose down
+
+# Optional: Remove generated certificates
+# rm -rf labs/lab11/reverse-proxy/certs/*
+
+# Check disk space
+docker system df
+```
+
+---
+
+## How to Submit
+
+1. Create a branch and push it to your fork:
+```bash
+git switch -c feature/lab11
+# create labs/submission11.md with your findings
+git add labs/lab11/ labs/submission11.md
+git commit -m "docs: add lab11 โ nginx reverse proxy hardening"
+git push -u origin feature/lab11
+```
+2. Open a PR from your forkโs `feature/lab11` โ course repoโs `main`.
+3. In the PR description include:
+```text
+- [x] Task 1 โ Reverse proxy compose setup
+- [x] Task 2 โ Security headers verification
+- [x] Task 3 โ TLS + HSTS + rate limiting + timeouts (+ testssl)
+```
+4. Submit the PR URL via Moodle before the deadline.
+
+---
+
+## Rubric (10 pts)
+
+| Criterion | Points |
+| ----------------------------------------------------- | -----: |
+| Task 1 โ Reverse proxy compose setup | 2.0 |
+| Task 2 โ Security headers (HTTP/HTTPS) | 3.0 |
+| Task 3 โ TLS, HSTS, rate limiting & timeouts | 5.0 |
+| Total | 10.0 |
+
+---
+
+## Guidelines
+
+- Keep app container internal; only expose Nginx ports to host
+- Use `add_header ... always;` so headers appear even on errors/redirects
+- Place HSTS only on HTTPS server blocks
+- Start CSP in Report-Only and iterate; Juice Shop is JS-heavy and can break under strict CSP
+- Choose rate limits that balance security and usability; document your rationale
+
+
+Resources
+
+- Nginx security headers: https://nginx.org/en/docs/http/ngx_http_headers_module.html
+- TLS config guidelines: https://ssl-config.mozilla.org/
+- testssl.sh: https://github.com/drwetter/testssl.sh
+- Permissions Policy: https://www.w3.org/TR/permissions-policy-1/
+
+
diff --git a/labs/lab11/docker-compose.yml b/labs/lab11/docker-compose.yml
new file mode 100644
index 00000000..da5002c1
--- /dev/null
+++ b/labs/lab11/docker-compose.yml
@@ -0,0 +1,19 @@
+services:
+ juice:
+ image: bkimminich/juice-shop:v19.0.0
+ restart: unless-stopped
+ expose:
+ - "3000"
+
+ nginx:
+ image: nginx:stable-alpine
+ restart: unless-stopped
+ depends_on:
+ - juice
+ ports:
+ - "8080:8080" # HTTP (will redirect to HTTPS)
+ - "8443:8443" # HTTPS
+ volumes:
+ - ./reverse-proxy/nginx.conf:/etc/nginx/nginx.conf:ro
+ - ./reverse-proxy/certs:/etc/nginx/certs:ro
+ - ./logs:/var/log/nginx:rw
diff --git a/labs/lab11/reverse-proxy/nginx.conf b/labs/lab11/reverse-proxy/nginx.conf
new file mode 100644
index 00000000..b90f6c47
--- /dev/null
+++ b/labs/lab11/reverse-proxy/nginx.conf
@@ -0,0 +1,127 @@
+user nginx;
+worker_processes auto;
+
+events { worker_connections 1024; }
+
+http {
+ include /etc/nginx/mime.types;
+ default_type application/octet-stream;
+ sendfile on;
+ keepalive_timeout 10;
+ server_tokens off;
+ gzip off;
+
+ # Security-focused logs
+ log_format security '$remote_addr - $remote_user [$time_local] '
+ '"$request" $status $body_bytes_sent '
+ '"$http_referer" "$http_user_agent" '
+ 'rt=$request_time uct=$upstream_connect_time '
+ 'urt=$upstream_response_time';
+ access_log /var/log/nginx/access.log security;
+ error_log /var/log/nginx/error.log warn;
+
+ # Upstream app
+ upstream juice {
+ server juice:3000;
+ keepalive 32;
+ }
+
+ # Rate limit zone for login
+ # ~10 req/min per IP, burst of 5
+ limit_req_zone $binary_remote_addr zone=login:10m rate=10r/m;
+ limit_req_status 429;
+
+ map $http_upgrade $connection_upgrade { default upgrade; '' close; }
+
+ # Common proxy settings
+ proxy_set_header Host $host;
+ proxy_set_header X-Real-IP $remote_addr;
+ proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+ proxy_set_header X-Forwarded-Proto $scheme;
+ proxy_http_version 1.1;
+ proxy_set_header Connection $connection_upgrade;
+ proxy_set_header Upgrade $http_upgrade;
+ # Prevent upstream TLS BREACH vector by disabling compression from upstream
+ proxy_set_header Accept-Encoding "";
+ proxy_read_timeout 30s;
+ proxy_send_timeout 30s;
+ proxy_connect_timeout 5s;
+ proxy_hide_header X-Powered-By;
+ # Hide upstream headers to avoid duplicates and enforce policy at the proxy
+ proxy_hide_header X-Frame-Options;
+ proxy_hide_header X-Content-Type-Options;
+ proxy_hide_header Referrer-Policy;
+ proxy_hide_header Permissions-Policy;
+ proxy_hide_header Cross-Origin-Opener-Policy;
+ proxy_hide_header Cross-Origin-Resource-Policy;
+ proxy_hide_header Content-Security-Policy;
+ proxy_hide_header Content-Security-Policy-Report-Only;
+ proxy_hide_header Access-Control-Allow-Origin;
+
+ # HTTP server (redirect to HTTPS)
+ server {
+ listen 8080;
+ listen [::]:8080;
+ server_name _;
+
+ # Core headers (also on redirects)
+ add_header X-Frame-Options "DENY" always;
+ add_header X-Content-Type-Options "nosniff" always;
+ add_header Referrer-Policy "strict-origin-when-cross-origin" always;
+ add_header Permissions-Policy "camera=(), geolocation=(), microphone=()" always;
+ add_header Cross-Origin-Opener-Policy "same-origin" always;
+ add_header Cross-Origin-Resource-Policy "same-origin" always;
+ add_header Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'" always;
+
+ return 308 https://$host:8443$request_uri;
+ }
+
+ # HTTPS server
+ server {
+ listen 8443 ssl;
+ listen [::]:8443 ssl;
+ http2 on;
+ server_name _;
+
+ ssl_certificate /etc/nginx/certs/localhost.crt;
+ ssl_certificate_key /etc/nginx/certs/localhost.key;
+ ssl_session_timeout 10m;
+ ssl_session_cache shared:SSL:10m;
+ ssl_protocols TLSv1.2 TLSv1.3;
+ ssl_ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:EECDH+AESGCM:EDH+AESGCM";
+ ssl_prefer_server_ciphers on;
+ ssl_stapling off;
+ # If using a publicly-trusted certificate, you may enable OCSP stapling:
+ # ssl_stapling on;
+ # ssl_stapling_verify on;
+ # resolver 1.1.1.1 8.8.8.8 valid=300s;
+ # resolver_timeout 5s;
+ # ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
+
+ client_max_body_size 2m;
+ client_body_timeout 10s;
+ client_header_timeout 10s;
+ keepalive_timeout 10s;
+ send_timeout 10s;
+
+ # Security headers (include HSTS here only)
+ add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
+ add_header X-Frame-Options "DENY" always;
+ add_header X-Content-Type-Options "nosniff" always;
+ add_header Referrer-Policy "strict-origin-when-cross-origin" always;
+ add_header Permissions-Policy "camera=(), geolocation=(), microphone=()" always;
+ add_header Cross-Origin-Opener-Policy "same-origin" always;
+ add_header Cross-Origin-Resource-Policy "same-origin" always;
+ add_header Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data:; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'" always;
+
+ location = /rest/user/login {
+ limit_req zone=login burst=5 nodelay;
+ limit_req_log_level warn;
+ proxy_pass http://juice;
+ }
+
+ location / {
+ proxy_pass http://juice;
+ }
+ }
+}
diff --git a/labs/lab12.md b/labs/lab12.md
new file mode 100644
index 00000000..1bf1af41
--- /dev/null
+++ b/labs/lab12.md
@@ -0,0 +1,401 @@
+# Lab 12 โ Kata Containers: VM-backed Container Sandboxing (Local)
+
+
+
+
+
+> Goal: Run OWASP Juice Shop under Kata Containers to experience VM-backed container isolation, compare it with the default runc runtime, and document security/operational trade-offs.
+> Deliverable: A PR from `feature/lab12` with `labs/submission12.md` containing setup evidence, runtime comparisons (runc vs kata), isolation tests, and a brief performance summary with recommendations.
+
+---
+
+## Overview
+
+In this lab you will practice:
+- Installing/Configuring Kata Containers as a Docker/containerd runtime (Linux)
+- Running the same workload (Juice Shop) with `runc` vs `kata-runtime`
+- Observing isolation differences (guest kernel, process visibility, restricted operations)
+- Measuring basic performance characteristics and trade-offs
+
+> VM-backed sandboxes like Kata place each container/pod inside a lightweight VM, adding a strong isolation boundary while preserving container UX.
+
+---
+
+## Prerequisites
+
+Before starting, ensure you have:
+- โ
Linux host with hardware virtualization enabled (Intel VT-x or AMD-V)
+ - Check: `egrep -c '(vmx|svm)' /proc/cpuinfo` (should return > 0)
+ - Nested virtualization required if running inside a VM
+- โ
containerd (1.7+) and nerdctl (1.7+) with root/sudo privileges
+- โ
`jq`, `curl`, and `awk` installed
+- โ
At least 4GB RAM and 10GB free disk space
+- โ
~60-90 minutes available (installation can take time)
+
+Install containerd + nerdctl (example on Debian/Ubuntu):
+```bash
+sudo apt-get update && sudo apt-get install -y containerd
+sudo containerd config default | sudo tee /etc/containerd/config.toml >/dev/null
+sudo systemctl enable --now containerd
+
+# Install nerdctl (binary)
+VER=2.2.0
+curl -fL -o /tmp/nerdctl.tgz "https://github.com/containerd/nerdctl/releases/download/v${VER}/nerdctl-${VER}-linux-amd64.tar.gz"
+sudo tar -C /usr/local/bin -xzf /tmp/nerdctl.tgz nerdctl && rm /tmp/nerdctl.tgz
+
+containerd --version
+sudo nerdctl --version
+
+# Prepare working directories
+mkdir -p labs/lab12/{setup,runc,kata,isolation,bench,analysis}
+```
+
+If you plan to use the Kata assets installer, ensure `zstd` is available for extracting the release tarball:
+```bash
+sudo apt-get install -y zstd jq
+```
+
+---
+
+## Tasks
+
+### Task 1 โ Install and Configure Kata (2 pts)
+โฑ๏ธ **Estimated time:** 20-30 minutes
+
+**Objective:** Install Kata and make it available to containerd (nerdctl) as `io.containerd.kata.v2`.
+
+#### 1.1: Install Kata
+
+- Build the Kata Rust runtime in a container and copy the shim to your host:
+
+```bash
+# Build inside a Rust container; output goes to labs/lab12/setup/kata-out/
+bash labs/lab12/setup/build-kata-runtime.sh
+
+# Install the shim onto your host PATH (requires sudo)
+sudo install -m 0755 labs/lab12/setup/kata-out/containerd-shim-kata-v2 /usr/local/bin/
+command -v containerd-shim-kata-v2 && containerd-shim-kata-v2 --version | tee labs/lab12/setup/kata-built-version.txt
+```
+
+Notes:
+- The runtime alone is not sufficient; Kata also needs a guest kernel + rootfs image. Prefer your distro packages for these artifacts, or follow the upstream docs to obtain them. If you already have Kata installed, replacing just the shim binary is typically sufficient for this lab.
+
+- Install Kata assets and default config (runtime-rs):
+```bash
+sudo bash labs/lab12/scripts/install-kata-assets.sh # downloads kata-static and wires configuration
+```
+ - If you see an error like "load TOML config failed" when running a Kata container, it means the default configuration file is missing. The script above creates `/etc/kata-containers/runtime-rs/configuration.toml` pointing to the installed defaults.
+
+#### 1.2: Configure containerd + nerdctl
+- Enable `io.containerd.kata.v2` per Kata docs (Kata 3โs shim is `containerd-shim-kata-v2`).
+- Minimal config example for config version 3 (most current containerd):
+```toml
+[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.kata]
+ runtime_type = 'io.containerd.kata.v2'
+```
+ - Legacy configs may use:
+```toml
+[plugins.'io.containerd.grpc.v1.cri'.containerd.runtimes.kata]
+ runtime_type = 'io.containerd.kata.v2'
+```
+
+Automated update (recommended):
+```bash
+sudo bash labs/lab12/scripts/configure-containerd-kata.sh # updates /etc/containerd/config.toml
+```
+- Restart and verify a test container:
+```bash
+sudo systemctl restart containerd
+sudo nerdctl run --rm --runtime io.containerd.kata.v2 alpine:3.19 uname -a
+```
+
+In `labs/submission12.md`, document:
+
+**Task 1 Requirements:**
+- Show the shim `containerd-shim-kata-v2 --version`
+- Show a successful test run with `sudo nerdctl run --runtime io.containerd.kata.v2 ...`
+
+---
+
+### Task 2 โ Run and Compare Containers (runc vs kata) (3 pts)
+โฑ๏ธ **Estimated time:** 15-20 minutes
+
+**Objective:** Run workloads with both runtimes and compare their environments.
+
+#### 2.1: Start runc container (Juice Shop)
+```bash
+# runc (default under nerdctl) - full application
+sudo nerdctl run -d --name juice-runc -p 3012:3000 bkimminich/juice-shop:v19.0.0
+
+# Wait for readiness
+sleep 10
+curl -s -o /dev/null -w "juice-runc: HTTP %{http_code}\n" http://localhost:3012 | tee labs/lab12/runc/health.txt
+```
+
+#### 2.2: Run Kata containers (Alpine-based tests)
+
+> **Note:** Due to a known issue with nerdctl + Kata runtime-rs v3 and long-running detached containers,
+> we'll use short-lived Alpine containers for Kata demonstrations.
+
+```bash
+echo "=== Kata Container Tests ==="
+sudo nerdctl run --rm --runtime io.containerd.kata.v2 alpine:3.19 uname -a | tee labs/lab12/kata/test1.txt
+sudo nerdctl run --rm --runtime io.containerd.kata.v2 alpine:3.19 uname -r | tee labs/lab12/kata/kernel.txt
+sudo nerdctl run --rm --runtime io.containerd.kata.v2 alpine:3.19 sh -c "grep 'model name' /proc/cpuinfo | head -1" | tee labs/lab12/kata/cpu.txt
+```
+
+#### 2.3: Kernel comparison (Key finding)
+
+```bash
+echo "=== Kernel Version Comparison ===" | tee labs/lab12/analysis/kernel-comparison.txt
+echo -n "Host kernel (runc uses this): " | tee -a labs/lab12/analysis/kernel-comparison.txt
+uname -r | tee -a labs/lab12/analysis/kernel-comparison.txt
+
+echo -n "Kata guest kernel: " | tee -a labs/lab12/analysis/kernel-comparison.txt
+sudo nerdctl run --rm --runtime io.containerd.kata.v2 alpine:3.19 cat /proc/version | tee -a labs/lab12/analysis/kernel-comparison.txt
+```
+
+#### 2.4: CPU virtualization check
+
+```bash
+echo "=== CPU Model Comparison ===" | tee labs/lab12/analysis/cpu-comparison.txt
+echo "Host CPU:" | tee -a labs/lab12/analysis/cpu-comparison.txt
+grep "model name" /proc/cpuinfo | head -1 | tee -a labs/lab12/analysis/cpu-comparison.txt
+
+echo "Kata VM CPU:" | tee -a labs/lab12/analysis/cpu-comparison.txt
+sudo nerdctl run --rm --runtime io.containerd.kata.v2 alpine:3.19 sh -c "grep 'model name' /proc/cpuinfo | head -1" | tee -a labs/lab12/analysis/cpu-comparison.txt
+```
+
+In `labs/submission12.md`, document:
+
+**Task 2 Requirements:**
+- Show juice-runc health check (HTTP 200 from port 3012)
+- Show Kata containers running successfully with `--runtime io.containerd.kata.v2`
+- Compare kernel versions:
+ - runc uses host kernel (same as `uname -r`)
+ - Kata uses separate guest kernel (6.12.47 or similar)
+- Compare CPU models (real vs virtualized)
+- Explain isolation implications:
+ - **runc**: ?
+ - **Kata**: ?
+
+---
+
+### Task 3 โ Isolation Tests (3 pts)
+โฑ๏ธ **Estimated time:** 15 minutes
+
+**Objective:** Observe and compare isolation characteristics between runc and Kata.
+
+#### 3.1: Kernel ring buffer (dmesg) access
+
+This demonstrates the most significant isolation difference:
+
+```bash
+echo "=== dmesg Access Test ===" | tee labs/lab12/isolation/dmesg.txt
+
+echo "Kata VM (separate kernel boot logs):" | tee -a labs/lab12/isolation/dmesg.txt
+sudo nerdctl run --rm --runtime io.containerd.kata.v2 alpine:3.19 dmesg 2>&1 | head -5 | tee -a labs/lab12/isolation/dmesg.txt
+```
+
+**Key observation:** Kata containers show VM boot logs, proving they run in a separate kernel.
+
+#### 3.2: /proc filesystem visibility
+
+```bash
+echo "=== /proc Entries Count ===" | tee labs/lab12/isolation/proc.txt
+
+echo -n "Host: " | tee -a labs/lab12/isolation/proc.txt
+ls /proc | wc -l | tee -a labs/lab12/isolation/proc.txt
+
+echo -n "Kata VM: " | tee -a labs/lab12/isolation/proc.txt
+sudo nerdctl run --rm --runtime io.containerd.kata.v2 alpine:3.19 sh -c "ls /proc | wc -l" | tee -a labs/lab12/isolation/proc.txt
+```
+
+#### 3.3: Network interfaces
+
+```bash
+echo "=== Network Interfaces ===" | tee labs/lab12/isolation/network.txt
+
+echo "Kata VM network:" | tee -a labs/lab12/isolation/network.txt
+sudo nerdctl run --rm --runtime io.containerd.kata.v2 alpine:3.19 ip addr | tee -a labs/lab12/isolation/network.txt
+```
+
+#### 3.4: Kernel modules
+
+```bash
+echo "=== Kernel Modules Count ===" | tee labs/lab12/isolation/modules.txt
+
+echo -n "Host kernel modules: " | tee -a labs/lab12/isolation/modules.txt
+ls /sys/module | wc -l | tee -a labs/lab12/isolation/modules.txt
+
+echo -n "Kata guest kernel modules: " | tee -a labs/lab12/isolation/modules.txt
+sudo nerdctl run --rm --runtime io.containerd.kata.v2 alpine:3.19 sh -c "ls /sys/module 2>/dev/null | wc -l" | tee -a labs/lab12/isolation/modules.txt
+```
+
+In `labs/submission12.md`, document:
+
+**Task 3 Requirements:**
+- Show dmesg output differences (Kata shows VM boot logs, proving separate kernel)
+- Compare /proc filesystem visibility
+- Show network interface configuration in Kata VM
+- Compare kernel module counts (host vs guest VM)
+- Explain isolation boundary differences:
+ - **runc**: ?
+ - **kata**: ?
+- Discuss security implications:
+ - Container escape in runc = ?
+ - Container escape in Kata = ?
+
+---
+
+### Task 4 โ Performance Comparison (2 pts)
+โฑ๏ธ **Estimated time:** 10 minutes
+
+**Objective:** Compare startup time and overhead between runc and Kata.
+
+#### 4.1: Container startup time comparison
+
+```bash
+echo "=== Startup Time Comparison ===" | tee labs/lab12/bench/startup.txt
+
+echo "runc:" | tee -a labs/lab12/bench/startup.txt
+time sudo nerdctl run --rm alpine:3.19 echo "test" 2>&1 | grep real | tee -a labs/lab12/bench/startup.txt
+
+echo "Kata:" | tee -a labs/lab12/bench/startup.txt
+time sudo nerdctl run --rm --runtime io.containerd.kata.v2 alpine:3.19 echo "test" 2>&1 | grep real | tee -a labs/lab12/bench/startup.txt
+```
+
+#### 4.2: HTTP response latency (juice-runc only)
+
+```bash
+echo "=== HTTP Latency Test (juice-runc) ===" | tee labs/lab12/bench/http-latency.txt
+out="labs/lab12/bench/curl-3012.txt"
+: > "$out"
+
+for i in $(seq 1 50); do
+ curl -s -o /dev/null -w "%{time_total}\n" http://localhost:3012/ >> "$out"
+done
+
+echo "Results for port 3012 (juice-runc):" | tee -a labs/lab12/bench/http-latency.txt
+awk '{s+=$1; n+=1} END {if(n>0) printf "avg=%.4fs min=%.4fs max=%.4fs n=%d\n", s/n, min, max, n}' \
+ min=$(sort -n "$out" | head -1) max=$(sort -n "$out" | tail -1) "$out" | tee -a labs/lab12/bench/http-latency.txt
+```
+
+In `labs/submission12.md`, document:
+
+**Task 4 Requirements:**
+- Show startup time comparison (runc: <1s, Kata: 3-5s)
+- Show HTTP latency for juice-runc baseline
+- Analyze performance tradeoffs:
+ - **Startup overhead**: ?
+ - **Runtime overhead**: ?
+ - **CPU overhead**: ?
+- Interpret when to use each:
+ - **Use runc when**: ?
+ - **Use Kata when**: ?
+
+---
+
+## Acceptance Criteria
+
+- โ
Kata shim installed and verified (`containerd-shim-kata-v2 --version`)
+- โ
containerd configured; runtime `io.containerd.kata.v2` used for `juice-kata`
+- โ
runc vs kata containers both reachable; environment differences captured
+- โ
Isolation tests executed and results summarized
+- โ
Basic latency snapshot recorded and discussed
+- โ
All artifacts saved under `labs/lab12/` and committed
+
+---
+
+## Known Issues and Troubleshooting
+
+### nerdctl + Kata runtime-rs detached container issue
+
+**Symptom:** Long-running detached containers fail with:
+```
+FATA[0001] failed to create shim task: Others("failed to handle message create container
+Caused by:
+ 0: open stdout
+ 1: No such file or directory (os error 2)
+```
+
+**Root Cause:** Race condition in logging initialization between nerdctl and Kata runtime-rs v3.
+
+**Workarounds:**
+1. Use short-lived/interactive containers (as in this lab)
+2. Use Kubernetes with Kata (fully supported)
+3. Use Docker with older Kata versions
+4. Use containerd's `ctr` command directly
+
+**Status:** Known issue, fix expected in future releases.
+
+### Verifying Kata is working
+
+If you encounter issues, verify Kata basics:
+
+```bash
+# Test simple execution
+sudo nerdctl run --rm --runtime io.containerd.kata.v2 alpine:3.19 echo "Kata works"
+
+# Check kernel version (should be 6.12.47 or similar, NOT your host kernel)
+sudo nerdctl run --rm --runtime io.containerd.kata.v2 alpine:3.19 uname -r
+
+# Check Kata shim
+ls -la /usr/local/bin/containerd-shim-kata-v2
+containerd-shim-kata-v2 --version
+
+# Check containerd logs
+sudo journalctl -u containerd -n 50 --no-pager | grep -i kata
+```
+
+---
+
+## How to Submit
+
+1. Create a branch and push it to your fork:
+```bash
+git switch -c feature/lab12
+# create labs/submission12.md with your findings
+git add labs/lab12/ labs/submission12.md
+git commit -m "docs: add lab12 โ kata containers sandboxing"
+git push -u origin feature/lab12
+```
+2. Open a PR from your forkโs `feature/lab12` โ course repoโs `main`.
+3. In the PR description include:
+```text
+- [x] Task 1 โ Kata install + runtime config
+- [x] Task 2 โ runc vs kata runtime comparison
+- [x] Task 3 โ Isolation tests
+- [x] Task 4 โ Basic performance snapshot
+```
+4. Submit the PR URL via Moodle before the deadline.
+
+---
+
+## Rubric (10 pts)
+
+| Criterion | Points |
+| ------------------------------------------------------ | -----: |
+| Task 1 โ Install + Configure Kata | 2.0 |
+| Task 2 โ Run and Compare (runc vs kata) | 3.0 |
+| Task 3 โ Isolation Tests | 3.0 |
+| Task 4 โ Performance Snapshot | 2.0 |
+| Total | 10.0 |
+
+---
+
+## Guidelines
+
+- Prefer non-privileged containers; avoid `--privileged` unless a test explicitly calls for it
+- Use containerd+nerdctl with `io.containerd.kata.v2` per Kata 3 docs (Docker `--runtime=kata` is legacy)
+- Nested virtualization must be enabled if inside a VM (check your cloud provider or hypervisor settings)
+- Use clear, concise evidence in `submission12.md` and focus your analysis on isolation trade-offs vs operational overhead
+
+
+References
+
+- Kata Containers: https://github.com/kata-containers/kata-containers
+- Install docs (Kata 3): https://github.com/kata-containers/kata-containers/tree/main/docs/install
+- containerd runtime config: https://github.com/kata-containers/kata-containers/tree/main/docs
+
+
diff --git a/labs/lab12/analysis/cpu-comparison.txt b/labs/lab12/analysis/cpu-comparison.txt
new file mode 100644
index 00000000..c5139f57
--- /dev/null
+++ b/labs/lab12/analysis/cpu-comparison.txt
@@ -0,0 +1,5 @@
+=== CPU Model Comparison ===
+Host CPU:
+model name : 12th Gen Intel(R) Core(TM) i5-12450H
+Kata VM CPU:
+model name : Intel(R) Xeon(R) Processor
diff --git a/labs/lab12/analysis/kernel-comparison.txt b/labs/lab12/analysis/kernel-comparison.txt
new file mode 100644
index 00000000..ce556779
--- /dev/null
+++ b/labs/lab12/analysis/kernel-comparison.txt
@@ -0,0 +1,3 @@
+=== Kernel Version Comparison ===
+Host kernel (runc uses this): 6.15.4-200.fc42.x86_64
+Kata guest kernel: Linux version 6.12.47 (@4bcec8f4443d) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04.2) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #1 SMP Fri Nov 14 15:34:06 UTC 2025
diff --git a/labs/lab12/bench/curl-3012.txt b/labs/lab12/bench/curl-3012.txt
new file mode 100644
index 00000000..f1b469d4
--- /dev/null
+++ b/labs/lab12/bench/curl-3012.txt
@@ -0,0 +1,50 @@
+0.000190
+0.000220
+0.000336
+0.000386
+0.000377
+0.000395
+0.000391
+0.000473
+0.000410
+0.000407
+0.000356
+0.000344
+0.000337
+0.000347
+0.000361
+0.000361
+0.000333
+0.000292
+0.000237
+0.000215
+0.000284
+0.000301
+0.000209
+0.000185
+0.000243
+0.000219
+0.000201
+0.000188
+0.000183
+0.000361
+0.000340
+0.000479
+0.000356
+0.000312
+0.000334
+0.000338
+0.000344
+0.000337
+0.000378
+0.000332
+0.000270
+0.000234
+0.000186
+0.000179
+0.000262
+0.000157
+0.000140
+0.000167
+0.000248
+0.000324
diff --git a/labs/lab12/bench/http-latency.txt b/labs/lab12/bench/http-latency.txt
new file mode 100644
index 00000000..ee01510a
--- /dev/null
+++ b/labs/lab12/bench/http-latency.txt
@@ -0,0 +1,3 @@
+=== HTTP Latency Test (juice-runc) ===
+Results for port 3012 (juice-runc):
+avg=0.0003s min=0.0001s max=0.0005s n=50
diff --git a/labs/lab12/bench/startup.txt b/labs/lab12/bench/startup.txt
new file mode 100644
index 00000000..c2aa22db
--- /dev/null
+++ b/labs/lab12/bench/startup.txt
@@ -0,0 +1,10 @@
+=== Startup Time Comparison ===
+runc:
+real 0m0.599s
+user 0m0.013s
+sys 0m0.017s
+
+Kata:
+real 0m6.664s
+user 0m0.012s
+sys 0m0.019s
\ No newline at end of file
diff --git a/labs/lab12/isolation/dmesg.txt b/labs/lab12/isolation/dmesg.txt
new file mode 100644
index 00000000..3461998f
--- /dev/null
+++ b/labs/lab12/isolation/dmesg.txt
@@ -0,0 +1,7 @@
+=== dmesg Access Test ===
+Kata VM (separate kernel boot logs):
+time="2025-11-28T16:28:03+03:00" level=warning msg="cannot set cgroup manager to \"systemd\" for runtime \"io.containerd.kata.v2\""
+[ 0.000000] Linux version 6.12.47 (@4bcec8f4443d) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04.2) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #1 SMP Fri Nov 14 15:34:06 UTC 2025
+[ 0.000000] Command line: reboot=k panic=1 systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service root=/dev/vda1 rootflags=data=ordered,errors=remount-ro ro rootfstype=ext4 agent.container_pipe_size=1 console=ttyS1 agent.log_vport=1025 agent.passfd_listener_port=1027 virtio_mmio.device=8K@0xe0000000:5 virtio_mmio.device=8K@0xe0002000:5
+[ 0.000000] BIOS-provided physical RAM map:
+[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
diff --git a/labs/lab12/isolation/modules.txt b/labs/lab12/isolation/modules.txt
new file mode 100644
index 00000000..653a2968
--- /dev/null
+++ b/labs/lab12/isolation/modules.txt
@@ -0,0 +1,3 @@
+=== Kernel Modules Count ===
+Host kernel modules: 354
+Kata guest kernel modules: 72
diff --git a/labs/lab12/isolation/network.txt b/labs/lab12/isolation/network.txt
new file mode 100644
index 00000000..eec24684
--- /dev/null
+++ b/labs/lab12/isolation/network.txt
@@ -0,0 +1,14 @@
+=== Network Interfaces ===
+Kata VM network:
+1: lo: mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
+ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
+ inet 127.0.0.1/8 scope host lo
+ valid_lft forever preferred_lft forever
+ inet6 ::1/128 scope host noprefixroute
+ valid_lft forever preferred_lft forever
+2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
+ link/ether 7a:70:25:f0:55:84 brd ff:ff:ff:ff:ff:ff
+ inet 10.4.0.13/24 brd 10.4.0.255 scope global eth0
+ valid_lft forever preferred_lft forever
+ inet6 fe80::7870:25ff:fef0:5584/64 scope link tentative
+ valid_lft forever preferred_lft forever
diff --git a/labs/lab12/isolation/proc.txt b/labs/lab12/isolation/proc.txt
new file mode 100644
index 00000000..0ba079bd
--- /dev/null
+++ b/labs/lab12/isolation/proc.txt
@@ -0,0 +1,3 @@
+=== /proc Entries Count ===
+Host: 528
+Kata VM: 53
diff --git a/labs/lab12/kata/cpu.txt b/labs/lab12/kata/cpu.txt
new file mode 100644
index 00000000..042f3e32
--- /dev/null
+++ b/labs/lab12/kata/cpu.txt
@@ -0,0 +1 @@
+model name : Intel(R) Xeon(R) Processor
diff --git a/labs/lab12/kata/kernel.txt b/labs/lab12/kata/kernel.txt
new file mode 100644
index 00000000..785c4624
--- /dev/null
+++ b/labs/lab12/kata/kernel.txt
@@ -0,0 +1 @@
+6.12.47
diff --git a/labs/lab12/kata/test1.txt b/labs/lab12/kata/test1.txt
new file mode 100644
index 00000000..3d2aa533
--- /dev/null
+++ b/labs/lab12/kata/test1.txt
@@ -0,0 +1 @@
+Linux 1ab865e5ba28 6.12.47 #1 SMP Fri Nov 14 15:34:06 UTC 2025 x86_64 Linux
diff --git a/labs/lab12/runc/health.txt b/labs/lab12/runc/health.txt
new file mode 100644
index 00000000..9bb7599c
--- /dev/null
+++ b/labs/lab12/runc/health.txt
@@ -0,0 +1 @@
+juice-runc: HTTP 000
diff --git a/labs/lab12/scripts/configure-containerd-kata.sh b/labs/lab12/scripts/configure-containerd-kata.sh
new file mode 100755
index 00000000..163133af
--- /dev/null
+++ b/labs/lab12/scripts/configure-containerd-kata.sh
@@ -0,0 +1,94 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# configure-containerd-kata.sh
+# Idempotently ensure containerd has the Kata runtime configured:
+# [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
+# runtime_type = "io.containerd.kata.v2"
+#
+# Usage:
+# sudo bash labs/lab12/scripts/configure-containerd-kata.sh
+
+CONF_DEFAULT="/etc/containerd/config.toml"
+# Allow override via $CONF or first CLI arg
+CONF="${CONF:-${1:-$CONF_DEFAULT}}"
+TMP=$(mktemp)
+
+backup() {
+ if [ -f "$CONF" ]; then
+ cp -a "$CONF" "${CONF}.$(date +%Y%m%d%H%M%S).bak"
+ fi
+}
+
+ensure_default() {
+ if [ ! -s "$CONF" ]; then
+ echo "Generating default containerd config at $CONF" >&2
+ mkdir -p "$(dirname "$CONF")"
+ containerd config default > "$CONF"
+ fi
+}
+
+detect_header() {
+ # Prefer v3 split-CRI path if present; otherwise fallback to grpc path
+ if grep -q "^\[plugins\.'io\.containerd\.cri\.v1\.runtime'\]" "$CONF"; then
+ echo "[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.kata]"
+ else
+ echo "[plugins.'io.containerd.grpc.v1.cri'.containerd.runtimes.kata]"
+ fi
+}
+
+insert_or_update_kata() {
+ local header
+ header=$(detect_header)
+ local value=" runtime_type = 'io.containerd.kata.v2'"
+
+ # Process file: update runtime_type inside the kata table if it exists,
+ # otherwise append a new table at the end.
+ awk -v hdr="$header" -v val="$value" '
+ BEGIN { inside=0; updated=0 }
+ {
+ if ($0 == hdr) {
+ print $0; inside=1; next
+ }
+ if (inside) {
+ if ($0 ~ /^\[/) {
+ if (!updated) print val
+ inside=0
+ print $0
+ next
+ }
+ if ($0 ~ /^\s*runtime_type\s*=\s*/){
+ print val; updated=1; next
+ }
+ print $0; next
+ }
+ print $0
+ }
+ END {
+ if (inside && !updated) {
+ print val
+ } else if (!inside && NR > 0) {
+ # Check if header ever appeared; if not, append it.
+ # We can infer by searching the output later, but simpler: do a second pass.
+ }
+ }
+ ' "$CONF" > "$TMP"
+
+ if ! grep -qF "$header" "$TMP"; then
+ {
+ printf '\n%s\n%s\n' "$header" "$value"
+ } >> "$TMP"
+ fi
+
+ install -m 0644 "$TMP" "$CONF"
+}
+
+main() {
+ backup
+ ensure_default
+ insert_or_update_kata
+ echo "Updated $CONF with Kata runtime: io.containerd.kata.v2" >&2
+ echo "Restart containerd to apply: sudo systemctl restart containerd" >&2
+}
+
+main "$@"
diff --git a/labs/lab12/scripts/install-kata-assets.sh b/labs/lab12/scripts/install-kata-assets.sh
new file mode 100755
index 00000000..c3c586d9
--- /dev/null
+++ b/labs/lab12/scripts/install-kata-assets.sh
@@ -0,0 +1,79 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# install-kata-assets.sh
+# Download and install Kata Containers static assets (kernel, rootfs image,
+# default runtime-rs configuration) under /opt/kata, and ensure a
+# configuration file exists in an expected path for runtime-rs.
+#
+# Usage:
+# sudo bash labs/lab12/scripts/install-kata-assets.sh [KATA_VER]
+#
+# Notes:
+# - Requires: curl, jq, tar (with zstd support), and root privileges.
+# - Creates or updates a symlink at:
+# /etc/kata-containers/runtime-rs/configuration.toml
+# pointing to the installed default configuration.
+
+VER_ARG=${1:-}
+ARCH=$(uname -m)
+case ${ARCH} in
+ x86_64) ARCH=amd64 ;;
+ aarch64|arm64) ARCH=arm64 ;;
+ *) echo "Unsupported architecture: $(uname -m)" >&2; exit 1 ;;
+esac
+
+if [[ -n "${VER_ARG}" ]]; then
+ KATA_VER=$(echo "${VER_ARG}" | sed -E 's/^v//')
+else
+ KATA_VER=$(curl -fsSL https://api.github.com/repos/kata-containers/kata-containers/releases/latest | jq -r .tag_name)
+ KATA_VER=${KATA_VER#v}
+fi
+
+ASSET_URL="https://github.com/kata-containers/kata-containers/releases/download/${KATA_VER}/kata-static-${KATA_VER}-${ARCH}.tar.zst"
+
+echo "Installing Kata static assets ${KATA_VER} for ${ARCH}" >&2
+TMP_TAR=$(mktemp --suffix=.tar.zst)
+curl -fL -o "${TMP_TAR}" "${ASSET_URL}"
+
+# Extract to root; archive lays files under /opt/kata, /usr/local/bin, etc.
+# Prefer explicit decompressor if available to avoid tar invoking external zstd unexpectedly.
+if command -v zstd >/dev/null 2>&1; then
+ zstd -d -c "${TMP_TAR}" | tar -xf - -C /
+elif command -v unzstd >/dev/null 2>&1; then
+ unzstd -c "${TMP_TAR}" | tar -xf - -C /
+elif tar --help 2>/dev/null | grep -q -- '--zstd'; then
+ tar --zstd -xf "${TMP_TAR}" -C /
+else
+ echo "Missing zstd support to extract ${TMP_TAR}." >&2
+ echo "Install the zstd package (e.g., sudo apt-get update && sudo apt-get install -y zstd) and re-run." >&2
+ exit 1
+fi
+rm -f "${TMP_TAR}"
+
+# Link configuration to an expected path for runtime-rs
+sudo mkdir -p /etc/kata-containers/runtime-rs
+SRC_CANDIDATES=(
+ "/opt/kata/share/defaults/kata-containers/runtime-rs/configuration-dragonball.toml"
+ "/opt/kata/share/defaults/kata-containers/configuration-dragonball.toml"
+ "/opt/kata/share/defaults/kata-containers/runtime-rs/configuration.toml"
+ "/usr/share/defaults/kata-containers/runtime-rs/configuration.toml"
+)
+
+for src in "${SRC_CANDIDATES[@]}"; do
+ if [[ -f "$src" ]]; then
+ ln -sf "$src" /etc/kata-containers/runtime-rs/configuration.toml
+ echo "Linked runtime-rs config -> $src" >&2
+ break
+ fi
+done
+
+if [[ ! -f /etc/kata-containers/runtime-rs/configuration.toml ]]; then
+ echo "Warning: could not find a default runtime-rs configuration in known locations." >&2
+ echo "Check /opt/kata/share/defaults/kata-containers/ and create: /etc/kata-containers/runtime-rs/configuration.toml" >&2
+ exit 1
+fi
+
+echo "Kata assets installed. Restart containerd and test a kata container." >&2
+echo " sudo systemctl restart containerd" >&2
+echo " sudo nerdctl run --rm --runtime io.containerd.kata.v2 alpine:3.19 uname -a" >&2
diff --git a/labs/lab12/setup/build-kata-runtime.sh b/labs/lab12/setup/build-kata-runtime.sh
new file mode 100644
index 00000000..b909a410
--- /dev/null
+++ b/labs/lab12/setup/build-kata-runtime.sh
@@ -0,0 +1,56 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Build Kata Containers 3.x Rust runtime (containerd-shim-kata-v2)
+# inside a temporary Rust toolchain container, and place the binary
+# into the provided output directory. This avoids installing build
+# dependencies on the host.
+#
+# Usage:
+# bash labs/lab12/setup/build-kata-runtime.sh
+# # result: labs/lab12/setup/kata-out/containerd-shim-kata-v2
+
+ROOT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")"/../.. && pwd)"
+WORK_DIR="${ROOT_DIR}/lab12/setup/kata-build"
+OUT_DIR="${ROOT_DIR}/lab12/setup/kata-out"
+
+mkdir -p "${WORK_DIR}" "${OUT_DIR}"
+
+echo "Building Kata runtime in Docker..." >&2
+docker run --rm \
+ -e CARGO_NET_GIT_FETCH_WITH_CLI=true \
+ -v "${WORK_DIR}":/work \
+ -v "${OUT_DIR}":/out \
+ rust:1.75-bookworm bash -lc '
+ set -euo pipefail
+ apt-get update && apt-get install -y --no-install-recommends \
+ git make gcc pkg-config ca-certificates musl-tools libseccomp-dev && \
+ update-ca-certificates || true
+
+ # Ensure cargo/rustup are available
+ export PATH=/usr/local/cargo/bin:$PATH
+ rustc --version; cargo --version; rustup --version || true
+
+ cd /work
+ if [ ! -d kata-containers ]; then
+ git clone --depth 1 https://github.com/kata-containers/kata-containers.git
+ fi
+ cd kata-containers/src/runtime-rs
+
+ # Add MUSL target for static build expected by runtime Makefile
+ rustup target add x86_64-unknown-linux-musl || true
+
+ # Build the runtime (shim v2)
+ make
+
+ # Collect the produced binary
+ f=$(find target -type f -name containerd-shim-kata-v2 | head -n1)
+ if [ -z "$f" ]; then
+ echo "ERROR: built binary not found" >&2; exit 1
+ fi
+ install -m 0755 "$f" /out/containerd-shim-kata-v2
+ strip /out/containerd-shim-kata-v2 || true
+ /out/containerd-shim-kata-v2 --version || true
+ '
+
+echo "Done. Binary saved to: ${OUT_DIR}/containerd-shim-kata-v2" >&2
diff --git a/labs/lab12/setup/kata-build/kata-containers b/labs/lab12/setup/kata-build/kata-containers
new file mode 160000
index 00000000..8534afb9
--- /dev/null
+++ b/labs/lab12/setup/kata-build/kata-containers
@@ -0,0 +1 @@
+Subproject commit 8534afb9e8de3a529a537185f0fd55b66d9bc5d5
diff --git a/labs/lab12/setup/kata-built-version.txt b/labs/lab12/setup/kata-built-version.txt
new file mode 100644
index 00000000..e1948b53
--- /dev/null
+++ b/labs/lab12/setup/kata-built-version.txt
@@ -0,0 +1 @@
+Kata Containers containerd shim (Rust): id: io.containerd.kata.v2, version: 3.23.0, commit: 8534afb9e8de3a529a537185f0fd55b66d9bc5d5
diff --git a/labs/lab12/setup/kata-out/containerd-shim-kata-v2 b/labs/lab12/setup/kata-out/containerd-shim-kata-v2
new file mode 100755
index 00000000..c8cad3d4
Binary files /dev/null and b/labs/lab12/setup/kata-out/containerd-shim-kata-v2 differ
diff --git a/labs/lab2.md b/labs/lab2.md
index 5e48d666..e66fb964 100644
--- a/labs/lab2.md
+++ b/labs/lab2.md
@@ -1,181 +1,189 @@
-# Lab 2 โ Threat Modeling (Threat Dragon + Threagile)
+# Lab 2 โ Threat Modeling with Threagile
-
+-blue)
-> **Goal:** Model the **OWASP Juice Shop `bkimminich/juice-shop:19.0.0`** deployment, identify top risks, and produce both a **diagram-first** and an **automation-first** threat model.
-> **Deliverable:** A PR from `feature/lab2` with a Threat Dragon model + Threagile outputs and a short risk summary.
+> **Goal:** Model OWASP Juice Shop (`bkimminich/juice-shop:v19.0.0`) deployment and generate an automation-first threat model with Threagile.
+> **Deliverable:** A PR from `feature/lab2` to the course repo with `labs/submission2.md` containing Threagile outputs and risk analysis. Submit the PR link via Moodle.
---
## Overview
In this lab you will practice:
+- Creating an **as-code** model with **Threagile** and automatically generating **risk reports + diagrams** from YAML
+- Making security-relevant model changes and demonstrating how they **impact the risk landscape**
+- Analyzing threat model outputs and documenting security findings systematically
-* Building a **data flow diagram (DFD)** and capturing threats with **OWASP Threat Dragon** (supports STRIDE and auto-suggests threats via a rule engine).
-* Creating an **as-code** model with **Threagile** to automatically generate a **risk report + diagrams** from YAML (great for CI).
-
-> Keep using the Juice Shop from Lab 1 (`:19.0.0`).
+> Keep using the Juice Shop from Lab 1 (`:19.0.0`) as your target application.
---
## Tasks
-### Task 1 โ Threagile model & automated report (2 pts)
-
-**Objective:** Use the provided Threagile model to generate a PDF report + diagrams and document the results in `labs/submission2.md`.
-
-1. **Use the provided YAML**
-
-- `labs/lab2/threagile-model.yaml` is provided. Do not restructure it for this task.
-- You may make a small change for the โDelta Runโ step (e.g., switch one link to HTTPS).
-
-2. **Generate outputs (risks + diagrams + PDF)**
-
-Run Threagile against the model and write all artifacts into `lab2`:
+### Task 1 โ Threagile Baseline Model (6 pts)
- ```bash
- docker run --rm -it -v "$(pwd)":/app/work threagile/threagile \
- -verbose \
- -model /app/work/labs/labs/lab2/threagile-model.yaml \
- -output /app/work/labs/lab2 \
- -generate-risks-excel=false \
- -generate-tags-excel=false
- ```
+**Objective:** Use the provided Threagile model to generate a PDF report + diagrams and analyze the baseline risk posture.
-What you get in `labs/lab2/`:
+#### 1.1: Generate Baseline Threat Model
-- `report.pdf` โ full PDF report (includes diagrams) generated by default.
-- Diagrams: data-flow & data-asset diagrams (PNG).
-- Risk outputs: `risks.json` and also `stats.json`, `technical-assets.json`.
+```bash
+mkdir -p labs/lab2/baseline labs/lab2/secure
-3. **Create `labs/submission2.md`**
+docker run --rm -v "$(pwd)":/app/work threagile/threagile \
+ -model /app/work/labs/lab2/threagile-model.yaml \
+ -output /app/work/labs/lab2/baseline \
+ -generate-risks-excel=false -generate-tags-excel=false
+```
-Include the following sections:
+#### 1.2: Verify Generated Outputs
-- Top 5 Risks (from `labs/lab2/risks.json`): create a table with columns โ Severity, Category, Asset, Likelihood, Impact.
- - Ranking: Sort risks by these weights to pick the Top 5:
- - Severity order: critical (5) > elevated (4) > high (3) > medium (2) > low (1)
- - Likelihood order: very-likely (4) > likely (3) > possible (2) > unlikely (1)
- - Impact order: high (3) > medium (2) > low (1)
- - Composite score = Severity*100 + Likelihood*10 + Impact. Sort descending; use score to break ties.
- - Practical way:
- - Manual read: open `labs/lab2/risks.json`, scan fields `severity`, `exploitation_likelihood`, `exploitation_impact`, `category`, `most_relevant_technical_asset`, apply the weights above, and pick the top 5.
-- **Delta Run**: change one thing in the YAML (e.g., set Reverse Proxy โ App link to HTTPS), re-run, and paste a before/after of the relevant counts (e.g., unencrypted-communication dropped). Add a one-sentence reason why.
+Expected files in `labs/lab2/baseline/`:
+- `report.pdf` โ full PDF report (includes diagrams)
+- Diagrams: data-flow & data-asset diagrams (PNG)
+- Risk exports: `risks.json`, `stats.json`, `technical-assets.json`
-4. **Deliverables**
+#### 1.3: Risk Analysis and Documentation
-Commit/push:
+Calculate composite scores using these weights:
+- Severity: critical (5) > elevated (4) > high (3) > medium (2) > low (1)
+- Likelihood: very-likely (4) > likely (3) > possible (2) > unlikely (1)
+- Impact: high (3) > medium (2) > low (1)
+- **Composite score** = `Severity*100 + Likelihood*10 + Impact`
-- `labs/lab2/threagile-model.yaml`
-- `labs/lab2/*diagram*.png` (at least the data-flow diagram)
-- `labs/submission2.md` (the write-up described above)
+In `labs/submission2.md`, document:
+- **Top 5 Risks** table with Severity, Category, Asset, Likelihood, Impact
+- Risk ranking methodology and composite score calculations
+- Analysis of critical security concerns identified
+- Screenshots or references to generated diagrams
-5. **Quality checklist (pass/fail hints)**
+---
-- Report opens and diagrams render.
-- Top 5 risks table present and legible; ties broken sensibly.
-- Stats snapshot included (from `stats.json`).
-- Clear overlap/difference vs Threat Dragon.
-- Delta Run shows before/after evidence and a short explanation.
+### Task 2 โ HTTPS Variant & Risk Comparison (4 pts)
+
+**Objective:** Create a secure variant of the model and demonstrate how security controls affect the threat landscape.
+
+#### 2.1: Create Secure Model Variant
+
+Copy the baseline model and make these specific changes:
+- **User Browser โ communication_links โ Direct to App**: set `protocol: https`
+- **Reverse Proxy โ communication_links**: set `protocol: https`
+- **Persistent Storage**: set `encryption: transparent`
+- Save as: `labs/lab2/threagile-model.secure.yaml`
+
+#### 2.2: Generate Secure Variant Analysis
+
+```bash
+docker run --rm -v "$(pwd)":/app/work threagile/threagile \
+ -model /app/work/labs/lab2/threagile-model.secure.yaml \
+ -output /app/work/labs/lab2/secure \
+ -generate-risks-excel=false -generate-tags-excel=false
+```
+
+#### 2.3: Generate Risk Comparison
+
+```bash
+jq -n \
+ --slurpfile b labs/lab2/baseline/risks.json \
+ --slurpfile s labs/lab2/secure/risks.json '
+def tally(x):
+(x | group_by(.category) | map({ (.[0].category): length }) | add) // {};
+(tally($b[0])) as $B |
+(tally($s[0])) as $S |
+(($B + $S) | keys | sort) as $cats |
+[
+"| Category | Baseline | Secure | ฮ |",
+"|---|---:|---:|---:|"
+] + (
+$cats | map(
+"| " + . + " | " +
+(($B[.] // 0) | tostring) + " | " +
+(($S[.] // 0) | tostring) + " | " +
+(((($S[.] // 0) - ($B[.] // 0))) | tostring) + " |"
+)
+) | .[]'
+```
+
+In `labs/submission2.md`, document:
+- **Risk Category Delta Table** (Baseline vs Secure vs ฮ)
+- **Delta Run Explanation** covering:
+ - Specific changes made to the model
+ - Observed results in risk categories
+ - Analysis of why these changes reduced/modified risks
+- Comparison of diagrams between baseline and secure variants
-> Resources: Threagile site (auto risk rules, diagrams, CI-friendly), CLI usage (Docker examples), sample outputs. ([threagile.io][3], [GitHub][6], [juanvvc.github.io][4])
---
-### Task 2 โ Threat Dragon Web Model (4 pts)
+## How to Submit
-**Objective:** Create a diagram-based threat model of your local Juice Shop setup using the web UI at `threatdragon.com`, and extract the top 5 risks.
+1. Create a branch for this lab and push it to your fork:
-1. **Use the Threat Dragon web UI**
- - Go to `threatdragon.com` โ New Model (GitHub login required).
- - Select a repo/branch where models are stored (optional).
- - Provide metadata: title = โJuice Shop Labโ, owner = your GitHub handle.
- - Add a diagram: place trust boundaries, actors, components, and flows.
- - Assign STRIDE categories to each element/flow (via the properties pane).
- - Run the rule engine and review auto-generated threats.
- - Triage: keep, edit, or drop threats. Add mitigation notes (e.g., TLS via proxy, authz on sensitive routes, rate limiting).
+ ```bash
+ git switch -c feature/lab2
+ # create labs/submission2.md with your findings
+ git add labs/submission2.md labs/lab2/
+ git commit -m "docs: add lab2 submission"
+ git push -u origin feature/lab2
+ ```
-2. **Model the deployment (minimum elements)**
- - **Actors:** User (Browser), Attacker (Internet)
- - **Components:** Reverse Proxy (optional), Juice Shop Container (`:19.0.0`), Persistent Storage (e.g., container volume), Email/SMS provider (if configured)
- - **Flows:**
- - `HTTP 3000/tcp` Browser โ Juice Shop (or Browser โ Proxy โ Juice Shop)
- - Outbound flows from Juice Shop (Email/SMS API, webhook, etc.)
- - Persistent storage โ Juice Shop
- - **Trust Boundaries:** Internet โข Host; Host โข Container Network
+2. Open a PR from your fork's `feature/lab2` branch โ **course repository's main branch**.
-3. **Folder & files**
- - Create in your repo:
- - `labs/lab2/threat-dragon.json` โ download/export the JSON model from the web UI.
- - `labs/lab2/dfd.png` โ export your diagram as PNG/SVG.
- - `labs/lab2/THREATS.md` โ markdown summary of your top risks.
+3. In the PR description, include:
-4. **Write `labs/lab2/THREATS.md`**
- - **Top 5 risks:** one-liners with STRIDE tags (e.g., โInjection [Tampering] โ unsanitized input can corrupt DBโ).
- - Cross-check vs Threagile: 2 overlaps + 1 difference (one-liners).
+ ```text
+ - [x] Task 1 done โ Threagile baseline model + risk analysis
+ - [x] Task 2 done โ HTTPS variant + risk comparison
+ ```
-> Resources: Threat Dragon docs & project page (DFDs, STRIDE, rule engine, desktop/web options).
+4. **Copy the PR URL** and submit it via **Moodle before the deadline**.
---
-### Bonus โ GitHub Social Interactions (optional)
-
-**Objective**: Explore GitHubโs social features and how they support collaboration.
+## Acceptance Criteria
-1. Star the course repository.
-2. Follow your professor, TAs, and at least 3 classmates.
-3. In `labs/submission2.md`, add 1โ2 sentences on why stars/follows matter in open source and team projects.
+- โ
Branch `feature/lab2` exists with commits for each task
+- โ
File `labs/submission2.md` contains required analysis for Tasks 1-2
+- โ
Threagile baseline and secure models successfully generated
+- โ
Both `labs/lab2/baseline/` and `labs/lab2/secure/` folders contain complete outputs
+- โ
Top 5 risks analysis and risk category delta comparison documented
+- โ
PR from `feature/lab2` โ **course repo main branch** is open
+- โ
PR link submitted via Moodle before the deadline
---
-### Acceptance Criteria
+## Rubric (10 pts)
-* โ
`labs/lab2/threat-dragon.json` exported and `labs/lab2/dfd.png` exported (diagram shows actors, Juice Shop container, flows, and trust boundaries).
-* โ
`labs/lab2/THREATS.md` lists **Top 5** STRIDE-tagged risks.
-* โ
`labs/lab2/threagile-model.yaml` models the same architecture at a reasonable fidelity.
-* โ
`labs/lab2/*diagram*.png` includes at least the data-flow diagram.
-* โ
`labs/submission2.md` includes: Artifacts list, Top 5 risks table, Stats snapshot, 2 overlaps + 1 difference Threagile vs Threat Dragon, and a Delta Run with before/after evidence.
-* โ
PR from `feature/lab2` โ `main` is open with artifacts attached/linked in the description.
+| Criterion | Points |
+| ------------------------------------------------------------ | -----: |
+| Task 1 โ Threagile baseline model + risk analysis | **6** |
+| Task 2 โ HTTPS variant + risk comparison analysis | **4** |
+| **Total** | **10** |
---
-## How to Submit
+## Guidelines
-1. Create `feature/lab2`, commit the new files, push, and open a PR.
-2. In the PR description, fill your template sections and include:
+- Use clear Markdown headers to organize sections in `submission2.md`
+- Include both command outputs and written analysis for each task
+- Document threat modeling process and security findings systematically
+- Ensure all generated artifacts are properly committed to the repository
- ```text
- - [x] Task 1: Threagile YAML + report + diagrams + submission2.md
- - [x] Task 2: Threat Dragon model + THREATS.md
- ```
+
+Threat Modeling Notes
----
+- Model exactly the architecture you're running from Lab 1 (localhost deployment)
+- Use consistent asset/link names between baseline and secure models for accurate diffs
+- Focus on actionable security insights rather than comprehensive risk catalogs
-## Rubric (10 pts)
+
-| Criterion | Points |
-| ------------------------------------------------------------------ | -----: |
-| Task 1 โ Threat Dragon DFD + **Top 5** risks in `THREATS.md` | **6** |
-| Task 2 โ Threagile YAML + generated report/diagrams + submission2 | **4** |
-| **Total** | **10** |
+
+Technical Tips
----
-
-## Hints
-
-> ๐งญ **Model the lab reality.** Use exactly the architecture youโre running from Lab 1 (localhost, optional proxy).
-> ๐ง **Threat Dragon tip:** Start with STRIDE per **flow** first (S/T/I for auth, R/E for data tampering/DoS), then per **asset**. The toolโs rule engine can suggest threats you can triage. ([OWASP][5])
-> โ๏ธ **Threagile flags:** You can generate a stub (`-create-stub-model`), list enums (`-list-types`), and run analysis with `-model ... -output ...`; it emits report/DFDs and risk exportsโhandy for CI. ([Go Packages][1], [Kali Linux Tutorials][2])
-> ๐ **Keep it short:** One-page summaries beat walls of textโuse bullets and link the artifacts.
-> ๐ **Consistent IDs:** Use the same risk names/IDs across both tasks where they overlapโthis helps later when we create CI gates and dashboards.
-
----
+- Verify report PDFs open correctly and diagrams render properly
+- Use the provided jq command exactly as shown for consistent delta tables
+- Keep explanations conciseโone-page summaries are more valuable than detailed reports
+- Check that Threagile Docker container has proper file permissions for output generation
-[1]: https://pkg.go.dev/github.com/threagile/threagile?utm_source=chatgpt.com "threagile command - github.com/threagile/threagile - Go ... - Go Packages"
-[2]: https://kalilinuxtutorials.com/threagile/?utm_source=chatgpt.com "Threagile : Agile Threat Modeling Toolkit 2020!Kalilinuxtutorials"
-[3]: https://threagile.io/?utm_source=chatgpt.com "Threagile โ Agile Threat Modeling Toolkit"
-[4]: https://juanvvc.github.io/securecoding/images/threatmod/threagile/report.pdf?utm_source=chatgpt.com "Threat Model Report: Some Example Application"
-[5]: https://owasp.org/www-project-threat-dragon/?utm_source=chatgpt.com "OWASP Threat Dragon"
-[6]: https://github.com/Threagile/threagile "GitHub - Threagile/threagile: Agile Threat Modeling Toolkit"
-[7]: https://github.com/Threagile/threagile/blob/master/demo/example/threagile.yaml "threagile/demo/example/threagile.yaml at master - GitHub"
+
diff --git a/labs/lab2/threagile-model.yaml b/labs/lab2/threagile-model.yaml
index aa0f6b18..85c01a79 100644
--- a/labs/lab2/threagile-model.yaml
+++ b/labs/lab2/threagile-model.yaml
@@ -1,76 +1,60 @@
threagile_version: 1.0.0
-title: OWASP Juice Shop โ Local Lab Threat Model
-date: 2025-09-07
+title: OWASP Juice Shop โ Local Lab Threat Model
+date: 2025-09-18
author:
name: Student Name
homepage: https://example.edu
management_summary_comment: >
- Threat model for a local OWASP Juice Shop setup. Users access the app
- either directly on HTTP 3000/tcp or via an optional reverse proxy that
- terminates TLS and adds security headers. The app runs in a container
- and may write to a host-mounted volume. Optional outbound notifications
- use an external Email/SMS provider or generic webhook endpoints.
+ Threat model for a local OWASP Juice Shop setup. Users access the app
+ either directly via HTTP on port 3000 or through an optional reverse proxy that
+ terminates TLS and adds security headers. The app runs in a container
+ and writes data to a host-mounted volume (for database, uploads, logs).
+ Optional outbound notifications (e.g., a challenge-solution WebHook) can be configured for integrations.
-business_criticality: important # archive, operational, important, critical, mission-critical
+business_criticality: important # archive, operational, important, critical, mission-critical
business_overview:
description: >
- Training environment for DevSecOps. The goal is to model risks for a
- deliberately vulnerable web app (OWASP Juice Shop) running locally in
- a container. Focus on minimal architecture, STRIDE thinking, and
- actionable mitigations.
+ Training environment for DevSecOps. This model covers a deliberately vulnerable
+ web application (OWASP Juice Shop) running locally in a Docker container. The focus is on a minimal architecture, STRIDE threat analysis, and actionable mitigations for the identified risks.
images:
- # - dfd.png: Data Flow Diagram exported from the tool
+ # - dfd.png: Data Flow Diagram (if exported from the tool)
technical_overview:
description: >
- Browser (user) connects to Juice Shop (Node.js) on localhost:3000
- or via a reverse proxy on 443/80. Juice Shop can call external
- services (Email/SMS provider, webhooks). Logs and files may persist
- on a host volume. Trust boundaries: Internet โ Host โ Container network.
+ A userโs web browser connects to the Juice Shop application (Node.js/Express server) either directly on **localhost:3000** (HTTP) or via a **reverse proxy** on ports 80/443 (with HTTPS). The Juice Shop server may issue outbound requests to external services (e.g., a configured **WebHook** for solved challenge notifications). All application data (the SQLite database, file uploads, logs) is stored on the hostโs filesystem via a mounted volume. Key trust boundaries include the **Internet** (user & external services) โ **Host** (local machine/VM) โ **Container Network** (isolated app container).
images: []
questions:
Do you expose port 3000 beyond localhost?: ""
Do you use a reverse proxy with TLS and security headers?: ""
- Are outbound notifications (email/webhook) configured?: ""
+ Are any outbound integrations (webhooks) configured?: ""
Is any sensitive data stored in logs or files?: ""
abuse_cases:
Credential Stuffing / Brute Force: >
- Attackers attempt repeated logins to exhaust resources or guess valid credentials.
+ Attackers attempt repeated login attempts to guess credentials or exhaust system resources.
Stored XSS via Product Reviews: >
- Malicious payloads stored and executed in other users' browsers.
- SSRF via Webhook Targets: >
- Outbound webhooks abused to pivot to internal endpoints.
+ Malicious scripts are inserted into product reviews, getting stored and executed in other usersโ browsers.
+ SSRF via Outbound Requests: >
+ Server-side requests (e.g. profile image URL fetch or WebHook callback) are abused to access internal network resources.
security_requirements:
- TLS in transit: Enforce HTTPS for user traffic via reverse proxy with strong ciphers.
- AuthZ on sensitive routes: Enforce role/permission checks server-side.
- Rate limiting & lockouts: Prevent brute force/login abuse; protect expensive endpoints.
- Secure headers: Add HSTS, CSP, X-Frame-Options, X-Content-Type-Options at proxy.
- Secrets management: Keep tokens/credentials out of repo and logs.
+ TLS in transit: Enforce HTTPS for user traffic via a TLS-terminating reverse proxy with strong ciphers and certificate management.
+ AuthZ on sensitive routes: Implement strict server-side authorization checks (role/permission) on admin or sensitive functionalities.
+ Rate limiting & lockouts: Apply rate limiting and account lockout policies to mitigate brute-force and automated attacks on authentication and expensive operations.
+ Secure headers: Add security headers (HSTS, CSP, X-Frame-Options, X-Content-Type-Options, etc.) at the proxy or app to mitigate client-side attacks.
+ Secrets management: Protect secret keys and credentials (JWT signing keys, OAuth client secrets) โ keep them out of code repos and avoid logging them.
-# Tags are optional helpers; keep as-is or extend
tags_available:
- # infra / tools
+ # Relevant technologies and environment tags
- docker
- - git
- - kubernetes
- nodejs
- - tomcat
- - aws
- - aws:iam
- - aws:rds
- - aws:s3
- - gcp
- - azure
-
- # from your model (data & assets)
+ # Data and asset tags
- pii
- auth
- tokens
@@ -78,23 +62,18 @@ tags_available:
- public
- actor
- user
- - attacker
- optional
- proxy
- app
- storage
- volume
- saas
- - notifications
- webhook
+ # Communication tags
- primary
- direct
- egress
- # leftovers from the stub (optional to keep or remove)
- - some-tag
- - some-other-tag
-
# =========================
# DATA ASSETS
# =========================
@@ -102,9 +81,9 @@ data_assets:
User Accounts:
id: user-accounts
- description: "Profiles, credential hashes, emails."
+ description: "User profile data, credential hashes, emails."
usage: business
- tags: ["pii","auth"]
+ tags: ["pii", "auth"]
origin: user-supplied
owner: Lab Owner
quantity: many
@@ -112,11 +91,11 @@ data_assets:
integrity: critical
availability: important
justification_cia_rating: >
- PII and auth data require confidentiality; integrity critical to prevent takeover.
+ Contains personal identifiers and authentication data. High confidentiality is required to protect user privacy, and integrity is critical to prevent account takeovers.
Orders:
id: orders
- description: "Order history, addresses, payment metadata (no PAN stored)."
+ description: "Order history, addresses, and payment metadata (no raw card numbers)."
usage: business
tags: ["pii"]
origin: application
@@ -126,11 +105,11 @@ data_assets:
integrity: important
availability: important
justification_cia_rating: >
- Contains personal data and business records.
+ Contains usersโ personal data and business transaction records. Integrity and confidentiality are important to prevent fraud or privacy breaches.
Product Catalog:
id: product-catalog
- description: "Public product info: names, prices, descriptions."
+ description: "Product information (names, descriptions, prices) available to all users."
usage: business
tags: ["public"]
origin: application
@@ -140,13 +119,13 @@ data_assets:
integrity: important
availability: important
justification_cia_rating: >
- Integrity matters to avoid fraud/manipulation of prices.
+ Product data is intended to be public, but its integrity is important (to avoid defacement or price manipulation that could mislead users).
Tokens & Sessions:
id: tokens-sessions
- description: "Session IDs, JWTs, CSRF tokens."
+ description: "Session identifiers, JWTs for authenticated sessions, CSRF tokens."
usage: business
- tags: ["auth","tokens"]
+ tags: ["auth", "tokens"]
origin: application
owner: Lab Owner
quantity: many
@@ -154,11 +133,11 @@ data_assets:
integrity: important
availability: important
justification_cia_rating: >
- Compromise leads to account takeover.
+ If session tokens are compromised, attackers can hijack user sessions. They must be kept confidential and intact; availability is less critical (tokens can be reissued).
Logs:
id: logs
- description: "App/access logs (may accidentally contain PII/secrets)."
+ description: "Application and access logs (may inadvertently contain PII or secrets)."
usage: devops
tags: ["logs"]
origin: application
@@ -168,7 +147,7 @@ data_assets:
integrity: important
availability: important
justification_cia_rating: >
- Operational value; ensure redaction to avoid leakage.
+ Logs are for internal use (troubleshooting, monitoring). They should not be exposed publicly, and sensitive data should be sanitized to protect confidentiality.
# =========================
# TECHNICAL ASSETS
@@ -177,7 +156,7 @@ technical_assets:
User Browser:
id: user-browser
- description: "End-user web browser."
+ description: "End-user web browser (client)."
type: external-entity
usage: business
used_as_client_by_human: true
@@ -185,15 +164,15 @@ technical_assets:
justification_out_of_scope:
size: system
technology: browser
- tags: ["actor","user"]
+ tags: ["actor", "user"]
internet: true
machine: virtual
encryption: none
- owner: External Users
+ owner: External User
confidentiality: public
integrity: operational
availability: operational
- justification_cia_rating: "UI client."
+ justification_cia_rating: "Client controlled by end user (potentially an attacker)."
multi_tenant: false
redundant: false
custom_developed_parts: false
@@ -204,8 +183,8 @@ technical_assets:
communication_links:
To Reverse Proxy (preferred):
target: reverse-proxy
- description: "User to reverse proxy (HTTPS 443)."
- protocol: http
+ description: "User browser to reverse proxy (HTTPS on 443)."
+ protocol: https
authentication: session-id
authorization: enduser-identity-propagation
tags: ["primary"]
@@ -217,9 +196,9 @@ technical_assets:
- tokens-sessions
data_assets_received:
- product-catalog
- Direct To App (no proxy):
+ Direct to App (no proxy):
target: juice-shop
- description: "Direct access to app (HTTP 3000)."
+ description: "Direct browser access to app (HTTP on 3000)."
protocol: http
authentication: session-id
authorization: enduser-identity-propagation
@@ -235,7 +214,7 @@ technical_assets:
Reverse Proxy:
id: reverse-proxy
- description: "Optional reverse proxy with TLS termination & security headers."
+ description: "Optional reverse proxy (e.g., Nginx) for TLS termination and adding security headers."
type: process
usage: business
used_as_client_by_human: false
@@ -243,7 +222,7 @@ technical_assets:
justification_out_of_scope:
size: application
technology: reverse-proxy
- tags: ["optional","proxy"]
+ tags: ["optional", "proxy"]
internet: false
machine: virtual
encryption: transparent
@@ -251,7 +230,7 @@ technical_assets:
confidentiality: internal
integrity: important
availability: important
- justification_cia_rating: "Controls ingress, adds TLS and headers."
+ justification_cia_rating: "Not exposed to internet directly; improves security of inbound traffic."
multi_tenant: false
redundant: false
custom_developed_parts: false
@@ -264,7 +243,7 @@ technical_assets:
communication_links:
To App:
target: juice-shop
- description: "Proxy to app (HTTP 3000)."
+ description: "Proxy forwarding to app (HTTP on 3000 internally)."
protocol: http
authentication: none
authorization: none
@@ -278,9 +257,9 @@ technical_assets:
data_assets_received:
- product-catalog
- Juice Shop:
+ Juice Shop Application:
id: juice-shop
- description: "OWASP Juice Shop application (Node.js, v19.0.0)."
+ description: "OWASP Juice Shop server (Node.js/Express, v19.0.0)."
type: process
usage: business
used_as_client_by_human: false
@@ -288,7 +267,7 @@ technical_assets:
justification_out_of_scope:
size: application
technology: web-server
- tags: ["app","nodejs"]
+ tags: ["app", "nodejs"]
internet: false
machine: container
encryption: none
@@ -296,7 +275,7 @@ technical_assets:
confidentiality: internal
integrity: important
availability: important
- justification_cia_rating: "Business-facing app with deliberate vulns for learning."
+ justification_cia_rating: "In-scope web application (contains all business logic and vulnerabilities by design)."
multi_tenant: false
redundant: false
custom_developed_parts: true
@@ -310,23 +289,9 @@ technical_assets:
data_formats_accepted:
- json
communication_links:
- To Email/SMS Provider:
- target: email-sms-provider
- description: "Outbound notifications to provider."
- protocol: https
- authentication: token
- authorization: technical-user
- tags: ["egress"]
- vpn: false
- ip_filtered: false
- readonly: false
- usage: business
- data_assets_sent:
- - user-accounts
- - orders
- To Webhook Endpoint:
+ To Challenge WebHook:
target: webhook-endpoint
- description: "Optional outbound webhooks."
+ description: "Optional outbound callback (HTTP POST) to external WebHook when a challenge is solved."
protocol: https
authentication: none
authorization: none
@@ -340,7 +305,7 @@ technical_assets:
Persistent Storage:
id: persistent-storage
- description: "Host-mounted volume for logs/uploads."
+ description: "Host-mounted volume for database, file uploads, and logs."
type: datastore
usage: devops
used_as_client_by_human: false
@@ -348,7 +313,7 @@ technical_assets:
justification_out_of_scope:
size: component
technology: file-server
- tags: ["storage","volume"]
+ tags: ["storage", "volume"]
internet: false
machine: virtual
encryption: none
@@ -356,66 +321,39 @@ technical_assets:
confidentiality: internal
integrity: important
availability: important
- justification_cia_rating: "Operational data; may contain sensitive info if misconfigured."
+ justification_cia_rating: "Local disk storage for the container โ not directly exposed, but if compromised it contains sensitive data (database and logs)."
multi_tenant: false
redundant: false
custom_developed_parts: false
data_assets_processed: []
data_assets_stored:
- logs
- data_formats_accepted:
- - file
- communication_links: {}
-
- Email/SMS Provider:
- id: email-sms-provider
- description: "External Email/SMS API provider."
- type: external-entity
- usage: business
- used_as_client_by_human: false
- out_of_scope: true
- justification_out_of_scope: "Third-party service."
- size: system
- technology: web-service-rest
- tags: ["saas","notifications"]
- internet: true
- machine: virtual
- encryption: none
- owner: Third Party
- confidentiality: internal
- integrity: important
- availability: important
- justification_cia_rating: "Handles notifications; sensitive addresses may be transmitted."
- multi_tenant: true
- redundant: true
- custom_developed_parts: false
- data_assets_processed:
- user-accounts
- orders
- data_assets_stored: []
+ - product-catalog
data_formats_accepted:
- - json
+ - file
communication_links: {}
Webhook Endpoint:
id: webhook-endpoint
- description: "3rd-party webhook receiver (if configured)."
+ description: "External WebHook service (3rd-party, if configured for integrations)."
type: external-entity
usage: business
used_as_client_by_human: false
out_of_scope: true
- justification_out_of_scope: "Third-party sink."
+ justification_out_of_scope: "Third-party service to receive notifications (not under our control)."
size: system
- technology: web-service-rest
- tags: ["saas","webhook"]
+ technology: web-service-rest
+ tags: ["saas", "webhook"]
internet: true
machine: virtual
encryption: none
- owner: Third Party
+ owner: Third-Party
confidentiality: internal
integrity: operational
availability: operational
- justification_cia_rating: "Potential egress path; validate destinations."
+ justification_cia_rating: "External service that receives data (like order or challenge info). Treated as a trusted integration point but could be abused if misconfigured."
multi_tenant: true
redundant: true
custom_developed_parts: false
@@ -433,19 +371,18 @@ trust_boundaries:
Internet:
id: internet
- description: "Public Internet zone."
+ description: "Untrusted public network (Internet)."
type: network-dedicated-hoster
tags: []
technical_assets_inside:
- user-browser
- - email-sms-provider
- webhook-endpoint
trust_boundaries_nested:
- host
Host:
id: host
- description: "Host OS/VM running Docker."
+ description: "Local host machine / VM running the Docker environment."
type: network-dedicated-hoster
tags: []
technical_assets_inside:
@@ -456,7 +393,7 @@ trust_boundaries:
Container Network:
id: container-network
- description: "Docker bridge network."
+ description: "Docker container network (isolated internal network for containers)."
type: network-dedicated-hoster
tags: []
technical_assets_inside:
@@ -470,11 +407,11 @@ shared_runtimes:
Docker Host:
id: docker-host
- description: "Docker daemon and bridge network."
+ description: "Docker Engine and default bridge network on the host."
tags: ["docker"]
technical_assets_running:
- juice-shop
- # add reverse-proxy here if you run it as a container:
+ # If the reverse proxy is containerized, include it:
# - reverse-proxy
# =========================
@@ -487,6 +424,6 @@ individual_risk_categories: {}
# =========================
risk_tracking: {}
-# diagram tweaks (optional)
+# (Optional diagram layout tweaks can be added here)
#diagram_tweak_edge_layout: spline
#diagram_tweak_layout_left_to_right: true
diff --git a/labs/lab3.md b/labs/lab3.md
index bfa0c93f..47ec06df 100644
--- a/labs/lab3.md
+++ b/labs/lab3.md
@@ -1,22 +1,20 @@
# Lab 3 โ Secure Git
-
+
-> **Goal:** Practice secure Git fundamentals: signed commits, pre-commit secret scanning, and standardized PRs.
-> **Deliverable:** A PR from `feature/lab3` with all checklist items completed.
+> **Goal:** Practice secure Git fundamentals: signed commits and pre-commit secret scanning.
+> **Deliverable:** A PR from `feature/lab3` to the course repo with `labs/submission3.md` containing secure Git practices implementation. Submit the PR link via Moodle.
---
## Overview
In this lab you will practice:
-- Verifying commit authenticity with **SSH commit signing**.
-- Preventing secrets with **pre-commit scanning** (TruffleHog + Gitleaks).
-- Standardizing collaboration with a **PR template & checklist**.
-
-These are the foundation of collaboration and trust in DevOps teams.
+- Verifying commit authenticity with **SSH commit signing**
+- Preventing secrets exposure with **pre-commit scanning** (TruffleHog + Gitleaks)
+- Implementing automated security controls in development workflows
---
@@ -24,177 +22,244 @@ These are the foundation of collaboration and trust in DevOps teams.
### Task 1 โ SSH Commit Signature Verification (5 pts)
-**Objective:** Understand the importance of signed commits and set up SSH commit signature verification.
-
-1. **Explore the Importance of Signed Commits**
- - Research why commit signing is crucial for verifying the integrity and authenticity of commits.
- - Resources:
- - [GitHub Docs on SSH Commit Verification](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification)
- - [Atlassian Guide to SSH and Git](https://confluence.atlassian.com/bitbucketserver/sign-commits-and-tags-with-ssh-keys-1305971205.html)
- - Create a file `labs/submission3.md` with a short summary explaining the benefits of signing commits.
-
-2. **Set Up SSH Commit Signing**
- - **Option 1:** Use an existing SSH key and add it to GitHub.
- - **Option 2 (recommended):** Generate a new key (ed25519)
- ```sh
- ssh-keygen -t ed25519 -C "your_email@example.com"
- ```
- Then add the public key to your GitHub account.
-
- - Configure Git to use your SSH key for signing:
- ```sh
- git config --global user.signingkey
- git config --global commit.gpgSign true
- git config --global gpg.format ssh
- ```
-
-3. **Make a Signed Commit**
- - Create and sign a commit with your `submission3.md` file:
- ```sh
- git commit -S -m "docs: add commit signing summary"
- ```
- - Push this commit to your `feature/lab3` branch.
+**Objective:** Configure SSH commit signing to verify commit authenticity and integrity.
----
-### Task 2 โ Pre-commit Hooks (4 pts)
-
-**Objective:** Add a local Git pre-commit hook that scans staged changes for secrets using Dockerized TruffleHog and Gitleaks. The commit must be blocked if any secrets are found.
-
-1. Create the pre-commit hook file
- - Path: `.git/hooks/pre-commit`
- - Contents:
- ```bash
- #!/usr/bin/env bash
- set -euo pipefail
-
- echo "[pre-commit] scanning staged files for secretsโฆ"
-
- # Collect staged files (added/changed)
- mapfile -t STAGED < <(git diff --cached --name-only --diff-filter=ACM)
- if [ ${#STAGED[@]} -eq 0 ]; then
- echo "[pre-commit] no staged files; skipping scans"
- exit 0
- fi
-
- # Limit to existing regular files only
- FILES=()
- for f in "${STAGED[@]}"; do
- [ -f "$f" ] && FILES+=("$f")
- done
- if [ ${#FILES[@]} -eq 0 ]; then
- echo "[pre-commit] no regular files to scan; skipping"
- exit 0
- fi
-
- # Run TruffleHog (Docker) against staged files
- echo "[pre-commit] TruffleHog scanโฆ"
- docker run --rm \
- -v "$PWD:/repo" -w /repo \
- trufflesecurity/trufflehog:latest \
- filesystem --fail --only-verified --json "${FILES[@]}" >/dev/null || {
- echo "\nโ TruffleHog detected potential secrets in staged changes." >&2
- echo "Fix or unstage the offending files and try again." >&2
- exit 1
- }
-
- # Run Gitleaks (Docker) against staged changes
- echo "[pre-commit] Gitleaks scanโฆ"
- docker run --rm \
- -v "$PWD:/repo" -w /repo \
- zricethezav/gitleaks:latest \
- detect --staged --redact --exit-code 1 --no-banner >/dev/null || {
- echo "\nโ Gitleaks detected potential secrets in staged changes." >&2
- echo "Fix or unstage the offending files and try again." >&2
- exit 1
- }
-
- echo "โ No secrets detected; proceeding with commit."
- exit 0
- ```
-
-2. Make the hook executable
- ```bash
- chmod +x .git/hooks/pre-commit
+#### 1.1: Research Commit Signing Benefits
+
+Study why commit signing is crucial for verifying the integrity and authenticity of commits:
+- [GitHub Docs on SSH Commit Verification](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification)
+- [Atlassian Guide to SSH and Git](https://confluence.atlassian.com/bitbucketserver/sign-commits-and-tags-with-ssh-keys-1305971205.html)
+
+#### 1.2: Configure SSH Commit Signing
+
+1. **Generate SSH Key (Option A - Recommended):**
+
+ ```sh
+ ssh-keygen -t ed25519 -C "your_email@example.com"
```
-3. Verify the hook blocks secrets
- - Add a test secret (e.g., a fake AWS key) to a file, stage it, and try to commit. The commit should be blocked by TruffleHog or Gitleaks.
- - Remove/redact the secret or unstage the file, then commit again to confirm it succeeds.
+2. **Use Existing SSH Key (Option B):**
+
+ Use an existing SSH key and add it to GitHub
+
+3. **Configure Git for SSH Signing:**
+
+ ```sh
+ git config --global user.signingkey
+ git config --global commit.gpgSign true
+ git config --global gpg.format ssh
+ ```
+
+#### 1.3: Create Signed Commit
+
+```sh
+git commit -S -m "docs: add commit signing summary"
+```
+
+In `labs/submission3.md`, document:
+- Summary explaining the benefits of signing commits for security
+- Evidence of successful SSH key setup and configuration
+- Analysis: "Why is commit signing critical in DevSecOps workflows?"
+- Screenshots or verification of the "Verified" badge on GitHub
---
-### Task 3 โ PR Template & Checklist (1 pt)
-**Objective:** Standardize pull requests with a reusable template so reviewers see the same sections and a clear checklist every time.
+### Task 2 โ Pre-commit Secret Scanning (5 pts)
-> โ ๏ธ **One-time bootstrap:** GitHub loads PR templates from the **default branch of the base repo** (your forkโs `main`). Add the template to `main` first, then open your lab PR from `feature/lab3`.
+**Objective:** Implement local Git pre-commit hook that scans staged changes for secrets using Dockerized TruffleHog and Gitleaks.
-#### Steps
+#### 2.1: Create Pre-commit Hook
-1. **Create (or source) a template on `main`**
- Path: `.github/pull_request_template.md`
- Commit message: `docs: add PR template`
- - **Option A (discover):** Find a concise PR template from a reputable open-source project or GitHub docs and adapt it.
- - **Option B (write your own):** Create a minimal template with these sections and a 3-item checklist:
- - Sections: **Goal**, **Changes**, **Testing**
- - Checklist (3 items): clear title, docs/README updated if needed, no secrets/large temp files
- - Keep it short and practical (aim for โค 30 lines).
+1. **Setup Pre-commit Hook File:**
+
+ Create `.git/hooks/pre-commit` with the following content:
-2. **Create your lab branch and open a PR**
```bash
- git checkout -b feature/lab3
- # make a change (add labs/submission3.md)
- git add .
- git commit -m "docs: add lab3 submission stub"
- git push -u origin feature/lab3
+ #!/usr/bin/env bash
+ set -euo pipefail
+ echo "[pre-commit] scanning staged files for secretsโฆ"
+
+ # Collect staged files (added/changed)
+ mapfile -t STAGED < <(git diff --cached --name-only --diff-filter=ACM)
+ if [ ${#STAGED[@]} -eq 0 ]; then
+ echo "[pre-commit] no staged files; skipping scans"
+ exit 0
+ fi
+
+ FILES=()
+ for f in "${STAGED[@]}"; do
+ [ -f "$f" ] && FILES+=("$f")
+ done
+ if [ ${#FILES[@]} -eq 0 ]; then
+ echo "[pre-commit] no regular files to scan; skipping"
+ exit 0
+ fi
+
+ echo "[pre-commit] Files to scan: ${FILES[*]}"
+
+ NON_LECTURES_FILES=()
+ LECTURES_FILES=()
+ for f in "${FILES[@]}"; do
+ if [[ "$f" == lectures/* ]]; then
+ LECTURES_FILES+=("$f")
+ else
+ NON_LECTURES_FILES+=("$f")
+ fi
+ done
+
+ echo "[pre-commit] Non-lectures files: ${NON_LECTURES_FILES[*]:-none}"
+ echo "[pre-commit] Lectures files: ${LECTURES_FILES[*]:-none}"
+
+ TRUFFLEHOG_FOUND_SECRETS=false
+ if [ ${#NON_LECTURES_FILES[@]} -gt 0 ]; then
+ echo "[pre-commit] TruffleHog scan on non-lectures filesโฆ"
+
+ set +e
+ TRUFFLEHOG_OUTPUT=$(docker run --rm -v "$(pwd):/repo" -w /repo \
+ trufflesecurity/trufflehog:latest \
+ filesystem "${NON_LECTURES_FILES[@]}" 2>&1)
+ TRUFFLEHOG_EXIT_CODE=$?
+ set -e
+ echo "$TRUFFLEHOG_OUTPUT"
+
+ if [ $TRUFFLEHOG_EXIT_CODE -ne 0 ]; then
+ echo "[pre-commit] โ TruffleHog detected potential secrets in non-lectures files"
+ TRUFFLEHOG_FOUND_SECRETS=true
+ else
+ echo "[pre-commit] โ TruffleHog found no secrets in non-lectures files"
+ fi
+ else
+ echo "[pre-commit] Skipping TruffleHog (only lectures files staged)"
+ fi
+
+ echo "[pre-commit] Gitleaks scan on staged filesโฆ"
+ GITLEAKS_FOUND_SECRETS=false
+ GITLEAKS_FOUND_IN_LECTURES=false
+
+ for file in "${FILES[@]}"; do
+ echo "[pre-commit] Scanning $file with Gitleaks..."
+
+ GITLEAKS_RESULT=$(docker run --rm -v "$(pwd):/repo" -w /repo \
+ zricethezav/gitleaks:latest \
+ detect --source="$file" --no-git --verbose --exit-code=0 --no-banner 2>&1 || true)
+
+ if [ -n "$GITLEAKS_RESULT" ] && echo "$GITLEAKS_RESULT" | grep -q -E "(Finding:|WRN leaks found)"; then
+ echo "Gitleaks found secrets in $file:"
+ echo "$GITLEAKS_RESULT"
+ echo "---"
+
+ if [[ "$file" == lectures/* ]]; then
+ echo "โ ๏ธ Secrets found in lectures directory - allowing as educational content"
+ GITLEAKS_FOUND_IN_LECTURES=true
+ else
+ echo "โ Secrets found in non-excluded file: $file"
+ GITLEAKS_FOUND_SECRETS=true
+ fi
+ else
+ echo "[pre-commit] No secrets found in $file"
+ fi
+ done
+
+ echo ""
+ echo "[pre-commit] === SCAN SUMMARY ==="
+ echo "TruffleHog found secrets in non-lectures files: $TRUFFLEHOG_FOUND_SECRETS"
+ echo "Gitleaks found secrets in non-lectures files: $GITLEAKS_FOUND_SECRETS"
+ echo "Gitleaks found secrets in lectures files: $GITLEAKS_FOUND_IN_LECTURES"
+ echo ""
+
+ if [ "$TRUFFLEHOG_FOUND_SECRETS" = true ] || [ "$GITLEAKS_FOUND_SECRETS" = true ]; then
+ echo -e "โ COMMIT BLOCKED: Secrets detected in non-excluded files." >&2
+ echo "Fix or unstage the offending files and try again." >&2
+ exit 1
+ elif [ "$GITLEAKS_FOUND_IN_LECTURES" = true ]; then
+ echo "โ ๏ธ Secrets found only in lectures directory (educational content) - allowing commit."
+ fi
+
+ echo "โ No secrets detected in non-excluded files; proceeding with commit."
+ exit 0
```
-Open a PR from `feature/lab3` โ `main` **in your fork**.
+2. **Make Hook Executable:**
-3. **Verify the template is applied**
+ ```bash
+ chmod +x .git/hooks/pre-commit
+ ```
- * The PR **description auto-fills** with your sections and the **3-item checklist**.
- * Fill in *Goal / Changes / Testing* and tick the checkboxes.
+#### 2.2: Test Secret Detection
-#### Acceptance Criteria
+Verify hook functionality:
+- Add a test secret (e.g., fake AWS key) to a file and stage it
+- Attempt to commit - should be blocked by TruffleHog or Gitleaks
+- Remove/redact the secret, then commit again to confirm success
-* โ
Branch `feature/lab3` exists with changes committed.
-* โ
`labs/submission3.md` is present and at least one commit in the PR shows **โVerifiedโ** (signed via SSH) on GitHub.
-* โ
A local `.git/hooks/pre-commit` runs TruffleHog and Gitleaks via Docker and blocks commits on detected secrets.
-* โ
File `.github/pull_request_template.md` exists on the **main** branch.
-* โ
A PR from `feature/lab3` โ `main` is open and **auto-filled** with the template, including **Goal / Changes / Testing** and the **3-item checklist** (boxes ticked).
+In `labs/submission3.md`, document:
+- Pre-commit hook setup process and configuration
+- Evidence of successful secret detection blocking commits
+- Test results showing both blocked and successful commits
+- Analysis of how automated secret scanning prevents security incidents
---
## How to Submit
-1. Complete all tasks.
-2. Push `feature/lab3` to your fork.
-3. Open a PR to your forkโs `main`.
-4. In the PR description, include:
+1. Create a branch for this lab and push it to your fork:
+
+ ```bash
+ git switch -c feature/lab3
+ # create labs/submission3.md with your findings
+ git add labs/submission3.md
+ git commit -m "docs: add lab3 submission"
+ git push -u origin feature/lab3
+ ```
+
+2. Open a PR from your fork's `feature/lab3` branch โ **course repository's main branch**.
+
+3. In the PR description, include:
```text
- - [x] Task 1 done
- - [x] Task 2 done
- - [x] Task 3 done
- - [x] Screenshots attached (if applicable)
+ - [x] Task 1 done โ SSH commit signing setup
+ - [x] Task 2 done โ Pre-commit secrets scanning setup
```
+4. **Copy the PR URL** and submit it via **Moodle before the deadline**.
+
+---
+
+## Acceptance Criteria
+
+- โ
Branch `feature/lab3` exists with commits for each task
+- โ
File `labs/submission3.md` contains required analysis for both tasks
+- โ
At least one commit shows **"Verified"** (signed via SSH) on GitHub
+- โ
Local `.git/hooks/pre-commit` runs TruffleHog and Gitleaks via Docker and blocks secrets
+- โ
PR from `feature/lab3` โ **course repo main branch** is open
+- โ
PR link submitted via Moodle before the deadline
+
---
## Rubric (10 pts)
-| Criterion | Points |
-| ------------------------------------------------- | -----: |
-| Task 1 โ SSH commit signing setup + summary | **5** |
-| Task 2 โ Pre-commit secrets scanning in effect | **4** |
-| Task 3 โ PR template & checklist applied | **1** |
-| **Total** | **10** |
+| Criterion | Points |
+| ------------------------------------------------ | -----: |
+| Task 1 โ SSH commit signing setup + analysis | **5** |
+| Task 2 โ Pre-commit secrets scanning setup | **5** |
+| **Total** | **10** |
---
-## Hints
+## Guidelines
+
+- Use clear Markdown headers to organize sections in `submission3.md`
+- Include both command outputs and written analysis for each task
+- Document security configurations and testing procedures thoroughly
+- Demonstrate both successful and blocked operations for secret scanning
+
+
+Security Configuration Notes
+
+- Ensure the email on your commits matches your GitHub account for proper verification
+- Verify `gpg.format` is set to `ssh` for proper signing configuration
+- Test pre-commit hooks thoroughly with both legitimate and test secret content
+- Docker Desktop/Engine must be running for secret scanning tools
+- Ensure all commits are properly signed for verification on GitHub
-> ๐ **Signed commit not showing โVerifiedโ?** Ensure the email on your commits matches your GitHub account and that `gpg.format` is set to `ssh`.\
-> ๐ **Docker required for scans:** The pre-commit hook uses Docker images for TruffleHog and Gitleaks; ensure Docker Desktop/Engine is running.\
-> ๐ **Template didnโt load?** Confirm the path is `.github\pull_request_template.md` **on `main`** before opening the PR; re-open the PR description after adding it.\
-> โ๏ธ **Keep it short:** Reviewers read many PRsโconcise templates get filled, long ones get ignored.
+
diff --git a/labs/lab4.md b/labs/lab4.md
new file mode 100644
index 00000000..12cc043d
--- /dev/null
+++ b/labs/lab4.md
@@ -0,0 +1,325 @@
+# Lab 4 โ SBOM Generation & Software Composition Analysis
+
+
+
+
+
+> **Goal:** Generate Software Bills of Materials (SBOMs) for OWASP Juice Shop using Syft and Trivy, perform comprehensive Software Composition Analysis with Grype and Trivy, then compare the toolchain capabilities.
+> **Deliverable:** A PR from `feature/lab4` to the course repo with `labs/submission4.md` containing SBOM analysis, SCA findings, and comprehensive toolchain comparison. Submit the PR link via Moodle.
+
+---
+
+## Overview
+
+In this lab you will practice:
+- Generating **SBOMs** with **Syft** and **Trivy** using Docker images for consistency
+- Performing **Software Composition Analysis (SCA)** with **Grype** (Anchore) and **Trivy**
+- **Comprehensive feature comparison** between **Syft+Grype** vs **Trivy all-in-one** approaches
+- **License analysis**, **vulnerability management**, and **supply chain security assessment**
+
+> Continue using the OWASP Juice Shop from previous labs (`bkimminich/juice-shop:v19.0.0`) as your target application.
+
+---
+
+## Tasks
+
+### Task 1 โ SBOM Generation with Syft and Trivy (4 pts)
+
+**Objective:** Generate comprehensive SBOMs using both Syft and Trivy Docker images, extracting maximum metadata including licenses, file information, and dependency relationships.
+
+#### 1.1: Setup SBOM Generation Environment
+
+```bash
+# Prepare working directory
+mkdir -p labs/lab4/{syft,trivy,comparison,analysis}
+
+# Pull required Docker images
+docker pull anchore/syft:latest
+docker pull aquasec/trivy:latest
+docker pull anchore/grype:latest
+```
+
+#### 1.2: Comprehensive SBOM Generation with Syft
+
+```bash
+# Syft native JSON format (most detailed)
+docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
+ -v "$(pwd)":/tmp anchore/syft:latest \
+ bkimminich/juice-shop:v19.0.0 -o syft-json=/tmp/labs/lab4/syft/juice-shop-syft-native.json
+
+# Human-readable table
+docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
+ -v "$(pwd)":/tmp anchore/syft:latest \
+ bkimminich/juice-shop:v19.0.0 -o table=/tmp/labs/lab4/syft/juice-shop-syft-table.txt
+
+# Extract licenses from the native JSON format
+echo "Extracting licenses from Syft SBOM..." > labs/lab4/syft/juice-shop-licenses.txt
+jq -r '.artifacts[] | select(.licenses != null and (.licenses | length > 0)) | "\(.name) | \(.version) | \(.licenses | map(.value) | join(", "))"' \
+ labs/lab4/syft/juice-shop-syft-native.json >> labs/lab4/syft/juice-shop-licenses.txt
+```
+
+#### 1.3: Comprehensive SBOM Generation with Trivy
+
+```bash
+# SBOM with license information
+docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
+ -v "$(pwd)":/tmp aquasec/trivy:latest image \
+ --format json --output /tmp/labs/lab4/trivy/juice-shop-trivy-detailed.json \
+ --list-all-pkgs bkimminich/juice-shop:v19.0.0
+
+# Human-readable table with package details
+docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
+ -v "$(pwd)":/tmp aquasec/trivy:latest image \
+ --format table --output /tmp/labs/lab4/trivy/juice-shop-trivy-table.txt \
+ --list-all-pkgs bkimminich/juice-shop:v19.0.0
+```
+
+#### 1.4: SBOM Analysis and Extraction
+
+```bash
+# Component Analysis
+echo "=== SBOM Component Analysis ===" > labs/lab4/analysis/sbom-analysis.txt
+echo "" >> labs/lab4/analysis/sbom-analysis.txt
+echo "Syft Package Counts:" >> labs/lab4/analysis/sbom-analysis.txt
+jq -r '.artifacts[] | .type' labs/lab4/syft/juice-shop-syft-native.json | sort | uniq -c >> labs/lab4/analysis/sbom-analysis.txt
+
+echo "" >> labs/lab4/analysis/sbom-analysis.txt
+echo "Trivy Package Counts:" >> labs/lab4/analysis/sbom-analysis.txt
+jq -r '.Results[] as $result | $result.Packages[]? | "\($result.Target // "Unknown") - \(.Type // "unknown")"' \
+ labs/lab4/trivy/juice-shop-trivy-detailed.json | sort | uniq -c >> labs/lab4/analysis/sbom-analysis.txt
+
+# License Extraction
+echo "" >> labs/lab4/analysis/sbom-analysis.txt
+echo "=== License Analysis ===" >> labs/lab4/analysis/sbom-analysis.txt
+echo "" >> labs/lab4/analysis/sbom-analysis.txt
+echo "Syft Licenses:" >> labs/lab4/analysis/sbom-analysis.txt
+jq -r '.artifacts[]? | select(.licenses != null) | .licenses[]? | .value' \
+ labs/lab4/syft/juice-shop-syft-native.json | sort | uniq -c >> labs/lab4/analysis/sbom-analysis.txt
+
+echo "" >> labs/lab4/analysis/sbom-analysis.txt
+echo "Trivy Licenses (OS Packages):" >> labs/lab4/analysis/sbom-analysis.txt
+jq -r '.Results[] | select(.Class // "" | contains("os-pkgs")) | .Packages[]? | select(.Licenses != null) | .Licenses[]?' \
+ labs/lab4/trivy/juice-shop-trivy-detailed.json | sort | uniq -c >> labs/lab4/analysis/sbom-analysis.txt
+
+echo "" >> labs/lab4/analysis/sbom-analysis.txt
+echo "Trivy Licenses (Node.js):" >> labs/lab4/analysis/sbom-analysis.txt
+jq -r '.Results[] | select(.Class // "" | contains("lang-pkgs")) | .Packages[]? | select(.Licenses != null) | .Licenses[]?' \
+ labs/lab4/trivy/juice-shop-trivy-detailed.json | sort | uniq -c >> labs/lab4/analysis/sbom-analysis.txt
+```
+
+In `labs/submission4.md`, document:
+- **Package Type Distribution** comparison between Syft and Trivy
+- **Dependency Discovery Analysis** - which tool found more/better dependency data
+- **License Discovery Analysis** - which tool found more/better license data
+
+---
+
+### Task 2 โ Software Composition Analysis with Grype and Trivy (3 pts)
+
+**Objective:** Perform comprehensive vulnerability analysis using both Grype (designed for Syft SBOMs) and Trivy's built-in vulnerability scanning.
+
+#### 2.1: SCA with Grype (Anchore)
+
+```bash
+# Scan using the Syft-generated SBOM
+docker run --rm -v "$(pwd)":/tmp anchore/grype:latest \
+ sbom:/tmp/labs/lab4/syft/juice-shop-syft-native.json \
+ -o json > labs/lab4/syft/grype-vuln-results.json
+
+# Human-readable vulnerability report
+docker run --rm -v "$(pwd)":/tmp anchore/grype:latest \
+ sbom:/tmp/labs/lab4/syft/juice-shop-syft-native.json \
+ -o table > labs/lab4/syft/grype-vuln-table.txt
+```
+
+#### 2.2: SCA with Trivy (All-in-One)
+
+```bash
+# Full vulnerability scan with detailed output
+docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
+ -v "$(pwd)":/tmp aquasec/trivy:latest image \
+ --format json --output /tmp/labs/lab4/trivy/trivy-vuln-detailed.json \
+ bkimminich/juice-shop:v19.0.0
+
+# Secrets scanning
+docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
+ -v "$(pwd)":/tmp aquasec/trivy:latest image \
+ --scanners secret --format table \
+ --output /tmp/labs/lab4/trivy/trivy-secrets.txt \
+ bkimminich/juice-shop:v19.0.0
+
+# License compliance scanning
+docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
+ -v "$(pwd)":/tmp aquasec/trivy:latest image \
+ --scanners license --format json \
+ --output /tmp/labs/lab4/trivy/trivy-licenses.json \
+ bkimminich/juice-shop:v19.0.0
+```
+
+#### 2.3: Vulnerability Analysis and Risk Assessment
+
+```bash
+# Count vulnerabilities by severity
+echo "=== Vulnerability Analysis ===" > labs/lab4/analysis/vulnerability-analysis.txt
+echo "" >> labs/lab4/analysis/vulnerability-analysis.txt
+echo "Grype Vulnerabilities by Severity:" >> labs/lab4/analysis/vulnerability-analysis.txt
+jq -r '.matches[]? | .vulnerability.severity' labs/lab4/syft/grype-vuln-results.json | sort | uniq -c >> labs/lab4/analysis/vulnerability-analysis.txt
+
+echo "" >> labs/lab4/analysis/vulnerability-analysis.txt
+echo "Trivy Vulnerabilities by Severity:" >> labs/lab4/analysis/vulnerability-analysis.txt
+jq -r '.Results[]?.Vulnerabilities[]? | .Severity' labs/lab4/trivy/trivy-vuln-detailed.json | sort | uniq -c >> labs/lab4/analysis/vulnerability-analysis.txt
+
+# License comparison summary
+echo "" >> labs/lab4/analysis/vulnerability-analysis.txt
+echo "=== License Analysis Summary ===" >> labs/lab4/analysis/vulnerability-analysis.txt
+echo "Tool Comparison:" >> labs/lab4/analysis/vulnerability-analysis.txt
+if [ -f labs/lab4/syft/juice-shop-syft-native.json ]; then
+ syft_licenses=$(jq -r '.artifacts[] | select(.licenses != null) | .licenses[].value' labs/lab4/syft/juice-shop-syft-native.json 2>/dev/null | sort | uniq | wc -l)
+ echo "- Syft found $syft_licenses unique license types" >> labs/lab4/analysis/vulnerability-analysis.txt
+fi
+if [ -f labs/lab4/trivy/trivy-licenses.json ]; then
+ trivy_licenses=$(jq -r '.Results[].Licenses[]?.Name' labs/lab4/trivy/trivy-licenses.json 2>/dev/null | sort | uniq | wc -l)
+ echo "- Trivy found $trivy_licenses unique license types" >> labs/lab4/analysis/vulnerability-analysis.txt
+fi
+```
+
+In `labs/submission4.md`, document:
+- **SCA Tool Comparison** - vulnerability detection capabilities
+- **Critical Vulnerabilities Analysis** - top 5 most critical findings with remediation
+- **License Compliance Assessment** - risky licenses and compliance recommendations
+- **Additional Security Features** - secrets scanning results
+
+---
+
+### Task 3 โ Toolchain Comparison: Syft+Grype vs Trivy All-in-One (3 pts)
+
+**Objective:** Comprehensive comparison of the specialized toolchain (Syft+Grype) versus the integrated solution (Trivy) across multiple dimensions.
+
+#### 3.1: Accuracy and Coverage Analysis
+
+```bash
+# Compare package detection
+echo "=== Package Detection Comparison ===" > labs/lab4/comparison/accuracy-analysis.txt
+
+# Extract unique packages from each tool
+jq -r '.artifacts[] | "\(.name)@\(.version)"' labs/lab4/syft/juice-shop-syft-native.json | sort > labs/lab4/comparison/syft-packages.txt
+jq -r '.Results[]?.Packages[]? | "\(.Name)@\(.Version)"' labs/lab4/trivy/juice-shop-trivy-detailed.json | sort > labs/lab4/comparison/trivy-packages.txt
+
+# Find packages detected by both tools
+comm -12 labs/lab4/comparison/syft-packages.txt labs/lab4/comparison/trivy-packages.txt > labs/lab4/comparison/common-packages.txt
+
+# Find packages unique to each tool
+comm -23 labs/lab4/comparison/syft-packages.txt labs/lab4/comparison/trivy-packages.txt > labs/lab4/comparison/syft-only.txt
+comm -13 labs/lab4/comparison/syft-packages.txt labs/lab4/comparison/trivy-packages.txt > labs/lab4/comparison/trivy-only.txt
+
+echo "Packages detected by both tools: $(wc -l < labs/lab4/comparison/common-packages.txt)" >> labs/lab4/comparison/accuracy-analysis.txt
+echo "Packages only detected by Syft: $(wc -l < labs/lab4/comparison/syft-only.txt)" >> labs/lab4/comparison/accuracy-analysis.txt
+echo "Packages only detected by Trivy: $(wc -l < labs/lab4/comparison/trivy-only.txt)" >> labs/lab4/comparison/accuracy-analysis.txt
+
+# Compare vulnerability findings
+echo "" >> labs/lab4/comparison/accuracy-analysis.txt
+echo "=== Vulnerability Detection Overlap ===" >> labs/lab4/comparison/accuracy-analysis.txt
+
+# Extract CVE IDs
+jq -r '.matches[]? | .vulnerability.id' labs/lab4/syft/grype-vuln-results.json | sort | uniq > labs/lab4/comparison/grype-cves.txt
+jq -r '.Results[]?.Vulnerabilities[]? | .VulnerabilityID' labs/lab4/trivy/trivy-vuln-detailed.json | sort | uniq > labs/lab4/comparison/trivy-cves.txt
+
+echo "CVEs found by Grype: $(wc -l < labs/lab4/comparison/grype-cves.txt)" >> labs/lab4/comparison/accuracy-analysis.txt
+echo "CVEs found by Trivy: $(wc -l < labs/lab4/comparison/trivy-cves.txt)" >> labs/lab4/comparison/accuracy-analysis.txt
+echo "Common CVEs: $(comm -12 labs/lab4/comparison/grype-cves.txt labs/lab4/comparison/trivy-cves.txt | wc -l)" >> labs/lab4/comparison/accuracy-analysis.txt
+```
+
+In `labs/submission4.md`, document:
+- **Accuracy Analysis** - package detection and vulnerability overlap quantified
+- **Tool Strengths and Weaknesses** - practical observations from your testing
+- **Use Case Recommendations** - when to choose Syft+Grype vs Trivy
+- **Integration Considerations** - CI/CD, automation, and operational aspects
+
+---
+
+## How to Submit
+
+1. Create a branch for this lab and push it to your fork:
+
+ ```bash
+ git switch -c feature/lab4
+ # create labs/submission4.md with your findings
+ git add labs/submission4.md labs/lab4/
+ git commit -m "docs: add lab4 submission - SBOM generation and SCA comparison"
+ git push -u origin feature/lab4
+ ```
+
+2. Open a PR from your fork's `feature/lab4` branch โ **course repository's main branch**.
+
+3. In the PR description, include:
+
+ ```text
+ - [x] Task 1 done โ SBOM Generation with Syft and Trivy
+ - [x] Task 2 done โ SCA with Grype and Trivy
+ - [x] Task 3 done โ Comprehensive Toolchain Comparison
+ ```
+
+4. **Copy the PR URL** and submit it via **Moodle before the deadline**.
+
+---
+
+## Acceptance Criteria
+
+- โ
Branch `feature/lab4` exists with commits for each task
+- โ
File `labs/submission4.md` contains required analysis for Tasks 1-3
+- โ
SBOM generation completed successfully with both Syft and Trivy
+- โ
Comprehensive SCA performed with both Grype and Trivy vulnerability scanning
+- โ
Quantitative toolchain comparison completed with accuracy analysis
+- โ
All generated SBOMs, vulnerability reports, and analysis files committed
+- โ
PR from `feature/lab4` โ **course repo main branch** is open
+- โ
PR link submitted via Moodle before the deadline
+
+---
+
+## Rubric (10 pts)
+
+| Criterion | Points |
+| ---------------------------------------------------------------- | -----: |
+| Task 1 โ SBOM generation with Syft and Trivy + analysis | **4** |
+| Task 2 โ SCA with Grype and Trivy + vulnerability assessment | **3** |
+| Task 3 โ Comprehensive toolchain comparison + recommendations | **3** |
+| **Total** | **10** |
+
+---
+
+## Guidelines
+
+- Use clear Markdown headers to organize sections in `submission4.md`
+- Include both quantitative metrics and qualitative analysis for each task
+- Document all Docker commands used and any issues encountered
+- Provide actionable security recommendations based on findings
+- Focus on practical insights over theoretical comparisons
+
+
+SBOM Quality Notes
+
+- NYU research (SBOMit project) shows metadata-based SBOM generation has accuracy limitations
+- Pay attention to packages detected by one tool but not the other - document these discrepancies
+- Consider the "lying SBOM" problem when evaluating tool accuracy
+
+
+
+
+SCA Best Practices
+
+- Always cross-reference critical vulnerabilities between tools before taking action
+- Evaluate both direct and transitive dependency risks in your analysis
+- Consider CVSS scores, exploitability, and context when prioritizing vulnerabilities
+- Document false positives and tool-specific detection patterns
+
+
+
+
+Comparison Methodology
+
+- Use consistent container image and execution environment for fair comparison
+- Focus on practical operational differences, not just feature checklists
+- Consider maintenance overhead and community support in your analysis
+- Provide specific use case recommendations based on quantitative findings
+
+
diff --git a/labs/lab5.md b/labs/lab5.md
new file mode 100644
index 00000000..472f9367
--- /dev/null
+++ b/labs/lab5.md
@@ -0,0 +1,480 @@
+# Lab 5 โ Security Analysis: SAST & DAST of OWASP Juice Shop
+
+
+
+
+
+> **Goal:** Perform Static Application Security Testing (SAST) using Semgrep and Dynamic Application Security Testing (DAST) using multiple tools (ZAP, Nuclei, Nikto, SQLmap) against OWASP Juice Shop to identify security vulnerabilities and compare tool effectiveness.
+> **Deliverable:** A PR from `feature/lab5` to the course repo with `labs/submission5.md` containing SAST findings, DAST results from multiple tools, and security recommendations. Submit the PR link via Moodle.
+
+---
+
+## Overview
+
+In this lab you will practice:
+- Performing **Static Application Security Testing (SAST)** with **Semgrep** using Docker containers
+- Conducting **Dynamic Application Security Testing (DAST)** using multiple specialized tools
+- **Tool comparison analysis** between different DAST tools (ZAP, Nuclei, Nikto, SQLmap)
+- **Vulnerability correlation** between SAST and DAST findings
+- **Security tool selection** for different vulnerability types
+
+These skills are essential for DevSecOps integration and security testing automation.
+
+> Use the OWASP Juice Shop (`bkimminich/juice-shop:v19.0.0`) as your target application, with access to its source code for SAST analysis.
+
+---
+
+## Tasks
+
+### Task 1 โ Static Application Security Testing with Semgrep (3 pts)
+โฑ๏ธ **Estimated time:** 15-20 minutes
+
+**Objective:** Perform SAST analysis using Semgrep to identify security vulnerabilities in the OWASP Juice Shop source code.
+
+#### 1.1: Setup SAST Environment
+
+1. **Prepare Working Directory and Clone Source:**
+
+ ```bash
+ mkdir -p labs/lab5/{semgrep,zap,nuclei,nikto,sqlmap,analysis}
+ git clone https://github.com/juice-shop/juice-shop.git --depth 1 --branch v19.0.0 labs/lab5/semgrep/juice-shop
+ ```
+
+#### 1.2: SAST Analysis with Semgrep
+
+1. **Run Semgrep Security Scan:**
+
+ ```bash
+ docker run --rm -v "$(pwd)/labs/lab5/semgrep/juice-shop":/src \
+ -v "$(pwd)/labs/lab5/semgrep":/output \
+ semgrep/semgrep:latest \
+ semgrep --config=p/security-audit --config=p/owasp-top-ten \
+ --json --output=/output/semgrep-results.json /src
+
+ # Generate human-readable security report
+ docker run --rm -v "$(pwd)/labs/lab5/semgrep/juice-shop":/src \
+ -v "$(pwd)/labs/lab5/semgrep":/output \
+ semgrep/semgrep:latest \
+ semgrep --config=p/security-audit --config=p/owasp-top-ten \
+ --text --output=/output/semgrep-report.txt /src
+ ```
+
+
+#### 1.3: SAST Results Analysis
+
+1. **Analyze SAST Results:**
+
+ ```bash
+ echo "=== SAST Analysis Report ===" > labs/lab5/analysis/sast-analysis.txt
+ jq '.results | length' labs/lab5/semgrep/semgrep-results.json >> labs/lab5/analysis/sast-analysis.txt
+ ```
+
+In `labs/submission5.md`, document:
+
+**Required Sections:**
+
+1. SAST Tool Effectiveness:
+ - Describe what types of vulnerabilities Semgrep detected
+ - Evaluate coverage (how many files scanned, how many findings)
+
+2. Critical Vulnerability Analysis:
+ - List **5 most critical findings** from Semgrep results
+ - For each vulnerability include:
+ - Vulnerability type (e.g., SQL Injection, Hardcoded Secret)
+ - File path and line number
+ - Severity level
+
+---
+
+### Task 2 โ Dynamic Application Security Testing with Multiple Tools (5 pts)
+โฑ๏ธ **Estimated time:** 60-90 minutes (scans run in background)
+
+**Objective:** Perform DAST analysis using ZAP (with authentication) and specialized tools (Nuclei, Nikto, SQLmap) to compare their effectiveness.
+
+#### 2.1: Setup DAST Environment
+
+1. **Start OWASP Juice Shop:**
+
+ ```bash
+ docker run -d --name juice-shop-lab5 -p 3000:3000 bkimminich/juice-shop:v19.0.0
+
+ # Wait for application to start
+ sleep 10
+
+ # Verify it's running
+ curl -s http://localhost:3000 | head -n 5
+ ```
+
+
+#### 2.2: OWASP ZAP Unauthenticated Scanning
+โฑ๏ธ ~5 minutes
+
+1. **Run Unauthenticated ZAP Baseline Scan:**
+
+ ```bash
+ # Baseline scan without authentication
+ docker run --rm --network host \
+ -v "$(pwd)/labs/lab5/zap":/zap/wrk/:rw \
+ zaproxy/zap-stable:latest \
+ zap-baseline.py -t http://localhost:3000 \
+ -r report-noauth.html -J zap-report-noauth.json
+ ```
+
+
+ > This baseline scan discovers vulnerabilities in publicly accessible endpoints.
+
+#### 2.3: OWASP ZAP Authenticated Scanning
+โฑ๏ธ ~20-30 minutes
+
+> **โ ๏ธ Important:** Authenticated scanning uses ZAP's Automation Framework. The configuration file is pre-created in `labs/lab5/scripts/zap-auth.yaml` for consistency.
+
+1. **Verify Authentication Endpoint:**
+
+ ```bash
+ # Test login with admin credentials (default Juice Shop account)
+ curl -s -X POST http://localhost:3000/rest/user/login \
+ -H 'Content-Type: application/json' \
+ -d '{"email":"admin@juice-sh.op","password":"admin123"}' | jq '.authentication.token'
+ ```
+
+ You should see a JWT token returned, confirming the endpoint works.
+
+2. **Run Authenticated ZAP Scan:**
+
+ ```bash
+ docker run --rm --network host \
+ -v "$(pwd)/labs/lab5":/zap/wrk/:rw \
+ zaproxy/zap-stable:latest \
+ zap.sh -cmd \
+ -autorun /zap/wrk/scripts/zap-auth.yaml
+ ```
+
+
+ ๐ ZAP Configuration Explained
+
+ The `labs/lab5/scripts/zap-auth.yaml` file configures:
+ - **Authentication**: JSON-based login with admin credentials
+ - **Session Management**: Cookie-based session tracking
+ - **Verification**: Uses regex to detect successful login (looks for "authentication" in response)
+ - **Scanning Jobs**: Spider โ AJAX Spider โ Passive Scan โ Active Scan โ Report Generation
+ - **AJAX Spider**: Discovers ~10x more URLs by executing JavaScript (finds dynamic endpoints)
+
+
+
+
+ **What this scan discovers:**
+ - ๐ **Authenticated endpoints** like `/rest/admin/application-configuration`
+ - ๐ **User-specific features** (basket, orders, payment, profile)
+ - ๐ **Admin panel** vulnerabilities
+ - ๐ **10x more URLs** than unauthenticated scan (AJAX spider finds ~1,200 URLs)
+
+ **Expected output:**
+ ```
+ Job spider found 112 URLs
+ Job spiderAjax found 1,199 URLs # AJAX spider discovers much more!
+ Job report generated report /zap/wrk/report-auth.html
+ ```
+
+ > **Key Insight:** Look for `http://localhost:3000/rest/admin/` endpoints in the output - these prove authentication is working!
+
+3. **Compare Authenticated vs Unauthenticated Scans:**
+
+ Run: `bash labs/lab5/scripts/compare_zap.sh`
+
+#### 2.4: Multi-Tool Specialized Scanning
+
+> **๐ก Networking Note:** Docker networking varies by tool:
+> - `--network host`: Shares host's network (ZAP, Nuclei, Nikto)
+> - `--network container:NAME`: Shares another container's network namespace (SQLmap)
+> Use the pattern shown in each command for best compatibility.
+
+1. **Nuclei Template-Based Scan:** โฑ๏ธ ~5 minutes
+
+ ```bash
+ docker run --rm --network host \
+ -v "$(pwd)/labs/lab5/nuclei":/app \
+ projectdiscovery/nuclei:latest \
+ -ut -u http://localhost:3000 \
+ -jsonl -o /app/nuclei-results.json
+ ```
+
+
+2. **Nikto Web Server Scan:** โฑ๏ธ ~5-10 minutes
+
+ ```bash
+ docker run --rm --network host \
+ -v "$(pwd)/labs/lab5/nikto":/tmp \
+ sullo/nikto:latest \
+ -h http://localhost:3000 -o /tmp/nikto-results.txt
+ ```
+
+
+3. **SQLmap SQL Injection Test:** โฑ๏ธ ~10-20 minutes per endpoint
+
+ > **Network Solution:** Share the network namespace with Juice Shop container so SQLmap can access `localhost:3000`
+
+ ```bash
+ # Test both vulnerable endpoints - Search (GET) and Login (POST JSON)
+ docker run --rm \
+ --network container:juice-shop-lab5 \
+ -v "$(pwd)/labs/lab5/sqlmap":/output \
+ sqlmapproject/sqlmap \
+ -u "http://localhost:3000/rest/products/search?q=*" \
+ --dbms=sqlite --batch --level=3 --risk=2 \
+ --technique=B --threads=5 --output-dir=/output
+
+ docker run --rm \
+ --network container:juice-shop-lab5 \
+ -v "$(pwd)/labs/lab5/sqlmap":/output \
+ sqlmapproject/sqlmap \
+ -u "http://localhost:3000/rest/user/login" \
+ --data '{"email":"*","password":"test"}' \
+ --method POST \
+ --headers='Content-Type: application/json' \
+ --dbms=sqlite --batch --level=5 --risk=3 \
+ --technique=BT --threads=5 --output-dir=/output \
+ --dump
+ ```
+
+
+ **How this works:**
+
+ **Networking:**
+ - `--network container:juice-shop-lab5` - Shares network namespace with Juice Shop container
+ - Inside SQLmap container, `localhost:3000` now directly reaches Juice Shop (no DNS/port forwarding needed)
+
+ **Endpoint 1 - Search (GET):**
+ - URL: `http://localhost:3000/rest/products/search?q=*`
+ - `*` marks the `q` parameter for injection testing
+ - `--technique=B` - Boolean-based blind SQL injection (true/false responses)
+ - Faster scan, detects logic-based vulnerabilities
+
+ **Endpoint 2 - Login (POST JSON):**
+ - URL: `http://localhost:3000/rest/user/login`
+ - Tests JSON `email` parameter with `*` marker
+ - `--technique=BT` - Boolean + Time-based blind SQL injection
+ - Time-based detects when responses take longer (SQL `SLEEP()` commands)
+ - More thorough, bypasses authentication without valid credentials
+
+ **Database & Extraction:**
+ - `--dbms=sqlite` - Optimizes for SQLite-specific syntax (Juice Shop uses SQLite)
+ - `--dump` - Automatically extracts database contents after confirming vulnerability
+ - Will extract Users table including emails and bcrypt password hashes
+
+ **Shell escaping:**
+ - Single quotes `'...'` wrap the entire shell command to avoid JSON escaping issues
+
+ > **Expected Results:** SQLmap will find SQL injection in both endpoints and extract ~20 user accounts with hashed passwords. Scan duration: 10-20 minutes.
+
+#### 2.5: DAST Results Analysis
+
+1. **Compare Tool Results:**
+
+ Run: `bash labs/lab5/scripts/summarize_dast.sh`
+
+In `labs/submission5.md`, document:
+
+**Required Sections:**
+
+1. Authenticated vs Unauthenticated Scanning:
+ - Compare URL discovery count (use numbers from `compare_zap.sh` output)
+ - List examples of admin/authenticated endpoints discovered
+ - Explain why authenticated scanning matters for security testing
+
+2. Tool Comparison Matrix:
+ - Create a comparison table with columns: Tool | Findings | Severity Breakdown | Best Use Case
+ - Include all 4 DAST tools: ZAP, Nuclei, Nikto, SQLmap
+ - Use actual numbers from your scan outputs
+
+3. Tool-Specific Strengths:
+ - Describe what each tool excels at:
+ - **ZAP**: (e.g., comprehensive scanning, authentication support)
+ - **Nuclei**: (e.g., speed, known CVE detection)
+ - **Nikto**: (e.g., server misconfiguration)
+ - **SQLmap**: (e.g., deep SQL injection analysis)
+ - Provide 1-2 example findings from each tool
+
+---
+
+### Task 3 โ SAST/DAST Correlation and Security Assessment (2 pts)
+โฑ๏ธ **Estimated time:** 20-30 minutes
+
+**Objective:** Correlate findings from SAST and DAST approaches to provide comprehensive security assessment.
+
+#### 3.1: SAST/DAST Correlation
+
+1. **Create Correlation Analysis:**
+
+ ```bash
+ echo "=== SAST/DAST Correlation Report ===" > labs/lab5/analysis/correlation.txt
+
+ # Count SAST findings
+ sast_count=$(jq '.results | length' labs/lab5/semgrep/semgrep-results.json 2>/dev/null || echo "0")
+
+ # Count DAST findings from all tools
+ zap_med=$(grep -c "class=\"risk-2\"" labs/lab5/zap/report-auth.html 2>/dev/null)
+ zap_high=$(grep -c "class=\"risk-3\"" labs/lab5/zap/report-auth.html 2>/dev/null)
+ zap_total=$(( (zap_med / 2) + (zap_high / 2) ))
+ nuclei_count=$(wc -l < labs/lab5/nuclei/nuclei-results.json 2>/dev/null || echo "0")
+ nikto_count=$(grep -c '+ ' labs/lab5/nikto/nikto-results.txt 2>/dev/null || echo '0')
+
+ # Count SQLmap findings
+ sqlmap_csv=$(find labs/lab5/sqlmap -name "results-*.csv" 2>/dev/null | head -1)
+ if [ -f "$sqlmap_csv" ]; then
+ sqlmap_count=$(tail -n +2 "$sqlmap_csv" | grep -v '^$' | wc -l)
+ else
+ sqlmap_count=0
+ fi
+
+ echo "Security Testing Results Summary:" >> labs/lab5/analysis/correlation.txt
+ echo "" >> labs/lab5/analysis/correlation.txt
+ echo "SAST (Semgrep): $sast_count code-level findings" >> labs/lab5/analysis/correlation.txt
+ echo "DAST (ZAP authenticated): $zap_total alerts" >> labs/lab5/analysis/correlation.txt
+ echo "DAST (Nuclei): $nuclei_count template matches" >> labs/lab5/analysis/correlation.txt
+ echo "DAST (Nikto): $nikto_count server issues" >> labs/lab5/analysis/correlation.txt
+ echo "DAST (SQLmap): $sqlmap_count SQL injection vulnerabilities" >> labs/lab5/analysis/correlation.txt
+ echo "" >> labs/lab5/analysis/correlation.txt
+
+ echo "Key Insights:" >> labs/lab5/analysis/correlation.txt
+ echo "" >> labs/lab5/analysis/correlation.txt
+ echo "SAST (Static Analysis):" >> labs/lab5/analysis/correlation.txt
+ echo " - Finds code-level vulnerabilities before deployment" >> labs/lab5/analysis/correlation.txt
+ echo " - Detects: hardcoded secrets, SQL injection patterns, insecure crypto" >> labs/lab5/analysis/correlation.txt
+ echo " - Fast feedback in development phase" >> labs/lab5/analysis/correlation.txt
+ echo "" >> labs/lab5/analysis/correlation.txt
+ echo "DAST (Dynamic Analysis):" >> labs/lab5/analysis/correlation.txt
+ echo " - Finds runtime configuration and deployment issues" >> labs/lab5/analysis/correlation.txt
+ echo " - Detects: missing security headers, authentication flaws, server misconfigs" >> labs/lab5/analysis/correlation.txt
+ echo " - Authenticated scanning reveals 60%+ more attack surface" >> labs/lab5/analysis/correlation.txt
+ echo "" >> labs/lab5/analysis/correlation.txt
+ echo "Recommendation: Use BOTH approaches for comprehensive security coverage" >> labs/lab5/analysis/correlation.txt
+
+ cat labs/lab5/analysis/correlation.txt
+ ```
+
+
+
+In `labs/submission5.md`, document:
+
+**Required Sections:**
+
+1. SAST vs DAST Comparison:
+ - Compare total findings: SAST count vs combined DAST count
+ - Identify 2-3 vulnerability types found ONLY by SAST
+ - Identify 2-3 vulnerability types found ONLY by DAST
+ - Explain why each approach finds different things
+
+---
+
+## Acceptance Criteria
+
+- โ
Branch `feature/lab5` exists with commits for each task.
+- โ
File `labs/submission5.md` contains required analysis for Tasks 1-3.
+- โ
SAST analysis completed with Semgrep.
+- โ
DAST analysis completed with ZAP and specialized tools.
+- โ
SAST/DAST correlation analysis completed.
+- โ
All generated reports, configurations, and analysis files committed.
+- โ
PR from `feature/lab5` โ **course repo main branch** is open.
+- โ
PR link submitted via Moodle before the deadline.
+
+---
+
+## Cleanup
+
+After completing the lab:
+
+```bash
+# Stop and remove containers
+docker stop juice-shop-lab5
+docker rm juice-shop-lab5
+
+# Optional: Remove large source code directory (~200MB)
+# rm -rf labs/lab5/semgrep/juice-shop
+
+# Check disk space recovered
+docker system df
+```
+
+---
+
+## How to Submit
+
+1. Create a branch for this lab and push it to your fork:
+
+ ```bash
+ git switch -c feature/lab5
+ # create labs/submission5.md with your findings
+ git add labs/submission5.md labs/lab5/
+ git commit -m "docs: add lab5 submission - SAST/multi-approach DAST security analysis"
+ git push -u origin feature/lab5
+ ```
+
+2. Open a PR from your fork's `feature/lab5` branch โ **course repository's main branch**.
+
+3. In the PR description, include:
+
+ ```text
+ - [x] Task 1 done โ SAST Analysis with Semgrep
+ - [x] Task 2 done โ DAST Analysis (ZAP + Nuclei + Nikto + SQLmap)
+ - [x] Task 3 done โ SAST/DAST Correlation
+ ```
+
+4. **Copy the PR URL** and submit it via **Moodle before the deadline**.
+
+---
+
+## Rubric (10 pts)
+
+| Criterion | Points |
+| ------------------------------------------------------------------- | -----: |
+| Task 1 โ SAST with Semgrep + basic analysis | **3** |
+| Task 2 โ DAST analysis (ZAP + Nuclei + Nikto + SQLmap) + comparison | **5** |
+| Task 3 โ SAST/DAST correlation + recommendations | **2** |
+| **Total** | **10** |
+
+---
+
+## Guidelines
+
+- Use clear Markdown headers to organize sections in `submission5.md`.
+- Include evidence from tool outputs to support your analysis.
+- Focus on practical insights about when to use each tool in a DevSecOps workflow.
+- Provide actionable security recommendations based on findings.
+
+
+Tool Comparison Reference
+
+**SAST Tool:**
+- **Semgrep**: Static code analysis using pattern-based security rulesets
+
+**DAST Tools:**
+- **ZAP**: Comprehensive web application scanner with integrated reporting
+- **Nuclei**: Fast template-based vulnerability scanner with community templates
+- **Nikto**: Web server vulnerability scanner for server misconfigurations
+- **SQLmap**: Specialized SQL injection testing tool
+
+**Tool Selection in DevSecOps:**
+- **Semgrep**: Early in development pipeline (pre-commit, PR checks)
+- **ZAP**: Staging/QA environment for comprehensive web app testing
+- **Nuclei**: Quick scans for known CVEs in any environment
+- **Nikto**: Web server security assessment during deployment
+- **SQLmap**: Targeted SQL injection testing when SAST/DAST indicate database issues
+
+
+
+
+Expected Vulnerability Categories
+
+**SAST typically finds:**
+- Hardcoded credentials and API keys in source code
+- Insecure cryptographic usage patterns
+- Code-level injection vulnerabilities (SQL, command, etc.)
+- Path traversal and insecure file handling
+
+**DAST typically finds:**
+- Authentication and session management issues
+- Runtime configuration problems (security headers, SSL/TLS)
+- XSS, CSRF, and other runtime exploitation vectors
+- Information disclosure through HTTP responses
+
+
diff --git a/labs/lab6.md b/labs/lab6.md
new file mode 100644
index 00000000..a772e4a4
--- /dev/null
+++ b/labs/lab6.md
@@ -0,0 +1,568 @@
+# Lab 6 โ Infrastructure-as-Code Security: Scanning & Policy Enforcement
+
+
+
+
+
+> **Goal:** Perform security analysis on vulnerable Infrastructure-as-Code using multiple scanning tools (tfsec, Checkov, Terrascan for Terraform; KICS for Pulumi and Ansible) and conduct comparative analysis to identify misconfigurations and security issues.
+> **Deliverable:** A PR from `feature/lab6` to the course repo with `labs/submission6.md` containing IaC security findings, tool comparison analysis, and security insights. Submit the PR link via Moodle.
+
+---
+
+## Overview
+
+In this lab you will practice:
+- Scanning **Terraform** infrastructure code with multiple security tools (tfsec, Checkov, Terrascan)
+- Analyzing **Pulumi** infrastructure code with **KICS (Checkmarx)**, an open-source scanner with first-class Pulumi YAML support
+- Scanning **Ansible** playbooks with **KICS** for security issues and misconfigurations
+- Comparing different IaC security scanners to evaluate their effectiveness
+- Analyzing critical security vulnerabilities and developing remediation strategies
+- Recommending tool selection strategies for real-world DevSecOps pipelines
+
+These skills are essential for shift-left security in infrastructure deployment and DevSecOps automation.
+
+> You will work with intentionally vulnerable Terraform, Pulumi, and Ansible code provided in the course repository to practice identifying and fixing security misconfigurations.
+
+---
+
+## Tasks
+
+### Task 1 โ Terraform & Pulumi Security Scanning (5 pts)
+
+**Objective:** Scan vulnerable Terraform and Pulumi configurations using multiple security tools to compare effectiveness and identify infrastructure security issues.
+
+#### 1.1: Setup Scanning Environment
+
+1. **Prepare Analysis Directory:**
+
+ ```bash
+ # Create analysis directory for all scan results
+ mkdir -p labs/lab6/analysis
+ ```
+
+
+Vulnerable IaC Code Structure
+
+**Location:** `labs/lab6/vulnerable-iac/`
+
+**Terraform code** (`labs/lab6/vulnerable-iac/terraform/`):
+- `main.tf` - AWS infrastructure with public S3 buckets, hardcoded credentials
+- `security_groups.tf` - Overly permissive security rules (0.0.0.0/0)
+- `database.tf` - Unencrypted RDS instances, public databases
+- `iam.tf` - Wildcard IAM permissions, privilege escalation
+- `variables.tf` - Insecure default values, hardcoded secrets
+
+**Pulumi code** (`labs/lab6/vulnerable-iac/pulumi/`):
+- `__main__.py` - Python-based infrastructure with 21 security issues
+- `Pulumi.yaml` - Configuration with default secret values
+- `Pulumi-vulnerable.yaml` - YAML-based Pulumi manifest (for KICS scanning)
+- Includes: public S3, open security groups, unencrypted databases
+
+**Ansible code** (`labs/lab6/vulnerable-iac/ansible/`):
+- `deploy.yml` - Hardcoded secrets, poor command execution
+- `configure.yml` - Weak SSH config, security misconfigurations
+- `inventory.ini` - Credentials in plaintext
+
+**Total: 80+ intentional security vulnerabilities across all frameworks**
+
+> **Note:** Pulumi code includes both Python and YAML formats. KICS is used for Pulumi scanning due to its first-class support for Pulumi YAML manifests and comprehensive query catalog.
+
+
+
+#### 1.2: Scan with tfsec
+
+1. **Run tfsec Security Scanner:**
+
+ ```bash
+ # Scan Terraform code with tfsec (JSON output)
+ docker run --rm -v "$(pwd)/labs/lab6/vulnerable-iac/terraform":/src \
+ aquasec/tfsec:latest /src \
+ --format json > labs/lab6/analysis/tfsec-results.json
+
+ # Generate readable report
+ docker run --rm -v "$(pwd)/labs/lab6/vulnerable-iac/terraform":/src \
+ aquasec/tfsec:latest /src > labs/lab6/analysis/tfsec-report.txt
+ ```
+
+#### 1.3: Scan with Checkov
+
+1. **Run Checkov Security Scanner:**
+
+ ```bash
+ # Scan with Checkov (JSON output)
+ docker run --rm -v "$(pwd)/labs/lab6/vulnerable-iac/terraform":/tf \
+ bridgecrew/checkov:latest \
+ -d /tf --framework terraform \
+ -o json > labs/lab6/analysis/checkov-terraform-results.json
+
+ # Generate readable report
+ docker run --rm -v "$(pwd)/labs/lab6/vulnerable-iac/terraform":/tf \
+ bridgecrew/checkov:latest \
+ -d /tf --framework terraform \
+ --compact > labs/lab6/analysis/checkov-terraform-report.txt
+ ```
+
+#### 1.4: Scan with Terrascan
+
+1. **Run Terrascan Security Scanner:**
+
+ ```bash
+ # Scan with Terrascan (JSON output)
+ docker run --rm -v "$(pwd)/labs/lab6/vulnerable-iac/terraform":/iac \
+ tenable/terrascan:latest scan \
+ -i terraform -d /iac \
+ -o json > labs/lab6/analysis/terrascan-results.json
+
+ # Generate readable report
+ docker run --rm -v "$(pwd)/labs/lab6/vulnerable-iac/terraform":/iac \
+ tenable/terrascan:latest scan \
+ -i terraform -d /iac \
+ -o human > labs/lab6/analysis/terrascan-report.txt
+ ```
+
+#### 1.5: Terraform Scanning Analysis
+
+1. **Compare Tool Results:**
+
+ ```bash
+ echo "=== Terraform Security Analysis ===" > labs/lab6/analysis/terraform-comparison.txt
+
+ # Count findings from each tool
+ tfsec_count=$(jq '.results | length' labs/lab6/analysis/tfsec-results.json 2>/dev/null || echo "0")
+ checkov_count=$(jq '.summary.failed' labs/lab6/analysis/checkov-terraform-results.json 2>/dev/null || echo "0")
+ terrascan_count=$(jq '.results.scan_summary.violated_policies' labs/lab6/analysis/terrascan-results.json 2>/dev/null || echo "0")
+
+ echo "tfsec findings: $tfsec_count" >> labs/lab6/analysis/terraform-comparison.txt
+ echo "Checkov findings: $checkov_count" >> labs/lab6/analysis/terraform-comparison.txt
+ echo "Terrascan findings: $terrascan_count" >> labs/lab6/analysis/terraform-comparison.txt
+ ```
+
+#### 1.6: Scan Pulumi Code with KICS
+
+1. **Scan Pulumi with KICS (Checkmarx):**
+
+ KICS provides first-class Pulumi support and scans Pulumi YAML manifests directly. It includes a comprehensive catalog of Pulumi-specific security queries for AWS, Azure, GCP, and Kubernetes resources.
+
+ ```bash
+ # Scan Pulumi with KICS (JSON and HTML reports)
+ docker run -t --rm -v "$(pwd)/labs/lab6/vulnerable-iac/pulumi":/src \
+ checkmarx/kics:latest \
+ scan -p /src -o /src/kics-report --report-formats json,html
+
+ # Move reports to analysis directory
+ sudo mv labs/lab6/vulnerable-iac/pulumi/kics-report/results.json labs/lab6/analysis/kics-pulumi-results.json
+ sudo mv labs/lab6/vulnerable-iac/pulumi/kics-report/results.html labs/lab6/analysis/kics-pulumi-report.html
+
+ # Generate readable summary (console output)
+ docker run -t --rm -v "$(pwd)/labs/lab6/vulnerable-iac/pulumi":/src \
+ checkmarx/kics:latest \
+ scan -p /src --minimal-ui > labs/lab6/analysis/kics-pulumi-report.txt 2>&1 || true
+ ```
+
+2. **Analyze Pulumi Results:**
+
+ ```bash
+ echo "=== Pulumi Security Analysis (KICS) ===" > labs/lab6/analysis/pulumi-analysis.txt
+
+ # KICS JSON structure: queries_total, queries_failed (vulnerabilities found)
+ high_severity=$(jq '.severity_counters.HIGH // 0' labs/lab6/analysis/kics-pulumi-results.json 2>/dev/null || echo "0")
+ medium_severity=$(jq '.severity_counters.MEDIUM // 0' labs/lab6/analysis/kics-pulumi-results.json 2>/dev/null || echo "0")
+ low_severity=$(jq '.severity_counters.LOW // 0' labs/lab6/analysis/kics-pulumi-results.json 2>/dev/null || echo "0")
+ total_findings=$(jq '.total_counter // 0' labs/lab6/analysis/kics-pulumi-results.json 2>/dev/null || echo "0")
+
+ echo "KICS Pulumi findings: $total_findings" >> labs/lab6/analysis/pulumi-analysis.txt
+ echo " HIGH severity: $high_severity" >> labs/lab6/analysis/pulumi-analysis.txt
+ echo " MEDIUM severity: $medium_severity" >> labs/lab6/analysis/pulumi-analysis.txt
+ echo " LOW severity: $low_severity" >> labs/lab6/analysis/pulumi-analysis.txt
+ ```
+
+In `labs/submission6.md`, document:
+- **Terraform Tool Comparison** - Effectiveness of tfsec vs. Checkov vs. Terrascan
+- **Pulumi Security Analysis** - Findings from KICS on Pulumi code
+- **Terraform vs. Pulumi** - Compare security issues between declarative HCL and programmatic YAML approaches
+- **KICS Pulumi Support** - Evaluate KICS's Pulumi-specific query catalog
+- **Critical Findings** - At least 5 significant security issues
+- **Tool Strengths** - What each tool excels at detecting
+
+---
+
+### Task 2 โ Ansible Security Scanning with KICS (2 pts)
+
+**Objective:** Scan vulnerable Ansible playbooks using KICS to identify security issues, misconfigurations, and best practice violations.
+
+#### 2.1: Scan Ansible Playbooks with KICS
+
+
+Vulnerable Ansible Code Structure
+
+The provided Ansible code includes common security issues:
+- `deploy.yml` - Playbook with hardcoded secrets
+- `configure.yml` - Tasks without `no_log` for sensitive operations
+- `inventory.ini` - Insecure inventory configuration
+
+KICS provides comprehensive Ansible security queries for:
+- Secrets management issues
+- Command execution vulnerabilities
+- File permissions and access control
+- Authentication and access issues
+- Insecure configurations
+
+
+
+1. **Run KICS Security Scanner for Ansible:**
+
+ KICS auto-detects Ansible playbooks and applies Ansible-specific security queries:
+
+ ```bash
+ # Scan Ansible playbooks with KICS (JSON and HTML reports)
+ docker run -t --rm -v "$(pwd)/labs/lab6/vulnerable-iac/ansible":/src \
+ checkmarx/kics:latest \
+ scan -p /src -o /src/kics-report --report-formats json,html
+
+ # Move reports to analysis directory
+ sudo mv labs/lab6/vulnerable-iac/ansible/kics-report/results.json labs/lab6/analysis/kics-ansible-results.json
+ sudo mv labs/lab6/vulnerable-iac/ansible/kics-report/results.html labs/lab6/analysis/kics-ansible-report.html
+
+ # Generate readable summary
+ docker run -t --rm -v "$(pwd)/labs/lab6/vulnerable-iac/ansible":/src \
+ checkmarx/kics:latest \
+ scan -p /src --minimal-ui > labs/lab6/analysis/kics-ansible-report.txt 2>&1 || true
+ ```
+
+#### 2.2: Ansible Security Analysis
+
+1. **Analyze KICS Ansible Results:**
+
+ ```bash
+ echo "=== Ansible Security Analysis (KICS) ===" > labs/lab6/analysis/ansible-analysis.txt
+
+ # Count findings by severity
+ high_severity=$(jq '.severity_counters.HIGH // 0' labs/lab6/analysis/kics-ansible-results.json 2>/dev/null || echo "0")
+ medium_severity=$(jq '.severity_counters.MEDIUM // 0' labs/lab6/analysis/kics-ansible-results.json 2>/dev/null || echo "0")
+ low_severity=$(jq '.severity_counters.LOW // 0' labs/lab6/analysis/kics-ansible-results.json 2>/dev/null || echo "0")
+ total_findings=$(jq '.total_counter // 0' labs/lab6/analysis/kics-ansible-results.json 2>/dev/null || echo "0")
+
+ echo "KICS Ansible findings: $total_findings" >> labs/lab6/analysis/ansible-analysis.txt
+ echo " HIGH severity: $high_severity" >> labs/lab6/analysis/ansible-analysis.txt
+ echo " MEDIUM severity: $medium_severity" >> labs/lab6/analysis/ansible-analysis.txt
+ echo " LOW severity: $low_severity" >> labs/lab6/analysis/ansible-analysis.txt
+ ```
+
+In `labs/submission6.md`, document:
+- **Ansible Security Issues** - Key security problems identified by KICS
+- **Best Practice Violations** - Explain at least 3 violations and their security impact
+- **KICS Ansible Queries** - Evaluate the types of security checks KICS performs
+- **Remediation Steps** - How to fix the identified issues
+
+---
+
+### Task 3 โ Comparative Tool Analysis & Security Insights (3 pts)
+
+**Objective:** Analyze and compare the effectiveness of different IaC security scanning tools to understand their strengths and weaknesses, and develop insights for tool selection in real-world scenarios.
+
+#### 3.1: Create Comprehensive Tool Comparison
+
+1. **Generate Summary Statistics:**
+
+ ```bash
+ # Generate comprehensive comparison statistics
+ echo "=== Comprehensive Tool Comparison ===" > labs/lab6/analysis/tool-comparison.txt
+
+ # Terraform tools
+ tfsec_count=$(jq '.results | length' labs/lab6/analysis/tfsec-results.json 2>/dev/null || echo "0")
+ checkov_tf_count=$(jq '.summary.failed' labs/lab6/analysis/checkov-terraform-results.json 2>/dev/null || echo "0")
+ terrascan_count=$(jq '.results.scan_summary.violated_policies' labs/lab6/analysis/terrascan-results.json 2>/dev/null || echo "0")
+
+ # Pulumi tool
+ kics_pulumi_count=$(jq '.total_counter // 0' labs/lab6/analysis/kics-pulumi-results.json 2>/dev/null || echo "0")
+
+ # Ansible tool
+ kics_ansible_count=$(jq '.total_counter // 0' labs/lab6/analysis/kics-ansible-results.json 2>/dev/null || echo "0")
+
+ echo "Terraform Scanning Results:" >> labs/lab6/analysis/tool-comparison.txt
+ echo " - tfsec: $tfsec_count findings" >> labs/lab6/analysis/tool-comparison.txt
+ echo " - Checkov: $checkov_tf_count findings" >> labs/lab6/analysis/tool-comparison.txt
+ echo " - Terrascan: $terrascan_count findings" >> labs/lab6/analysis/tool-comparison.txt
+ echo "" >> labs/lab6/analysis/tool-comparison.txt
+ echo "Pulumi Scanning Results (KICS): $kics_pulumi_count findings" >> labs/lab6/analysis/tool-comparison.txt
+ echo "Ansible Scanning Results (KICS): $kics_ansible_count findings" >> labs/lab6/analysis/tool-comparison.txt
+ ```
+
+2. **Create Tool Effectiveness Matrix:**
+
+ In `labs/submission6.md`, create a comprehensive comparison table:
+
+ | Criterion | tfsec | Checkov | Terrascan | KICS |
+ |-----------|-------|---------|-----------|------|
+ | **Total Findings** | # | # | # | # (Pulumi + Ansible) |
+ | **Scan Speed** | Fast/Medium/Slow | | | |
+ | **False Positives** | Low/Med/High | | | |
+ | **Report Quality** | โญ-โญโญโญโญ | | | |
+ | **Ease of Use** | โญ-โญโญโญโญ | | | |
+ | **Documentation** | โญ-โญโญโญโญ | | | |
+ | **Platform Support** | Terraform only | Multiple | Multiple | Multiple |
+ | **Output Formats** | JSON, text, SARIF, etc | | | |
+ | **CI/CD Integration** | Easy/Medium/Hard | | | |
+ | **Unique Strengths** | | | | |
+
+#### 3.2: Vulnerability Category Analysis
+
+1. **Categorize Findings by Security Domain:**
+
+ In `labs/submission6.md`, analyze tool performance across security categories:
+
+ | Security Category | tfsec | Checkov | Terrascan | KICS (Pulumi) | KICS (Ansible) | Best Tool |
+ |------------------|-------|---------|-----------|---------------|----------------|----------|
+ | **Encryption Issues** | ? | ? | ? | ? | N/A | ? |
+ | **Network Security** | ? | ? | ? | ? | ? | ? |
+ | **Secrets Management** | ? | ? | ? | ? | ? | ? |
+ | **IAM/Permissions** | ? | ? | ? | ? | ? | ? |
+ | **Access Control** | ? | ? | ? | ? | ? | ? |
+ | **Compliance/Best Practices** | ? | ? | ? | ? | ? | ? |
+
+ **Instructions:**
+ - Review the JSON/HTML reports from each tool
+ - Count findings in each security category
+ - Identify which tools excel at detecting specific issue types
+ - Note unique findings detected by only one tool
+
+In `labs/submission6.md`, document:
+- **Tool Comparison Matrix** - Comprehensive evaluation with all metrics
+- **Category Analysis** - Tool performance across security domains
+- **Top 5 Critical Findings** - Detailed analysis with remediation code examples
+- **Tool Selection Guide** - Recommendations for different use cases
+- **Lessons Learned** - Insights about tool effectiveness, false positives, and limitations
+- **CI/CD Integration Strategy** - Practical multi-stage pipeline recommendations
+- **Justification** - Explain your reasoning for tool choices and strategy
+
+---
+
+## Acceptance Criteria
+
+- โ
Branch `feature/lab6` exists with commits for each task.
+- โ
File `labs/submission6.md` contains required analysis for Tasks 1-3.
+- โ
Terraform scanned with tfsec, Checkov, and Terrascan.
+- โ
Pulumi scanned with KICS (Checkmarx).
+- โ
Ansible playbooks scanned with KICS (Checkmarx).
+- โ
Comparative analysis completed with tool evaluation matrices.
+- โ
All scan results and analysis outputs committed.
+- โ
PR from `feature/lab6` โ **course repo main branch** is open.
+- โ
PR link submitted via Moodle before the deadline.
+
+---
+
+## How to Submit
+
+1. Create a branch for this lab and push it to your fork:
+
+ ```bash
+ git switch -c feature/lab6
+ # create labs/submission6.md with your findings
+ git add labs/submission6.md labs/lab6/analysis/
+ git commit -m "docs: add lab6 submission - IaC security scanning and comparative analysis"
+ git push -u origin feature/lab6
+ ```
+
+2. Open a PR from your fork's `feature/lab6` branch โ **course repository's main branch**.
+
+3. In the PR description, include:
+
+ ```text
+ - [x] Task 1 done โ Terraform & Pulumi scanning with multiple tools
+ - [x] Task 2 done โ Ansible security analysis
+ - [x] Task 3 done โ Comparative tool analysis and security insights
+ ```
+
+4. **Copy the PR URL** and submit it via **Moodle before the deadline**.
+
+---
+
+## Rubric (10 pts)
+
+| Criterion | Points |
+| ---------------------------------------------------------------- | -----: |
+| Task 1 โ Terraform & Pulumi scanning (multiple tools) + analysis | **5** |
+| Task 2 โ Ansible scanning (KICS) + remediation | **2** |
+| Task 3 โ Comparative analysis + security insights | **3** |
+| **Total** | **10** |
+
+---
+
+## Guidelines
+
+- Use clear Markdown headers to organize sections in `submission6.md`.
+- Include evidence from tool outputs (JSON excerpts, command outputs) to support your analysis.
+- Focus on practical insights about tool selection for IaC security.
+- Provide actionable remediation steps for identified issues.
+- Document any challenges encountered with different tools.
+
+
+Directory Structure After Lab
+
+```
+labs/lab6/
+โโโ vulnerable-iac/ # Vulnerable code to scan (DO NOT MODIFY)
+โ โโโ terraform/ # 30 Terraform vulnerabilities
+โ โโโ pulumi/ # 21 Pulumi vulnerabilities
+โ โโโ ansible/ # 26 Ansible vulnerabilities
+โ โโโ README.md # Vulnerability catalog
+โโโ analysis/ # All scan results and analysis
+โ โโโ tfsec-results.json
+โ โโโ tfsec-report.txt
+โ โโโ checkov-terraform-results.json
+โ โโโ checkov-terraform-report.txt
+โ โโโ terrascan-results.json
+โ โโโ terrascan-report.txt
+โ โโโ kics-pulumi-results.json
+โ โโโ kics-pulumi-report.html
+โ โโโ kics-pulumi-report.txt
+โ โโโ kics-ansible-results.json
+โ โโโ kics-ansible-report.html
+โ โโโ kics-ansible-report.txt
+โ โโโ tool-comparison.txt
+โ โโโ terraform-comparison.txt
+โ โโโ pulumi-analysis.txt
+โ โโโ ansible-analysis.txt
+โโโ submission6.md # Your submission document
+```
+
+
+
+
+Common Issues & Troubleshooting
+
+**Issue: Docker volume mount permission errors**
+```bash
+# Solution: Ensure you're running commands from the project root directory
+pwd # Should show path ending in the course repo name
+```
+
+**Issue: jq command not found**
+```bash
+# Install jq for JSON parsing
+# macOS: brew install jq
+# Ubuntu: sudo apt-get install jq
+# Windows WSL: sudo apt-get install jq
+```
+
+**Issue: Checkov output format**
+```bash
+# Checkov uses -o flag for output format (json, cli, sarif, etc.)
+# Use shell redirection (>) to save output to a specific file
+# Example: -o json > output.json
+```
+
+**Issue: KICS exits with non-zero exit code**
+```bash
+# This is expected when vulnerabilities are found
+# We use "|| true" to continue execution and capture the output
+# Alternative: Use --ignore-on-exit results to suppress non-zero exit codes
+```
+
+**Issue: KICS not detecting Pulumi files**
+```bash
+# Ensure Pulumi-vulnerable.yaml is in the scan directory
+# KICS auto-detects Pulumi YAML files by extension and content
+# Verify KICS version supports Pulumi (v1.6.x+)
+# Use: docker run --rm checkmarx/kics:latest version
+```
+
+**Issue: KICS report directory not found**
+```bash
+# KICS creates the report directory automatically
+# Ensure you're using -o flag with proper path: -o /src/kics-report
+# The container path must match the mounted volume
+```
+
+
+
+
+Tool Comparison Reference
+
+**Terraform Scanning Tools:**
+- **tfsec**: Fast, Terraform-specific scanner with low false positives
+- **Checkov**: Policy-as-code approach with 1000+ built-in policies (supports Terraform, CloudFormation, K8s, Docker)
+- **Terrascan**: OPA-based scanner with compliance framework mapping
+
+**Pulumi Scanning:**
+- **KICS (Checkmarx)**: Open-source scanner with first-class Pulumi YAML support
+ - Dedicated Pulumi queries catalog for AWS, Azure, GCP, and Kubernetes
+ - Auto-detects Pulumi platform
+ - Announced Pulumi support in v1.6.x with continued expansion
+ - Provides JSON, HTML, SARIF, and console output formats
+
+**Ansible Scanning:**
+- **KICS (Checkmarx)**: Open-source scanner with comprehensive Ansible security queries
+ - Dedicated Ansible queries catalog
+ - Detects secrets management issues, command injection, insecure configurations
+ - Same tool across Terraform, Pulumi, and Ansible for consistency
+
+**Tool Selection Guidelines:
+- **tfsec**: Use for fast CI/CD scans, Terraform-specific checks
+- **Checkov**: Use for comprehensive Terraform and multi-framework coverage (CloudFormation, K8s, Docker)
+- **KICS**: Use for Pulumi and Ansible scanning with first-class support and extensive query catalog
+ - Provides unified scanning across Pulumi and Ansible
+ - Comprehensive security queries for AWS, Azure, GCP, Kubernetes resources
+ - Single tool for consistency across multiple IaC frameworks
+- **Terrascan**: Use for compliance-focused scanning (PCI-DSS, HIPAA, etc.)
+- **Conftest**: Use for custom organizational policy enforcement across all IaC types
+
+
+
+
+Common IaC Security Issues
+
+**Common Terraform & Pulumi Issues:**
+- Unencrypted S3 buckets and RDS instances
+- Security groups allowing 0.0.0.0/0 access
+- Hardcoded credentials and secrets
+- Missing resource tags for governance
+- Overly permissive IAM policies
+- Publicly accessible databases
+
+**Common Ansible Issues:**
+- Hardcoded passwords in playbooks
+- Missing `no_log` on sensitive tasks
+- Overly permissive file permissions (0777)
+- Using `shell` instead of proper modules
+- Missing `become` privilege escalation controls
+- Unencrypted Ansible Vault or missing vault usage
+
+**Security Requirements to Enforce:**
+- Encryption requirements (at-rest and in-transit)
+- Network segmentation and access controls
+- Tagging standards for governance and cost allocation
+- Region restrictions and compliance requirements
+- IAM least-privilege principles
+- Regular security assessments and audits
+
+
+
+
+Remediation Best Practices
+
+**Terraform & Pulumi Remediation:**
+- Enable S3 bucket encryption with `server_side_encryption_configuration`
+- Restrict security group ingress to specific CIDR blocks
+- Use AWS Secrets Manager or Parameter Store for credentials
+- Add required tags to all resources
+- Implement least-privilege IAM policies
+- Set RDS instances to `storage_encrypted = true`
+
+**Ansible Remediation:**
+- Use Ansible Vault for all secrets: `ansible-vault encrypt vars.yml`
+- Add `no_log: true` to tasks handling sensitive data
+- Set proper file permissions (0644 for configs, 0600 for keys)
+- Use Ansible modules instead of `shell`/`command` where possible
+- Implement proper `become` with specific users
+- Regular security updates in playbooks
+
+**Security Scanning Best Practices:**
+- Integrate security scanning into CI/CD pipelines
+- Use pre-commit hooks for early detection
+- Run multiple tools for comprehensive coverage
+- Regularly update scanning tools and their rule sets
+- Document and track remediation progress
+- Establish SLAs for fixing critical/high severity issues
+
+
diff --git a/labs/lab6/vulnerable-iac/README.md b/labs/lab6/vulnerable-iac/README.md
new file mode 100644
index 00000000..65cc1e17
--- /dev/null
+++ b/labs/lab6/vulnerable-iac/README.md
@@ -0,0 +1,284 @@
+# Vulnerable Infrastructure-as-Code for Lab 6
+
+โ ๏ธ **WARNING: This directory contains intentionally vulnerable code for educational purposes only!**
+
+## Overview
+
+This directory contains deliberately insecure Terraform, Pulumi, and Ansible code designed for Lab 6 - Infrastructure-as-Code Security. Students will use security scanning tools to identify and understand these vulnerabilities.
+
+## โ ๏ธ DO NOT USE IN PRODUCTION!
+
+**These files contain serious security vulnerabilities and should NEVER be used in real environments.**
+
+---
+
+## ๐ Directory Structure
+
+```
+vulnerable-iac/
+โโโ terraform/
+โ โโโ main.tf # Public S3 buckets, hardcoded credentials
+โ โโโ security_groups.tf # Overly permissive firewall rules
+โ โโโ database.tf # Unencrypted databases, weak configurations
+โ โโโ iam.tf # Wildcard IAM permissions
+โ โโโ variables.tf # Insecure default values
+โโโ pulumi/
+โ โโโ __main__.py # Python-based infrastructure with 21 security issues
+โ โโโ Pulumi.yaml # Config with default secret values
+โ โโโ Pulumi-vulnerable.yaml # YAML-based Pulumi manifest (for KICS scanning)
+โ โโโ requirements.txt # Python dependencies
+โโโ ansible/
+ โโโ deploy.yml # Hardcoded secrets, poor practices
+ โโโ configure.yml # Weak SSH config, security misconfigurations
+ โโโ inventory.ini # Credentials in plaintext
+```
+
+---
+
+## ๐ด Terraform Vulnerabilities (30 issues)
+
+### Authentication & Credentials
+1. Hardcoded AWS access key in provider configuration
+2. Hardcoded AWS secret key in provider configuration
+9. Hardcoded database password in plain text
+30. Hardcoded API key in variables with default value
+
+### Storage Security
+2. S3 bucket with public-read ACL
+3. S3 bucket without encryption configuration
+4. S3 bucket public access block disabled
+16. DynamoDB table without encryption
+
+### Network Security
+5. Security group allowing all traffic from 0.0.0.0/0
+6. SSH (port 22) accessible from anywhere
+6. RDP (port 3389) accessible from anywhere
+7. MySQL (port 3306) exposed to internet
+7. PostgreSQL (port 5432) exposed to internet
+
+### Database Security
+8. RDS instance without storage encryption
+10. RDS instance publicly accessible
+11. RDS backup retention set to 0 (no backups)
+12. RDS deletion protection disabled
+14. RDS multi-AZ disabled (no high availability)
+15. RDS auto minor version upgrade disabled
+
+### IAM & Permissions
+18. IAM policy with wildcard (*) actions and resources
+19. IAM role with full S3 access on all resources
+20. IAM user with inline policy granting excessive permissions
+21. IAM access keys created for service account
+22. IAM credentials exposed in outputs without sensitive flag
+23. IAM policy allowing privilege escalation paths
+
+### Configuration Management
+24. No region validation for resource deployment
+25. Weak default password in variables
+26. Public access enabled by default
+27. Encryption disabled by default
+28. SSH allowed from anywhere by default
+29. Backup retention days set to 0 by default
+
+---
+
+## ๐ด Pulumi Vulnerabilities (21+ issues)
+
+> **Note:** Pulumi code is provided in both Python (`__main__.py`) and YAML (`Pulumi-vulnerable.yaml`) formats. The YAML format is used for KICS scanning, which has first-class Pulumi YAML support.
+
+### Authentication & Credentials
+1. Hardcoded AWS access key in provider
+2. Hardcoded AWS secret key in provider
+3. Hardcoded database password in code
+4. Hardcoded API key in code
+21. Default config values with secrets in Pulumi.yaml
+
+### Storage Security
+3. S3 bucket with public-read ACL
+4. S3 bucket without encryption configuration
+17. DynamoDB table without server-side encryption
+18. DynamoDB table without point-in-time recovery
+19. EBS volume without encryption
+
+### Network Security
+5. Security group allowing all traffic from 0.0.0.0/0
+6. SSH and RDP accessible from anywhere
+
+### Database Security
+7. RDS instance without storage encryption
+8. RDS instance publicly accessible
+9. RDS backup retention set to 0 (no backups)
+10. RDS deletion protection disabled
+
+### IAM & Permissions
+11. IAM policy with wildcard (*) actions and resources
+12. IAM role with full S3 access on all resources
+16. Lambda function with overly permissive IAM role
+
+### Compute Security
+13. EC2 instance without root volume encryption
+14. Secrets exposed in EC2 user data
+
+### Secrets Management
+15. Secrets exposed in Pulumi outputs (not marked as secret)
+
+### Logging & Monitoring
+20. CloudWatch log group without retention policy
+20. CloudWatch log group without KMS encryption
+
+---
+
+## ๐ด Ansible Vulnerabilities (26 issues)
+
+### Secrets Management
+1. Hardcoded database password in playbook vars
+2. Hardcoded API key in playbook vars
+3. Database connection string with credentials
+20. SSL private key in plaintext
+38. Global variables with secrets in inventory
+41. Production using same credentials as development
+
+### Command Execution
+4. Using shell module instead of proper apt module
+5. MySQL command with password visible in logs
+10. Downloading and executing script without verification
+17. Shell command with potential injection vulnerability
+32. Using raw module to flush firewall rules
+
+### File Permissions & Access
+6. Configuration file with 0777 permissions (world-writable)
+7. SSH private key with 0644 permissions (should be 0600)
+16. Downloaded file with 0777 permissions
+
+### Authentication & Access Control
+21. SELinux disabled
+22. Passwordless sudo for all commands
+23. SSH PermitRootLogin enabled
+23. SSH PasswordAuthentication enabled
+23. SSH PermitEmptyPasswords enabled
+34. Authorized key added for root user
+
+### Logging & Monitoring
+5. Sensitive command without no_log flag
+13. Password hashing without no_log
+14. Debug output exposing secrets
+18. Password visible in task name
+26. Passwords logged in plaintext files
+
+### Network Security
+9. Firewall (ufw) disabled
+25. Application listening on 0.0.0.0 (all interfaces)
+
+### Credential Management
+11. Git credentials hardcoded in repository URL
+35. Credentials in inventory file
+36. Using root user with password authentication
+37. SSH private key path in plaintext inventory
+
+### Configuration Security
+15. Using 'latest' instead of pinned versions
+24. Installing unnecessary development tools on production
+28. Insecure temp file handling with predictable names
+29. No timeout for long-running tasks
+31. Fetching sensitive files without encryption
+33. No checksum validation for templates
+39. Insecure SSH connection settings (StrictHostKeyChecking=no)
+40. No connection timeout configured
+
+### Error Handling
+12. Ignoring errors for critical database migrations
+30. No proper error handling in assertions
+
+---
+
+## ๐ ๏ธ Tools to Use
+
+Students should scan this code with:
+
+### Terraform
+- **tfsec**: Fast Terraform security scanner
+- **Checkov**: Policy-as-code security scanner
+- **Terrascan**: OPA-based compliance scanner
+
+### Pulumi
+- **KICS (Checkmarx)**: Open-source scanner with first-class Pulumi YAML support
+ - Dedicated Pulumi queries catalog (AWS/Azure/GCP/Kubernetes)
+ - Auto-detects Pulumi platform
+ - Provides comprehensive security analysis
+
+### Ansible
+- **KICS (Checkmarx)**: Open-source scanner with comprehensive Ansible security queries
+ - Dedicated Ansible queries catalog
+ - Auto-detects Ansible playbooks
+ - Provides comprehensive security analysis
+
+### Policy-as-Code
+- **Conftest/OPA**: Custom policy enforcement for all IaC types
+
+---
+
+## ๐ Expected Student Outcomes
+
+Students should:
+1. Identify all 80+ security vulnerabilities across Terraform, Pulumi, and Ansible code
+ - Note: Pulumi code includes both Python and YAML formats for comprehensive analysis
+2. Compare detection capabilities of different tools
+3. Compare security issues between declarative (Terraform HCL) and programmatic (Pulumi Python/YAML) IaC
+4. Evaluate KICS's first-class Pulumi support and query catalog
+5. Understand false positives vs true positives
+6. Write custom policies to catch organizational-specific issues
+7. Provide remediation steps for each vulnerability class
+8. Recommend tool selection strategies for CI/CD pipelines
+
+---
+
+## ๐ง How to Use (Students)
+
+```bash
+# Copy vulnerable code to your lab directory
+cp -r vulnerable-iac/terraform/* labs/lab6/terraform/
+cp -r vulnerable-iac/pulumi/* labs/lab6/pulumi/
+cp -r vulnerable-iac/ansible/* labs/lab6/ansible/
+
+# Scan with multiple tools (see lab6.md for commands)
+docker run --rm -v "$(pwd)/labs/lab6/terraform":/src aquasec/tfsec:latest /src
+docker run --rm -v "$(pwd)/labs/lab6/terraform":/tf bridgecrew/checkov:latest -d /tf
+docker run -t --rm -v "$(pwd)/labs/lab6/pulumi":/src checkmarx/kics:latest scan -p /src -o /src/kics-report --report-formats json,html
+# ... and more
+```
+
+---
+
+## ๐ Learning Resources
+
+- [OWASP Infrastructure as Code Security](https://owasp.org/www-project-devsecops/)
+- [Terraform Security Best Practices](https://www.terraform.io/docs/cloud/guides/recommended-practices/index.html)
+- [Pulumi Security Best Practices](https://www.pulumi.com/docs/guides/crossguard/)
+- [Ansible Security Best Practices](https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html)
+- [CIS AWS Foundations Benchmark](https://www.cisecurity.org/benchmark/amazon_web_services)
+- [CIS Distribution Independent Linux Benchmark](https://www.cisecurity.org/benchmark/distribution_independent_linux)
+
+---
+
+## ๐ Security Notice
+
+**These files are for educational purposes only. They contain intentional security vulnerabilities that would compromise real systems. Never deploy this code to any environment connected to the internet or containing real data.**
+
+---
+
+## โ
Validation
+
+To verify students have completed the lab successfully, check that they:
+- [ ] Identified at least 20 Terraform vulnerabilities
+- [ ] Identified at least 15 Pulumi vulnerabilities
+- [ ] Identified at least 15 Ansible vulnerabilities
+- [ ] Compared at least 4 scanning tools (tfsec, Checkov for Terraform, KICS for Pulumi, Terrascan, ansible-lint)
+- [ ] Analyzed differences between Terraform (HCL) and Pulumi (Python/YAML) security issues
+- [ ] Evaluated KICS's Pulumi-specific query catalog and platform support
+- [ ] Created at least 3 custom OPA policies
+- [ ] Provided remediation guidance
+- [ ] Explained tool selection rationale
+
+---
+
+*Lab created for F25-DevSecOps-Intro course*
diff --git a/labs/lab6/vulnerable-iac/ansible/configure.yml b/labs/lab6/vulnerable-iac/ansible/configure.yml
new file mode 100644
index 00000000..e87a4c4a
--- /dev/null
+++ b/labs/lab6/vulnerable-iac/ansible/configure.yml
@@ -0,0 +1,140 @@
+---
+# Vulnerable Configuration Playbook for Lab 6
+
+- name: Configure web servers (VULNERABLE)
+ hosts: all
+ become: true
+ gather_facts: yes
+
+ vars:
+ # SECURITY ISSUE #20 - Plaintext secrets
+ ssl_private_key: |
+ -----BEGIN PRIVATE KEY-----
+ MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC7VJTUt...
+ -----END PRIVATE KEY-----
+
+ admin_password: "Admin123!"
+
+ tasks:
+ # SECURITY ISSUE #21 - No SELinux or AppArmor
+ - name: Disable SELinux
+ selinux:
+ state: disabled
+ when: ansible_os_family == "RedHat"
+
+ # SECURITY ISSUE #22 - Permissive sudo configuration
+ - name: Configure sudo for app user
+ lineinfile:
+ path: /etc/sudoers
+ line: 'appuser ALL=(ALL) NOPASSWD: ALL'
+ validate: '/usr/sbin/visudo -cf %s'
+ # Allowing passwordless sudo for all commands!
+
+ # SECURITY ISSUE #23 - Weak SSH configuration
+ - name: Configure SSH
+ lineinfile:
+ path: /etc/ssh/sshd_config
+ regexp: "{{ item.regexp }}"
+ line: "{{ item.line }}"
+ loop:
+ - { regexp: '^PermitRootLogin', line: 'PermitRootLogin yes' } # Should be 'no'!
+ - { regexp: '^PasswordAuthentication', line: 'PasswordAuthentication yes' } # Should be 'no'!
+ - { regexp: '^PermitEmptyPasswords', line: 'PermitEmptyPasswords yes' } # Should be 'no'!
+ notify: restart sshd
+
+ # SECURITY ISSUE #24 - Installing unnecessary packages
+ - name: Install all development tools
+ apt:
+ name:
+ - build-essential
+ - gcc
+ - g++
+ - gdb
+ - strace
+ - tcpdump
+ state: present
+ # Development tools on production server!
+
+ # SECURITY ISSUE #25 - Exposing application on all interfaces
+ - name: Configure application to listen on all interfaces
+ lineinfile:
+ path: /etc/myapp/config.yml
+ regexp: '^listen:'
+ line: 'listen: 0.0.0.0:8080'
+ # Should bind to specific interface or localhost
+
+ # SECURITY ISSUE #26 - Logging sensitive information
+ - name: Log database connection
+ lineinfile:
+ path: /var/log/myapp/app.log
+ line: "Database connection: postgresql://admin:{{ admin_password }}@localhost/myapp"
+ create: yes
+ # Logging password in plaintext!
+
+ # SECURITY ISSUE #27 - Using vars_prompt without no_log
+ - name: Set API credentials
+ command: echo "API_KEY={{ api_key }}" >> /etc/environment
+ # Credentials in command output
+
+ # SECURITY ISSUE #28 - Insecure temp file handling
+ - name: Create temporary file
+ shell: echo "{{ admin_password }}" > /tmp/password.txt
+ # Password in temp file with predictable name!
+
+ # SECURITY ISSUE #29 - No timeout for long-running tasks
+ - name: Wait for service
+ wait_for:
+ port: 8080
+ delay: 10
+ timeout: 0 # Wait forever!
+
+ # SECURITY ISSUE #30 - Using assert without proper error handling
+ - name: Check configuration
+ assert:
+ that:
+ - ansible_os_family == "Debian"
+ fail_msg: "Unsupported OS"
+ # Exposing system information in error
+
+ # SECURITY ISSUE #31 - Fetching files without encryption
+ - name: Backup configuration
+ fetch:
+ src: /etc/myapp/config.env
+ dest: /backups/
+ flat: yes
+ # Transferring sensitive config in plaintext!
+
+ # SECURITY ISSUE #32 - Using raw module
+ - name: Execute raw command
+ raw: iptables -F # Flush all firewall rules!
+ # Should use proper firewall modules
+
+ # SECURITY ISSUE #33 - No checksum validation for templates
+ - name: Deploy configuration template
+ template:
+ src: app.conf.j2
+ dest: /etc/nginx/sites-available/app.conf
+ mode: '0644'
+ # No backup, no validation before deployment
+ notify: reload nginx
+
+ # SECURITY ISSUE #34 - Authorized_key with wrong permissions
+ - name: Add authorized key
+ authorized_key:
+ user: root
+ key: "{{ lookup('file', '/tmp/id_rsa.pub') }}"
+ state: present
+ # Adding key for root user!
+
+ handlers:
+ - name: restart sshd
+ service:
+ name: sshd
+ state: restarted
+ # No validation of sshd config before restart!
+
+ - name: reload nginx
+ service:
+ name: nginx
+ state: reloaded
+ # No config test before reload!
diff --git a/labs/lab6/vulnerable-iac/ansible/deploy.yml b/labs/lab6/vulnerable-iac/ansible/deploy.yml
new file mode 100644
index 00000000..9f7edece
--- /dev/null
+++ b/labs/lab6/vulnerable-iac/ansible/deploy.yml
@@ -0,0 +1,128 @@
+---
+# Vulnerable Ansible Playbook for Lab 6
+# This file contains intentional security issues for educational purposes
+# DO NOT use this playbook in production!
+
+- name: Deploy web application (VULNERABLE)
+ hosts: webservers
+ become: yes
+
+ vars:
+ # SECURITY ISSUE #1 - Hardcoded password in playbook!
+ db_password: "SuperSecret123!"
+ # SECURITY ISSUE #2 - Hardcoded API key!
+ api_key: "sk_live_1234567890abcdef"
+ # SECURITY ISSUE #3 - Database connection string with credentials
+ db_connection: "postgresql://admin:password123@db.example.com:5432/myapp"
+
+ tasks:
+ # SECURITY ISSUE #4 - Using shell instead of proper module
+ - name: Install packages with shell
+ shell: apt-get install -y nginx mysql-client
+ # Should use apt module instead
+
+ # SECURITY ISSUE #5 - Command with hardcoded password visible in logs
+ - name: Set database password
+ command: mysql -u root -p{{ db_password }} -e "CREATE DATABASE myapp;"
+ # Missing no_log: true - password will appear in logs!
+
+ # SECURITY ISSUE #6 - File with overly permissive permissions
+ - name: Create config file
+ copy:
+ content: |
+ DB_PASSWORD={{ db_password }}
+ API_KEY={{ api_key }}
+ dest: /etc/myapp/config.env
+ mode: '0777' # World readable/writable!
+ owner: root
+ group: root
+
+ # SECURITY ISSUE #7 - SSH key with wrong permissions
+ - name: Deploy SSH key
+ copy:
+ src: files/id_rsa
+ dest: /root/.ssh/id_rsa
+ mode: '0644' # Should be 0600!
+ owner: root
+ group: root
+
+ # SECURITY ISSUE #8 - Running command as root without necessity
+ - name: Create application directory
+ command: mkdir -p /var/www/myapp
+ become: yes
+ become_user: root
+ # Should use file module and run as regular user
+
+ # SECURITY ISSUE #9 - Disabling firewall
+ - name: Disable firewall
+ service:
+ name: ufw
+ state: stopped
+ enabled: no
+ # Should never disable firewall!
+
+ # SECURITY ISSUE #10 - Downloading and executing script without verification
+ - name: Download and run setup script
+ shell: curl http://example.com/setup.sh | bash
+ # No HTTPS, no checksum verification!
+
+ # SECURITY ISSUE #11 - Git clone with hardcoded credentials in URL
+ - name: Clone repository
+ git:
+ repo: 'https://username:password@github.com/company/repo.git'
+ dest: /var/www/myapp
+ # Credentials in URL!
+
+ # SECURITY ISSUE #12 - Ignoring errors
+ - name: Run database migration
+ command: /usr/local/bin/migrate
+ ignore_errors: yes
+ # Should not ignore errors for critical tasks
+
+ # SECURITY ISSUE #13 - Using deprecated bare variables
+ - name: Create user
+ user:
+ name: "{{ username }}" # Variable not defined, will fail
+ password: "{{ password | password_hash('sha512') }}"
+ # Password operation without no_log!
+
+ # SECURITY ISSUE #14 - Debug statement exposing secrets
+ - name: Debug configuration
+ debug:
+ msg: "Database: {{ db_connection }}, API Key: {{ api_key }}"
+ # Exposing secrets in debug output!
+
+ # SECURITY ISSUE #15 - Using latest version (non-deterministic)
+ - name: Install application
+ apt:
+ name: myapp
+ state: latest # Should pin specific version
+ update_cache: yes
+
+ # SECURITY ISSUE #16 - No validation of downloaded files
+ - name: Download application
+ get_url:
+ url: http://example.com/app.tar.gz # HTTP not HTTPS!
+ dest: /tmp/app.tar.gz
+ # No checksum validation!
+ mode: '0777'
+
+ # SECURITY ISSUE #17 - Running with shell expansion
+ - name: Process files
+ shell: rm -rf {{ user_input }}/*
+ # Shell injection risk if user_input is not sanitized!
+
+ # SECURITY ISSUE #18 - Synchronous password in task name
+ - name: Set password to SuperSecret123!
+ # Task name exposes password!
+ user:
+ name: appuser
+ password: "{{ 'SuperSecret123!' | password_hash('sha512') }}"
+
+ handlers:
+ # SECURITY ISSUE #19 - Handler without proper service check
+ - name: restart nginx
+ service:
+ name: nginx
+ state: restarted
+ # No validation that nginx is properly configured before restart
diff --git a/labs/lab6/vulnerable-iac/ansible/inventory.ini b/labs/lab6/vulnerable-iac/ansible/inventory.ini
new file mode 100644
index 00000000..8dc56497
--- /dev/null
+++ b/labs/lab6/vulnerable-iac/ansible/inventory.ini
@@ -0,0 +1,38 @@
+# Vulnerable Ansible Inventory for Lab 6
+# SECURITY ISSUE #35 - Credentials in inventory file!
+
+[webservers]
+web1.example.com ansible_user=root ansible_password=RootPass123!
+web2.example.com ansible_user=root ansible_ssh_pass=RootPass123!
+
+[databases]
+# SECURITY ISSUE #36 - Using root user and default port
+db1.example.com ansible_user=root ansible_port=22 ansible_password=DbPass123!
+
+[appservers]
+# SECURITY ISSUE #37 - Private key path in plaintext
+app1.example.com ansible_user=deploy ansible_ssh_private_key_file=/tmp/insecure_key
+
+[all:vars]
+# SECURITY ISSUE #38 - Global variables with secrets
+ansible_become_password=Sudo123!
+db_admin_password=AdminDB123!
+api_secret_key=sk_live_abcdef1234567890
+
+# SECURITY ISSUE #39 - Using insecure connection settings
+ansible_ssh_common_args='-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null'
+
+# SECURITY ISSUE #40 - No connection timeout
+ansible_connection=ssh
+ansible_ssh_timeout=0
+
+[production:children]
+webservers
+databases
+appservers
+
+[production:vars]
+environment=production
+# SECURITY ISSUE #41 - Production using same credentials as dev
+admin_user=admin
+admin_pass=AdminProd123!
diff --git a/labs/lab6/vulnerable-iac/pulumi/Pulumi-vulnerable.yaml b/labs/lab6/vulnerable-iac/pulumi/Pulumi-vulnerable.yaml
new file mode 100644
index 00000000..469d7624
--- /dev/null
+++ b/labs/lab6/vulnerable-iac/pulumi/Pulumi-vulnerable.yaml
@@ -0,0 +1,279 @@
+#
+# Vulnerable Pulumi YAML Configuration for Lab 6
+# This file contains intentional security issues for educational purposes
+# DO NOT use this code in production!
+#
+# KICS Documentation: https://docs.kics.io
+# Pulumi YAML Queries: https://docs.kics.io/latest/queries/pulumi-queries/
+#
+
+name: vulnerable-pulumi-lab6
+runtime: yaml
+description: Intentionally vulnerable Pulumi infrastructure for Lab 6 - DO NOT USE IN PRODUCTION!
+
+variables:
+ # SECURITY ISSUE #1 - Hardcoded database password
+ dbPassword: "SuperSecret123!"
+
+ # SECURITY ISSUE #2 - Hardcoded API key
+ apiKey: "sk_live_1234567890abcdef"
+
+ awsRegion: "us-east-1"
+
+resources:
+ # SECURITY ISSUE #3 - Public S3 bucket
+ publicBucket:
+ type: aws:s3:Bucket
+ properties:
+ bucket: my-public-bucket-pulumi-yaml
+ acl: public-read # Public access!
+ tags:
+ Name: "Public Bucket"
+ # Missing required tags: Environment, Owner, CostCenter
+
+ # SECURITY ISSUE #4 - S3 bucket without encryption
+ unencryptedBucket:
+ type: aws:s3:Bucket
+ properties:
+ bucket: my-unencrypted-bucket-pulumi-yaml
+ acl: private
+ versioning:
+ enabled: false # Versioning disabled
+ tags:
+ Name: "Unencrypted Bucket"
+ # No serverSideEncryptionConfiguration!
+
+ # SECURITY ISSUE #5 - Security group allowing all traffic from anywhere
+ allowAllSg:
+ type: aws:ec2:SecurityGroup
+ properties:
+ name: allow-all-sg-yaml
+ description: "Allow all inbound traffic"
+ vpcId: vpc-12345678
+ ingress:
+ - description: "Allow all traffic"
+ fromPort: 0
+ toPort: 65535
+ protocol: "-1" # All protocols
+ cidrBlocks:
+ - "0.0.0.0/0" # From anywhere!
+ egress:
+ - fromPort: 0
+ toPort: 0
+ protocol: "-1"
+ cidrBlocks:
+ - "0.0.0.0/0"
+ tags:
+ Name: "Allow All Security Group"
+
+ # SECURITY ISSUE #6 - SSH and RDP open to the world
+ sshOpenSg:
+ type: aws:ec2:SecurityGroup
+ properties:
+ name: ssh-open-sg-yaml
+ description: "SSH and RDP from anywhere"
+ vpcId: vpc-12345678
+ ingress:
+ - description: "SSH from anywhere"
+ fromPort: 22
+ toPort: 22
+ protocol: tcp
+ cidrBlocks:
+ - "0.0.0.0/0" # SSH from anywhere!
+ - description: "RDP from anywhere"
+ fromPort: 3389
+ toPort: 3389
+ protocol: tcp
+ cidrBlocks:
+ - "0.0.0.0/0" # RDP from anywhere!
+ tags:
+ Name: "SSH Open"
+
+ # SECURITY ISSUE #7 & #8 - Unencrypted and publicly accessible RDS instance
+ unencryptedDb:
+ type: aws:rds:Instance
+ properties:
+ identifier: mydb-unencrypted-pulumi-yaml
+ engine: postgres
+ engineVersion: "13.7"
+ instanceClass: db.t3.micro
+ allocatedStorage: 20
+ username: admin
+ password: ${dbPassword} # Using hardcoded password!
+ storageEncrypted: false # SECURITY ISSUE #7 - No encryption!
+ publiclyAccessible: true # SECURITY ISSUE #8 - Public access!
+ skipFinalSnapshot: true
+ backupRetentionPeriod: 0 # SECURITY ISSUE #9 - No backups!
+ deletionProtection: false # SECURITY ISSUE #10
+ vpcSecurityGroupIds:
+ - ${allowAllSg.id}
+ tags:
+ Name: "Unencrypted Database"
+
+ # SECURITY ISSUE #11 - IAM policy with wildcard permissions
+ adminPolicy:
+ type: aws:iam:Policy
+ properties:
+ name: admin-policy-yaml
+ description: "Policy with wildcard permissions"
+ policy:
+ fn::toJSON:
+ Version: "2012-10-17"
+ Statement:
+ - Effect: Allow
+ Action: "*" # Wildcard action!
+ Resource: "*" # Wildcard resource!
+
+ # SECURITY ISSUE #12 - IAM role with overly permissive S3 access
+ appRole:
+ type: aws:iam:Role
+ properties:
+ name: app-role-yaml
+ assumeRolePolicy:
+ fn::toJSON:
+ Version: "2012-10-17"
+ Statement:
+ - Action: sts:AssumeRole
+ Effect: Allow
+ Principal:
+ Service: ec2.amazonaws.com
+
+ s3FullAccessPolicy:
+ type: aws:iam:RolePolicy
+ properties:
+ name: s3-full-access-yaml
+ role: ${appRole.id}
+ policy:
+ fn::toJSON:
+ Version: "2012-10-17"
+ Statement:
+ - Effect: Allow
+ Action: "s3:*" # Full S3 access!
+ Resource: "*" # All resources!
+
+ # SECURITY ISSUE #13 & #14 - EC2 instance without encryption and secrets in user data
+ unencryptedInstance:
+ type: aws:ec2:Instance
+ properties:
+ ami: ami-0c55b159cbfafe1f0
+ instanceType: t2.micro
+ vpcSecurityGroupIds:
+ - ${sshOpenSg.id}
+ userData:
+ fn::toJSON:
+ - "#!/bin/bash"
+ - "echo 'DB_PASSWORD=${dbPassword}' > /etc/app/config" # Password in user data!
+ - "echo 'API_KEY=${apiKey}' >> /etc/app/config"
+ tags:
+ Name: "Unencrypted Instance"
+ # No root block device encryption specified!
+
+ # SECURITY ISSUE #16 - Lambda function with overly permissive IAM role
+ lambdaRole:
+ type: aws:iam:Role
+ properties:
+ name: lambda-role-yaml
+ assumeRolePolicy:
+ fn::toJSON:
+ Version: "2012-10-17"
+ Statement:
+ - Action: sts:AssumeRole
+ Effect: Allow
+ Principal:
+ Service: lambda.amazonaws.com
+
+ lambdaPolicy:
+ type: aws:iam:RolePolicy
+ properties:
+ name: lambda-policy-yaml
+ role: ${lambdaRole.id}
+ policy:
+ fn::toJSON:
+ Version: "2012-10-17"
+ Statement:
+ - Effect: Allow
+ Action:
+ - "s3:*"
+ - "dynamodb:*"
+ - "rds:*"
+ - "ec2:*"
+ Resource: "*"
+
+ # SECURITY ISSUE #17 & #18 - DynamoDB table without encryption or PITR
+ unencryptedTable:
+ type: aws:dynamodb:Table
+ properties:
+ name: my-table-pulumi-yaml
+ attributes:
+ - name: id
+ type: S
+ hashKey: id
+ billingMode: PAY_PER_REQUEST
+ pointInTimeRecovery:
+ enabled: false # SECURITY ISSUE #18 - No PITR
+ tags:
+ Name: "Unencrypted Table"
+ # No serverSideEncryption specified! SECURITY ISSUE #17
+
+ # SECURITY ISSUE #19 - EBS volume without encryption
+ unencryptedVolume:
+ type: aws:ebs:Volume
+ properties:
+ availabilityZone: us-east-1a
+ size: 10
+ encrypted: false # No encryption!
+ tags:
+ Name: "Unencrypted Volume"
+
+ # SECURITY ISSUE #20 - CloudWatch log group without retention or KMS encryption
+ logGroup:
+ type: aws:cloudwatch:LogGroup
+ properties:
+ name: /aws/app/logs-yaml
+ retentionInDays: 0 # Logs never expire - cost and compliance issue
+ # No kmsKeyId specified - no encryption!
+
+ # SECURITY ISSUE #21 - EKS cluster without encryption
+ eksCluster:
+ type: aws:eks:Cluster
+ properties:
+ name: vulnerable-eks-yaml
+ roleArn: ${appRole.arn}
+ vpcConfig:
+ subnetIds:
+ - subnet-12345678
+ - subnet-87654321
+ endpointPublicAccess: true # Public access enabled
+ publicAccessCidrs:
+ - "0.0.0.0/0" # Accessible from anywhere!
+ # No encryptionConfig specified!
+
+# SECURITY ISSUE #15 - Exposing secrets in outputs (not marked as secret)
+outputs:
+ bucketName:
+ value: ${publicBucket.id}
+
+ dbEndpoint:
+ value: ${unencryptedDb.endpoint}
+
+ # These outputs expose sensitive data!
+ dbPassword:
+ value: ${dbPassword}
+
+ apiKey:
+ value: ${apiKey}
+
+ region:
+ value: ${awsRegion}
+
+# Configuration with default secret values - SECURITY ISSUE
+config:
+ aws:region:
+ default: us-east-1
+
+ # Should not have defaults for sensitive values!
+ db_password:
+ default: "DefaultPass123!"
+
+ api_key:
+ default: "sk_default_key"
diff --git a/labs/lab6/vulnerable-iac/pulumi/Pulumi.yaml b/labs/lab6/vulnerable-iac/pulumi/Pulumi.yaml
new file mode 100644
index 00000000..f0d65d01
--- /dev/null
+++ b/labs/lab6/vulnerable-iac/pulumi/Pulumi.yaml
@@ -0,0 +1,12 @@
+name: vulnerable-pulumi-lab6
+runtime: python
+description: Intentionally vulnerable Pulumi infrastructure for Lab 6 - DO NOT USE IN PRODUCTION!
+
+config:
+ # SECURITY ISSUE #21 - Default config values with secrets
+ aws:region:
+ default: us-east-1
+ db_password:
+ default: "DefaultPass123!" # Should not have default for passwords!
+ api_key:
+ default: "sk_default_key" # Should not have default for secrets!
diff --git a/labs/lab6/vulnerable-iac/pulumi/__main__.py b/labs/lab6/vulnerable-iac/pulumi/__main__.py
new file mode 100644
index 00000000..57f3d669
--- /dev/null
+++ b/labs/lab6/vulnerable-iac/pulumi/__main__.py
@@ -0,0 +1,248 @@
+"""
+Vulnerable Pulumi Infrastructure Code for Lab 6
+This file contains intentional security issues for educational purposes
+DO NOT use this code in production!
+
+Language: Python
+Cloud: AWS
+"""
+
+import pulumi
+import pulumi_aws as aws
+
+# SECURITY ISSUE #1 - Hardcoded AWS credentials
+aws_provider = aws.Provider("aws-provider",
+ region="us-east-1",
+ access_key="AKIAIOSFODNN7EXAMPLE", # Hardcoded!
+ secret_key="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" # Hardcoded!
+)
+
+# SECURITY ISSUE #2 - Hardcoded secrets in config
+config = pulumi.Config()
+db_password = "SuperSecret123!" # Should use config.require_secret()
+api_key = "sk_live_1234567890abcdef" # Hardcoded API key
+
+# SECURITY ISSUE #3 - Public S3 bucket
+public_bucket = aws.s3.Bucket("public-bucket",
+ bucket="my-public-bucket-pulumi",
+ acl="public-read", # Public access!
+ tags={
+ "Name": "Public Bucket",
+ # Missing required tags: Environment, Owner
+ }
+)
+
+# SECURITY ISSUE #4 - S3 bucket without encryption
+unencrypted_bucket = aws.s3.Bucket("unencrypted-bucket",
+ bucket="my-unencrypted-bucket-pulumi",
+ acl="private",
+ # No server_side_encryption_configuration!
+ versioning=aws.s3.BucketVersioningArgs(
+ enabled=False # Versioning disabled
+ ),
+ tags={
+ "Name": "Unencrypted Bucket"
+ }
+)
+
+# SECURITY ISSUE #5 - Security group allowing all traffic from anywhere
+allow_all_sg = aws.ec2.SecurityGroup("allow-all-sg",
+ description="Allow all inbound traffic",
+ vpc_id="vpc-12345678",
+ ingress=[
+ aws.ec2.SecurityGroupIngressArgs(
+ description="Allow all traffic",
+ from_port=0,
+ to_port=65535,
+ protocol="-1", # All protocols
+ cidr_blocks=["0.0.0.0/0"], # From anywhere!
+ )
+ ],
+ egress=[
+ aws.ec2.SecurityGroupEgressArgs(
+ from_port=0,
+ to_port=0,
+ protocol="-1",
+ cidr_blocks=["0.0.0.0/0"],
+ )
+ ],
+ tags={
+ "Name": "Allow All Security Group"
+ }
+)
+
+# SECURITY ISSUE #6 - SSH open to the world
+ssh_open_sg = aws.ec2.SecurityGroup("ssh-open-sg",
+ description="SSH from anywhere",
+ vpc_id="vpc-12345678",
+ ingress=[
+ aws.ec2.SecurityGroupIngressArgs(
+ description="SSH from anywhere",
+ from_port=22,
+ to_port=22,
+ protocol="tcp",
+ cidr_blocks=["0.0.0.0/0"], # SSH from anywhere!
+ ),
+ aws.ec2.SecurityGroupIngressArgs(
+ description="RDP from anywhere",
+ from_port=3389,
+ to_port=3389,
+ protocol="tcp",
+ cidr_blocks=["0.0.0.0/0"], # RDP from anywhere!
+ )
+ ],
+ tags={
+ "Name": "SSH Open"
+ }
+)
+
+# SECURITY ISSUE #7 - Unencrypted RDS instance
+unencrypted_db = aws.rds.Instance("unencrypted-db",
+ identifier="mydb-unencrypted-pulumi",
+ engine="postgres",
+ engine_version="13.7",
+ instance_class="db.t3.micro",
+ allocated_storage=20,
+ username="admin",
+ password=db_password, # Hardcoded password from above!
+ storage_encrypted=False, # No encryption!
+ publicly_accessible=True, # SECURITY ISSUE #8 - Public access!
+ skip_final_snapshot=True,
+ backup_retention_period=0, # SECURITY ISSUE #9 - No backups!
+ deletion_protection=False, # SECURITY ISSUE #10
+ vpc_security_group_ids=[allow_all_sg.id],
+ tags={
+ "Name": "Unencrypted Database"
+ }
+)
+
+# SECURITY ISSUE #11 - IAM policy with wildcard permissions
+admin_policy = aws.iam.Policy("admin-policy",
+ description="Policy with wildcard permissions",
+ policy=pulumi.Output.all().apply(lambda _: """{
+ "Version": "2012-10-17",
+ "Statement": [{
+ "Effect": "Allow",
+ "Action": "*",
+ "Resource": "*"
+ }]
+ }""")
+)
+
+# SECURITY ISSUE #12 - IAM role with overly permissive S3 access
+app_role = aws.iam.Role("app-role",
+ assume_role_policy=pulumi.Output.all().apply(lambda _: """{
+ "Version": "2012-10-17",
+ "Statement": [{
+ "Action": "sts:AssumeRole",
+ "Effect": "Allow",
+ "Principal": {
+ "Service": "ec2.amazonaws.com"
+ }
+ }]
+ }""")
+)
+
+s3_full_access_policy = aws.iam.RolePolicy("s3-full-access",
+ role=app_role.id,
+ policy=pulumi.Output.all().apply(lambda _: """{
+ "Version": "2012-10-17",
+ "Statement": [{
+ "Effect": "Allow",
+ "Action": "s3:*",
+ "Resource": "*"
+ }]
+ }""")
+)
+
+# SECURITY ISSUE #13 - EC2 instance without encryption
+unencrypted_instance = aws.ec2.Instance("unencrypted-instance",
+ ami="ami-0c55b159cbfafe1f0",
+ instance_type="t2.micro",
+ vpc_security_group_ids=[ssh_open_sg.id],
+ # No root_block_device encryption!
+ user_data=f"""#!/bin/bash
+ echo "DB_PASSWORD={db_password}" > /etc/app/config # SECURITY ISSUE #14 - Password in user data!
+ echo "API_KEY={api_key}" >> /etc/app/config
+ """,
+ tags={
+ "Name": "Unencrypted Instance"
+ }
+)
+
+# SECURITY ISSUE #15 - Exposing secrets in outputs (not marked as secret)
+pulumi.export("bucket_name", public_bucket.id)
+pulumi.export("db_endpoint", unencrypted_db.endpoint)
+pulumi.export("db_password", db_password) # Exposing password!
+pulumi.export("api_key", api_key) # Exposing API key!
+
+# SECURITY ISSUE #16 - Lambda function with overly permissive IAM role
+lambda_role = aws.iam.Role("lambda-role",
+ assume_role_policy=pulumi.Output.all().apply(lambda _: """{
+ "Version": "2012-10-17",
+ "Statement": [{
+ "Action": "sts:AssumeRole",
+ "Effect": "Allow",
+ "Principal": {
+ "Service": "lambda.amazonaws.com"
+ }
+ }]
+ }""")
+)
+
+lambda_policy = aws.iam.RolePolicy("lambda-policy",
+ role=lambda_role.id,
+ policy=pulumi.Output.all().apply(lambda _: """{
+ "Version": "2012-10-17",
+ "Statement": [{
+ "Effect": "Allow",
+ "Action": [
+ "s3:*",
+ "dynamodb:*",
+ "rds:*",
+ "ec2:*"
+ ],
+ "Resource": "*"
+ }]
+ }""")
+)
+
+# SECURITY ISSUE #17 - DynamoDB table without encryption
+unencrypted_table = aws.dynamodb.Table("unencrypted-table",
+ name="my-table-pulumi",
+ attributes=[
+ aws.dynamodb.TableAttributeArgs(
+ name="id",
+ type="S",
+ )
+ ],
+ hash_key="id",
+ billing_mode="PAY_PER_REQUEST",
+ # No server_side_encryption!
+ point_in_time_recovery=aws.dynamodb.TablePointInTimeRecoveryArgs(
+ enabled=False # SECURITY ISSUE #18 - No PITR
+ ),
+ tags={
+ "Name": "Unencrypted Table"
+ }
+)
+
+# SECURITY ISSUE #19 - EBS volume without encryption
+unencrypted_volume = aws.ebs.Volume("unencrypted-volume",
+ availability_zone="us-east-1a",
+ size=10,
+ encrypted=False, # No encryption!
+ tags={
+ "Name": "Unencrypted Volume"
+ }
+)
+
+# SECURITY ISSUE #20 - CloudWatch log group without retention
+log_group = aws.cloudwatch.LogGroup("app-logs",
+ name="/aws/app/logs",
+ retention_in_days=0, # Logs never expire - cost and compliance issue
+ # No KMS encryption!
+)
+
+print(f"โ ๏ธ WARNING: This Pulumi stack contains {20} intentional security vulnerabilities!")
+print(" This is for educational purposes only - DO NOT deploy to production!")
diff --git a/labs/lab6/vulnerable-iac/pulumi/requirements.txt b/labs/lab6/vulnerable-iac/pulumi/requirements.txt
new file mode 100644
index 00000000..5f626e8c
--- /dev/null
+++ b/labs/lab6/vulnerable-iac/pulumi/requirements.txt
@@ -0,0 +1,2 @@
+pulumi>=3.0.0,<4.0.0
+pulumi-aws>=6.0.0,<7.0.0
diff --git a/labs/lab6/vulnerable-iac/terraform/database.tf b/labs/lab6/vulnerable-iac/terraform/database.tf
new file mode 100644
index 00000000..1897f378
--- /dev/null
+++ b/labs/lab6/vulnerable-iac/terraform/database.tf
@@ -0,0 +1,92 @@
+# Vulnerable Database Configuration for Lab 6
+# Contains unencrypted databases and poor security practices
+
+# Unencrypted RDS instance - SECURITY ISSUE #8
+resource "aws_db_instance" "unencrypted_db" {
+ identifier = "mydb-unencrypted"
+ engine = "postgres"
+ engine_version = "13.7"
+ instance_class = "db.t3.micro"
+ allocated_storage = 20
+
+ username = "admin"
+ password = "SuperSecretPassword123!" # SECURITY ISSUE #9 - Hardcoded password!
+
+ storage_encrypted = false # No encryption!
+
+ publicly_accessible = true # SECURITY ISSUE #10 - Public access!
+
+ skip_final_snapshot = true
+
+ # No backup configuration
+ backup_retention_period = 0 # SECURITY ISSUE #11 - No backups!
+
+ # Missing monitoring
+ enabled_cloudwatch_logs_exports = []
+
+ # No deletion protection
+ deletion_protection = false # SECURITY ISSUE #12
+
+ # Using default security group
+ vpc_security_group_ids = [aws_security_group.database_exposed.id]
+
+ tags = {
+ Name = "Unencrypted Database"
+ # Missing required tags
+ }
+}
+
+# Database with weak configuration - SECURITY ISSUE #13
+resource "aws_db_instance" "weak_db" {
+ identifier = "mydb-weak"
+ engine = "mysql"
+ engine_version = "5.7.38" # Old version with known vulnerabilities
+ instance_class = "db.t3.micro"
+ allocated_storage = 20
+
+ username = "root" # Using default admin username
+ password = "password123" # Weak password!
+
+ storage_encrypted = true
+ kms_key_id = "" # Empty KMS key - using default key
+
+ publicly_accessible = false
+
+ # Multi-AZ disabled
+ multi_az = false # SECURITY ISSUE #14 - No high availability
+
+ # Auto minor version upgrade disabled
+ auto_minor_version_upgrade = false # SECURITY ISSUE #15
+
+ # No performance insights
+ performance_insights_enabled = false
+
+ skip_final_snapshot = true
+
+ tags = {
+ Name = "Weak Database"
+ }
+}
+
+# DynamoDB table without encryption - SECURITY ISSUE #16
+resource "aws_dynamodb_table" "unencrypted_table" {
+ name = "my-table"
+ billing_mode = "PAY_PER_REQUEST"
+ hash_key = "id"
+
+ attribute {
+ name = "id"
+ type = "S"
+ }
+
+ # No server_side_encryption configuration!
+
+ # No point-in-time recovery
+ point_in_time_recovery {
+ enabled = false # SECURITY ISSUE #17
+ }
+
+ tags = {
+ Name = "Unencrypted DynamoDB Table"
+ }
+}
diff --git a/labs/lab6/vulnerable-iac/terraform/iam.tf b/labs/lab6/vulnerable-iac/terraform/iam.tf
new file mode 100644
index 00000000..8ac6746f
--- /dev/null
+++ b/labs/lab6/vulnerable-iac/terraform/iam.tf
@@ -0,0 +1,125 @@
+# Vulnerable IAM Configuration for Lab 6
+# Contains overly permissive IAM policies
+
+# IAM policy with wildcard permissions - SECURITY ISSUE #18
+resource "aws_iam_policy" "admin_policy" {
+ name = "overly-permissive-policy"
+ description = "Policy with wildcard permissions"
+
+ policy = jsonencode({
+ Version = "2012-10-17"
+ Statement = [
+ {
+ Effect = "Allow"
+ Action = "*" # All actions allowed!
+ Resource = "*" # On all resources!
+ }
+ ]
+ })
+}
+
+# IAM role with full S3 access - SECURITY ISSUE #19
+resource "aws_iam_role" "app_role" {
+ name = "application-role"
+
+ assume_role_policy = jsonencode({
+ Version = "2012-10-17"
+ Statement = [
+ {
+ Action = "sts:AssumeRole"
+ Effect = "Allow"
+ Principal = {
+ Service = "ec2.amazonaws.com"
+ }
+ }
+ ]
+ })
+}
+
+resource "aws_iam_role_policy" "s3_full_access" {
+ name = "s3-full-access"
+ role = aws_iam_role.app_role.id
+
+ policy = jsonencode({
+ Version = "2012-10-17"
+ Statement = [
+ {
+ Effect = "Allow"
+ Action = [
+ "s3:*" # All S3 actions!
+ ]
+ Resource = "*" # On all buckets!
+ }
+ ]
+ })
+}
+
+# IAM user with inline policy - SECURITY ISSUE #20
+resource "aws_iam_user" "service_account" {
+ name = "service-account"
+ path = "/system/"
+
+ tags = {
+ Name = "Service Account"
+ }
+}
+
+resource "aws_iam_user_policy" "service_policy" {
+ name = "service-inline-policy"
+ user = aws_iam_user.service_account.name
+
+ policy = jsonencode({
+ Version = "2012-10-17"
+ Statement = [
+ {
+ Effect = "Allow"
+ Action = [
+ "ec2:*", # Full EC2 access
+ "s3:*", # Full S3 access
+ "rds:*" # Full RDS access
+ ]
+ Resource = "*"
+ }
+ ]
+ })
+}
+
+# Access key for IAM user - SECURITY ISSUE #21
+resource "aws_iam_access_key" "service_key" {
+ user = aws_iam_user.service_account.name
+}
+
+# Output sensitive data - SECURITY ISSUE #22
+output "access_key_id" {
+ value = aws_iam_access_key.service_key.id
+ # Should be marked as sensitive!
+}
+
+output "secret_access_key" {
+ value = aws_iam_access_key.service_key.secret
+ # Exposing secret key in output!
+}
+
+# IAM policy allowing privilege escalation - SECURITY ISSUE #23
+resource "aws_iam_policy" "privilege_escalation" {
+ name = "potential-privilege-escalation"
+ description = "Policy that allows privilege escalation"
+
+ policy = jsonencode({
+ Version = "2012-10-17"
+ Statement = [
+ {
+ Effect = "Allow"
+ Action = [
+ "iam:CreatePolicy",
+ "iam:CreateUser",
+ "iam:AttachUserPolicy",
+ "iam:AttachRolePolicy",
+ "iam:PutUserPolicy",
+ "iam:PutRolePolicy"
+ ]
+ Resource = "*"
+ }
+ ]
+ })
+}
diff --git a/labs/lab6/vulnerable-iac/terraform/main.tf b/labs/lab6/vulnerable-iac/terraform/main.tf
new file mode 100644
index 00000000..027cdecf
--- /dev/null
+++ b/labs/lab6/vulnerable-iac/terraform/main.tf
@@ -0,0 +1,43 @@
+# Vulnerable Terraform Configuration for Lab 6
+# This file contains intentional security issues for educational purposes
+# DO NOT use this code in production!
+
+provider "aws" {
+ region = "us-east-1"
+ # Hardcoded credentials - SECURITY ISSUE #1
+ access_key = "AKIAIOSFODNN7EXAMPLE"
+ secret_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
+}
+
+# Public S3 bucket - SECURITY ISSUE #2
+resource "aws_s3_bucket" "public_data" {
+ bucket = "my-public-bucket-lab6"
+ acl = "public-read" # Public access enabled!
+
+ tags = {
+ Name = "Public Data Bucket"
+ # Missing required tags: Environment, Owner, CostCenter
+ }
+}
+
+# S3 bucket without encryption - SECURITY ISSUE #3
+resource "aws_s3_bucket" "unencrypted_data" {
+ bucket = "my-unencrypted-bucket-lab6"
+ acl = "private"
+
+ # No server_side_encryption_configuration!
+
+ versioning {
+ enabled = false # Versioning disabled
+ }
+}
+
+# S3 bucket with public access block disabled - SECURITY ISSUE #4
+resource "aws_s3_bucket_public_access_block" "bad_config" {
+ bucket = aws_s3_bucket.public_data.id
+
+ block_public_acls = false # Should be true
+ block_public_policy = false # Should be true
+ ignore_public_acls = false # Should be true
+ restrict_public_buckets = false # Should be true
+}
diff --git a/labs/lab6/vulnerable-iac/terraform/security_groups.tf b/labs/lab6/vulnerable-iac/terraform/security_groups.tf
new file mode 100644
index 00000000..88f706d5
--- /dev/null
+++ b/labs/lab6/vulnerable-iac/terraform/security_groups.tf
@@ -0,0 +1,92 @@
+# Vulnerable Security Groups for Lab 6
+# Contains overly permissive network rules
+
+# Security group allowing ALL traffic from anywhere - SECURITY ISSUE #5
+resource "aws_security_group" "allow_all" {
+ name = "allow-all-traffic"
+ description = "Allow all inbound traffic from anywhere"
+ vpc_id = "vpc-12345678"
+
+ ingress {
+ description = "Allow all traffic"
+ from_port = 0
+ to_port = 65535
+ protocol = "-1" # All protocols
+ cidr_blocks = ["0.0.0.0/0"] # From anywhere!
+ }
+
+ egress {
+ from_port = 0
+ to_port = 0
+ protocol = "-1"
+ cidr_blocks = ["0.0.0.0/0"]
+ }
+
+ tags = {
+ Name = "Allow All Security Group"
+ }
+}
+
+# Security group with SSH open to the world - SECURITY ISSUE #6
+resource "aws_security_group" "ssh_open" {
+ name = "ssh-from-anywhere"
+ description = "SSH access from anywhere"
+ vpc_id = "vpc-12345678"
+
+ ingress {
+ description = "SSH from anywhere"
+ from_port = 22
+ to_port = 22
+ protocol = "tcp"
+ cidr_blocks = ["0.0.0.0/0"] # SSH from anywhere!
+ }
+
+ ingress {
+ description = "RDP from anywhere"
+ from_port = 3389
+ to_port = 3389
+ protocol = "tcp"
+ cidr_blocks = ["0.0.0.0/0"] # RDP from anywhere!
+ }
+
+ egress {
+ from_port = 0
+ to_port = 0
+ protocol = "-1"
+ cidr_blocks = ["0.0.0.0/0"]
+ }
+
+ tags = {
+ Name = "SSH Open Security Group"
+ }
+}
+
+# Security group with database ports exposed - SECURITY ISSUE #7
+resource "aws_security_group" "database_exposed" {
+ name = "database-public"
+ description = "Database accessible from internet"
+ vpc_id = "vpc-12345678"
+
+ ingress {
+ description = "MySQL from anywhere"
+ from_port = 3306
+ to_port = 3306
+ protocol = "tcp"
+ cidr_blocks = ["0.0.0.0/0"] # Database exposed!
+ }
+
+ ingress {
+ description = "PostgreSQL from anywhere"
+ from_port = 5432
+ to_port = 5432
+ protocol = "tcp"
+ cidr_blocks = ["0.0.0.0/0"] # Database exposed!
+ }
+
+ egress {
+ from_port = 0
+ to_port = 0
+ protocol = "-1"
+ cidr_blocks = ["0.0.0.0/0"]
+ }
+}
diff --git a/labs/lab6/vulnerable-iac/terraform/variables.tf b/labs/lab6/vulnerable-iac/terraform/variables.tf
new file mode 100644
index 00000000..df4547a7
--- /dev/null
+++ b/labs/lab6/vulnerable-iac/terraform/variables.tf
@@ -0,0 +1,75 @@
+# Vulnerable Variables Configuration for Lab 6
+# Contains insecure default values
+
+variable "aws_region" {
+ description = "AWS region"
+ type = string
+ default = "us-east-1"
+ # No validation for approved regions - SECURITY ISSUE #24
+}
+
+variable "db_password" {
+ description = "Database password"
+ type = string
+ default = "changeme123" # SECURITY ISSUE #25 - Weak default password!
+ # Should not have a default value for passwords!
+ # Should be marked as sensitive!
+}
+
+variable "environment" {
+ description = "Environment name"
+ type = string
+ default = "production" # Defaulting to production is risky
+ # No validation
+}
+
+variable "enable_public_access" {
+ description = "Enable public access to resources"
+ type = bool
+ default = true # SECURITY ISSUE #26 - Public access enabled by default!
+}
+
+variable "enable_encryption" {
+ description = "Enable encryption"
+ type = bool
+ default = false # SECURITY ISSUE #27 - Encryption disabled by default!
+}
+
+variable "allowed_ssh_cidr" {
+ description = "CIDR blocks allowed for SSH"
+ type = list(string)
+ default = ["0.0.0.0/0"] # SECURITY ISSUE #28 - Allows SSH from anywhere!
+}
+
+variable "backup_retention_days" {
+ description = "Number of days to retain backups"
+ type = number
+ default = 0 # SECURITY ISSUE #29 - No backups by default!
+}
+
+variable "api_key" {
+ description = "API key for external service"
+ type = string
+ default = "sk_test_1234567890abcdef" # SECURITY ISSUE #30 - Hardcoded API key!
+ # Should not have default, should be sensitive
+}
+
+# No validation constraints on critical variables
+variable "instance_type" {
+ description = "EC2 instance type"
+ type = string
+ default = "t2.micro"
+ # No validation - could use expensive instance types
+}
+
+variable "allowed_regions" {
+ description = "List of allowed AWS regions"
+ type = list(string)
+ default = ["us-east-1", "us-west-2", "eu-west-1"]
+ # Not enforced anywhere in the code
+}
+
+# Missing required variables
+# - No variable for required resource tags
+# - No variable for KMS key IDs
+# - No variable for logging configuration
diff --git a/labs/lab7.md b/labs/lab7.md
new file mode 100644
index 00000000..48c23111
--- /dev/null
+++ b/labs/lab7.md
@@ -0,0 +1,414 @@
+# Lab 7 โ Container Security: Image Scanning & Deployment Hardening
+
+
+
+
+
+> **Goal:** Analyze container images for vulnerabilities, audit Docker host security, and compare secure deployment configurations.
+> **Deliverable:** A PR from `feature/lab7` to the course repo with `labs/submission7.md` containing vulnerability analysis, CIS benchmark results, and deployment security comparison. Submit the PR link via Moodle.
+
+---
+
+## Overview
+
+In this lab you will practice:
+- **Container image vulnerability scanning** using next-generation tools (Docker Scout, Snyk)
+- **Docker security benchmarking** with CIS Docker Benchmark compliance assessment
+- **Secure container deployment** analysis and configuration comparison
+- **Container security assessment** using modern scanning and analysis tools
+- **Security configuration impact** analysis for production deployments
+
+These skills are essential for implementing container security in DevSecOps pipelines and production environments.
+
+> Target application: OWASP Juice Shop (`bkimminich/juice-shop:v19.0.0`)
+
+---
+
+## Prerequisites
+
+### Docker Scout CLI Setup
+
+Docker Scout requires authentication and a CLI plugin installation.
+
+#### Step 1: Install Docker Scout CLI Plugin
+
+**For Linux/macOS:**
+```bash
+curl -sSfL https://raw.githubusercontent.com/docker/scout-cli/main/install.sh | sh -s --
+```
+
+**Verify installation:**
+```bash
+docker scout version
+```
+
+You should see output like: `version: v1.x.x`
+
+#### Step 2: Docker Hub Authentication
+
+Docker Scout requires a Docker Hub account and Personal Access Token (PAT).
+
+**Create account and generate PAT:**
+
+1. **Create Docker Hub account** (if needed): Visit https://hub.docker.com
+
+2. **Generate PAT:**
+
+ - Log in โ Account Settings โ Security โ Personal Access Tokens
+ - Click **New Access Token**
+ - Description: `Lab7 Docker Scout Access`
+ - Permissions: Select **Read, Write, Delete**
+ - Click **Generate** and copy the token immediately
+
+3. **Authenticate:**
+
+ ```bash
+ docker login
+ # Username: your-docker-hub-username
+ # Password: paste-your-PAT (not your password!)
+ ```
+
+4. **Verify access:**
+
+ ```bash
+ docker scout quickview busybox:latest
+ # Should display vulnerability scan results
+ ```
+
+**Why PAT over password?**
+- Limited scope permissions for least privilege
+- Easy to revoke without changing account password
+- Required for SSO-enabled organizations
+- Better audit trail
+
+Learn more: https://docs.docker.com/go/access-tokens/
+
+---
+
+## Tasks
+
+### Task 1 โ Image Vulnerability & Configuration Analysis (3 pts)
+
+**Objective:** Scan container images for vulnerabilities and configuration issues.
+
+#### 1.1: Setup Working Directory
+
+```bash
+mkdir -p labs/lab7/{scanning,hardening,analysis}
+cd labs/lab7
+```
+
+#### 1.2: Vulnerability Scanning
+
+```bash
+# Pull the image to scan locally
+docker pull bkimminich/juice-shop:v19.0.0
+
+# Detailed CVE analysis
+docker scout cves bkimminich/juice-shop:v19.0.0 | tee scanning/scout-cves.txt
+```
+
+**Understanding the output:**
+- **C/H/M/L** = Critical/High/Medium/Low severity counts
+- Look for CVE IDs, affected packages, and potential impact
+
+#### 1.3: Snyk comparison
+
+```bash
+# Requires Snyk account: https://snyk.io
+# Set token: export SNYK_TOKEN=your-token
+docker run --rm \
+ -e SNYK_TOKEN \
+ -v /var/run/docker.sock:/var/run/docker.sock \
+ snyk/snyk:docker snyk test --docker bkimminich/juice-shop:v19.0.0 --severity-threshold=high \
+ | tee scanning/snyk-results.txt
+```
+
+#### 1.4: Configuration Assessment
+
+```bash
+# Scan for security and best practice issues
+docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
+ goodwithtech/dockle:latest \
+ bkimminich/juice-shop:v19.0.0 | tee scanning/dockle-results.txt
+```
+
+**Look for:**
+- **FATAL/WARN** issues about running as root
+- Exposed secrets in environment variables
+- Missing security configurations
+- File permission issues
+
+**๐ Document in `labs/submission7.md`:**
+
+1. **Top 5 Critical/High Vulnerabilities**
+ - CVE ID, affected package, severity, and impact
+
+2. **Dockle Configuration Findings**
+ - List FATAL and WARN issues
+ - Explain why each is a security concern
+
+3. **Security Posture Assessment**
+ - Does the image run as root?
+ - What security improvements would you recommend?
+
+---
+
+### Task 2 โ Docker Host Security Benchmarking (3 pts)
+
+**Objective:** Audit Docker host configuration against CIS Docker Benchmark.
+
+#### 2.1: Run CIS Docker Benchmark
+
+```bash
+# Run CIS Docker Benchmark security audit
+docker run --rm --net host --pid host --userns host --cap-add audit_control \
+ -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \
+ -v /var/lib:/var/lib:ro \
+ -v /var/run/docker.sock:/var/run/docker.sock:ro \
+ -v /usr/lib/systemd:/usr/lib/systemd:ro \
+ -v /etc:/etc:ro --label docker_bench_security \
+ docker/docker-bench-security | tee hardening/docker-bench-results.txt
+```
+
+**Understanding the output:**
+- **[PASS]** - Security control properly configured
+- **[WARN]** - Potential issue requiring review
+- **[FAIL]** - Security control not properly configured
+- **[INFO]** - Informational (no action needed)
+
+**Key sections:**
+1. Host Configuration
+2. Docker daemon configuration
+3. Docker daemon configuration files
+4. Container Images and Build Files
+5. Container Runtime
+
+**๐ Document in `labs/submission7.md`:**
+
+1. **Summary Statistics**
+ - Total PASS/WARN/FAIL/INFO counts
+
+2. **Analysis of Failures** (if any)
+ - List failures and explain security impact
+ - Propose specific remediation steps
+
+---
+
+### Task 3 โ Deployment Security Configuration Analysis (4 pts)
+
+**Objective:** Compare deployment configurations to understand security hardening trade-offs.
+
+#### 3.1: Deploy Three Security Profiles
+
+```bash
+# Profile 1: Default (baseline)
+docker run -d --name juice-default -p 3001:3000 \
+ bkimminich/juice-shop:v19.0.0
+
+# Profile 2: Hardened (security restrictions)
+docker run -d --name juice-hardened -p 3002:3000 \
+ --cap-drop=ALL \
+ --security-opt=no-new-privileges \
+ --memory=512m \
+ --cpus=1.0 \
+ bkimminich/juice-shop:v19.0.0
+
+# Profile 3: Production (maximum hardening)
+docker run -d --name juice-production -p 3003:3000 \
+ --cap-drop=ALL \
+ --cap-add=NET_BIND_SERVICE \
+ --security-opt=no-new-privileges \
+ --security-opt=seccomp=default \
+ --memory=512m \
+ --memory-swap=512m \
+ --cpus=1.0 \
+ --pids-limit=100 \
+ --restart=on-failure:3 \
+ bkimminich/juice-shop:v19.0.0
+
+# Wait for startup
+sleep 15
+
+# Verify all containers are running
+docker ps -a --filter name=juice-
+```
+
+#### 3.2: Compare Configurations
+
+```bash
+# Test functionality
+echo "=== Functionality Test ===" | tee analysis/deployment-comparison.txt
+curl -s -o /dev/null -w "Default: HTTP %{http_code}\n" http://localhost:3001 | tee -a analysis/deployment-comparison.txt
+curl -s -o /dev/null -w "Hardened: HTTP %{http_code}\n" http://localhost:3002 | tee -a analysis/deployment-comparison.txt
+curl -s -o /dev/null -w "Production: HTTP %{http_code}\n" http://localhost:3003 | tee -a analysis/deployment-comparison.txt
+
+# Check resource usage
+echo "" | tee -a analysis/deployment-comparison.txt
+echo "=== Resource Usage ===" | tee -a analysis/deployment-comparison.txt
+docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}" \
+ juice-default juice-hardened juice-production | tee -a analysis/deployment-comparison.txt
+
+# Inspect security settings
+echo "" | tee -a analysis/deployment-comparison.txt
+echo "=== Security Configurations ===" | tee -a analysis/deployment-comparison.txt
+for container in juice-default juice-hardened juice-production; do
+ echo "" | tee -a analysis/deployment-comparison.txt
+ echo "Container: $container" | tee -a analysis/deployment-comparison.txt
+ docker inspect $container --format 'CapDrop: {{.HostConfig.CapDrop}}
+SecurityOpt: {{.HostConfig.SecurityOpt}}
+Memory: {{.HostConfig.Memory}}
+CPU: {{.HostConfig.CpuQuota}}
+PIDs: {{.HostConfig.PidsLimit}}
+Restart: {{.HostConfig.RestartPolicy.Name}}' | tee -a analysis/deployment-comparison.txt
+done
+```
+
+#### 3.3: Cleanup
+
+```bash
+docker stop juice-default juice-hardened juice-production
+docker rm juice-default juice-hardened juice-production
+```
+
+**๐ Document in `labs/submission7.md`:**
+
+#### 1. Configuration Comparison Table
+
+Create a table from `docker inspect` output comparing all three profiles:
+- Capabilities (dropped/added)
+- Security options
+- Resource limits (memory, CPU, PIDs)
+- Restart policy
+
+#### 2. Security Measure Analysis
+
+Research and explain EACH security flag:
+
+**a) `--cap-drop=ALL` and `--cap-add=NET_BIND_SERVICE`**
+- What are Linux capabilities? (Research this!)
+- What attack vector does dropping ALL capabilities prevent?
+- Why do we need to add back NET_BIND_SERVICE?
+- What's the security trade-off?
+
+**b) `--security-opt=no-new-privileges`**
+- What does this flag do? (Look it up!)
+- What type of attack does it prevent?
+- Are there any downsides to enabling it?
+
+**c) `--memory=512m` and `--cpus=1.0`**
+- What happens if a container doesn't have resource limits?
+- What attack does memory limiting prevent?
+- What's the risk of setting limits too low?
+
+**d) `--pids-limit=100`**
+- What is a fork bomb?
+- How does PID limiting help?
+- How to determine the right limit?
+
+**e) `--restart=on-failure:3`**
+- What does this policy do?
+- When is auto-restart beneficial? When is it risky?
+- Compare `on-failure` vs `always`
+
+#### 3. Critical Thinking Questions
+
+1. **Which profile for DEVELOPMENT? Why?**
+
+2. **Which profile for PRODUCTION? Why?**
+
+3. **What real-world problem do resource limits solve?**
+
+4. **If an attacker exploits Default vs Production, what actions are blocked in Production?**
+
+5. **What additional hardening would you add?**
+
+
+---
+
+## Acceptance Criteria
+
+- โ
Branch `feature/lab7` exists with commits for each task
+- โ
File `labs/submission7.md` contains required analysis for Tasks 1-3
+- โ
Vulnerability scanning completed with Docker Scout
+- โ
CIS Docker Benchmark audit completed
+- โ
Deployment security comparison completed
+- โ
All scan outputs committed to `labs/lab7/`
+- โ
PR from `feature/lab7` โ **course repo main branch** is open
+- โ
PR link submitted via Moodle before the deadline
+
+---
+
+## How to Submit
+
+1. Create a branch for this lab and push it to your fork:
+
+ ```bash
+ git switch -c feature/lab7
+ # create labs/submission7.md with your findings
+ git add labs/submission7.md labs/lab7/
+ git commit -m "docs: add lab7 submission - container security analysis"
+ git push -u origin feature/lab7
+ ```
+
+2. Open a PR from your fork's `feature/lab7` branch โ **course repository's main branch**.
+
+3. In the PR description, include:
+
+ ```text
+ - [x] Task 1 done โ Advanced Image Security & Configuration Analysis
+ - [x] Task 2 done โ Docker Security Benchmarking & Assessment
+ - [x] Task 3 done โ Secure Container Deployment Analysis
+ ```
+
+4. **Copy the PR URL** and submit it via **Moodle before the deadline**.
+
+---
+
+## Rubric (10 pts)
+
+| Criterion | Points |
+| ---------------------------------------------------------------- | -----: |
+| Task 1 โ Image vulnerability & configuration analysis | **3** |
+| Task 2 โ Docker host security benchmarking | **3** |
+| Task 3 โ Deployment security configuration analysis | **4** |
+| **Total** | **10** |
+
+---
+
+## Guidelines
+
+- Use clear Markdown headers to organize sections in `submission7.md`
+- Include evidence from tool outputs to support your analysis
+- Research security concepts thoroughlyโdon't copy-paste
+- Focus on understanding trade-offs between security and usability
+
+
+Container Security Resources
+
+**Documentation:**
+- [Docker Security](https://docs.docker.com/engine/security/)
+- [CIS Docker Benchmark](https://www.cisecurity.org/benchmark/docker)
+- [Linux Capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html)
+
+
+
+
+Expected Security Findings
+
+**Image Vulnerabilities:**
+- Outdated base packages with CVEs
+- Vulnerable dependencies
+- Missing security patches
+
+**CIS Benchmark:**
+- Insecure daemon configuration
+- Missing resource limits
+- Excessive privileges
+
+**Deployment Gaps:**
+- Running as root
+- Unnecessary capabilities
+- No resource limits
+
+
\ No newline at end of file
diff --git a/labs/lab8.md b/labs/lab8.md
new file mode 100644
index 00000000..1fda7f2c
--- /dev/null
+++ b/labs/lab8.md
@@ -0,0 +1,318 @@
+# Lab 8 โ Software Supply Chain Security: Signing, Verification, and Attestations
+
+
+
+
+
+> Goal: Sign and verify container images, attach and verify attestations (SBOM/provenance), and optionally sign non-container artifacts โ all locally, without code changes.
+> Deliverable: A PR from `feature/lab8` with `labs/submission8.md` containing signing/verification logs, attestation evidence, and a short analysis. Submit the PR link via Moodle.
+
+---
+
+## Overview
+
+In this lab you will practice:
+- Image signing/verification with Cosign against a local registry
+- Attestations (SBOM and provenance) and payload inspection
+- Optional artifact (blob) signing for non-container assets
+
+Context: Cosign is a widely used OSS tool for image signing and attestations. If you produced SBOMs in Lab 4, reuse them here for attestations.
+
+> Target application: `bkimminich/juice-shop:v19.0.0`
+
+---
+
+## Prerequisites
+
+- Docker (Docker Desktop or Engine) and internet access
+- `jq` for JSON processing
+- Cosign installed (binary)
+ - See: https://docs.sigstore.dev/cosign/system_config/installation/
+ - Verify: `cosign version`
+
+Install Cosign (quick start):
+
+```bash
+# Linux x86_64 (install to /usr/local/bin)
+curl -sSL -o cosign "https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64"
+chmod +x cosign && sudo mv cosign /usr/local/bin/
+
+# Verify
+cosign version
+```
+
+Docs:
+- Install guide: https://docs.sigstore.dev/cosign/system_config/installation/
+- Releases: https://github.com/sigstore/cosign/releases/latest
+
+Prepare working directories:
+```bash
+mkdir -p labs/lab8/{registry,signing,attest,analysis,artifacts}
+```
+
+---
+
+## Tasks
+
+### Task 1 โ Local Registry, Signing & Verification (4 pts)
+**Objective:** Push the image to a local registry, sign it with Cosign, and verify the signature, including a tamper demonstration.
+
+#### 1.1: Pull and push to local registry
+```bash
+# Pull target image
+docker pull bkimminich/juice-shop:v19.0.0
+
+# Start local registry on localhost:5000 (Distribution v3)
+docker run -d --restart=always -p 5000:5000 --name registry registry:3
+
+# Tag and push the image to the local registry
+docker tag bkimminich/juice-shop:v19.0.0 localhost:5000/juice-shop:v19.0.0
+docker push localhost:5000/juice-shop:v19.0.0
+
+# Recommended: use a digest reference (from the local registry) instead of a tag
+DIGEST=$(curl -sI \
+ -H 'Accept: application/vnd.docker.distribution.manifest.v2+json' \
+ http://localhost:5000/v2/juice-shop/manifests/v19.0.0 \
+ | tr -d '\r' | awk -F': ' '/Docker-Content-Digest/ {print $2}')
+REF="localhost:5000/juice-shop@${DIGEST}"
+echo "Using digest ref: $REF" | tee labs/lab8/analysis/ref.txt
+```
+
+#### 1.2: Generate a Cosign key pair for signing
+```bash
+cd labs/lab8/signing
+cosign generate-key-pair
+cd -
+# This creates cosign.key (private key) and cosign.pub (public key)
+# You will be prompted to set a passphrase for the private key
+```
+
+#### 1.3: Sign and verify the image
+```bash
+# Sign the image using your private key
+cosign sign --yes \
+ --allow-insecure-registry \
+ --tlog-upload=false \
+ --key labs/lab8/signing/cosign.key \
+ "$REF"
+
+# Verify the signature using your public key and save the output
+cosign verify \
+ --allow-insecure-registry \
+ --insecure-ignore-tlog \
+ --key labs/lab8/signing/cosign.pub \
+ "$REF"
+```
+
+> Note for students:
+> - This verify flow is valid for a local, insecure registry. You correctly use a digest reference and `--allow-insecure-registry`.
+> - The warning appears because you signed with `--tlog-upload=false`. Using `--insecure-ignore-tlog` tells Cosign to skip Rekor transparency log verification in this lab context.
+> - For production: remove `--insecure-ignore-tlog`, sign without `--tlog-upload=false` (so the signature is recorded in Rekor), avoid insecure registries, and always verify/sign by digest (not by tag).
+
+#### 1.4: Tamper demonstration
+```bash
+docker pull busybox:latest
+docker tag busybox:latest localhost:5000/juice-shop:v19.0.0
+docker push localhost:5000/juice-shop:v19.0.0
+
+# IMPORTANT: Re-resolve the tag to the NEW digest from the local registry
+DIGEST_AFTER=$(curl -sI \
+ -H 'Accept: application/vnd.docker.distribution.manifest.v2+json' \
+ http://localhost:5000/v2/juice-shop/manifests/v19.0.0 \
+ | tr -d '\r' | awk -F': ' '/Docker-Content-Digest/ {print $2}')
+REF_AFTER="localhost:5000/juice-shop@${DIGEST_AFTER}"
+echo "After tamper digest ref: $REF_AFTER" | tee labs/lab8/analysis/ref-after-tamper.txt
+
+# Verify should now FAIL for the new digest (not signed with your key)
+cosign verify \
+ --allow-insecure-registry \
+ --insecure-ignore-tlog \
+ --key labs/lab8/signing/cosign.pub \
+ "$REF_AFTER"
+
+# Sanity check: verifying the ORIGINAL digest still succeeds (supply chain best practice)
+cosign verify \
+ --allow-insecure-registry \
+ --insecure-ignore-tlog \
+ --key labs/lab8/signing/cosign.pub \
+ "$REF"
+```
+
+In `labs/submission8.md`, explain how signing protects against tag tampering and what โsubject digestโ means.
+
+---
+
+### Task 2 โ Attestations: SBOM (reuse) & Provenance (4 pts)
+
+**Objective:** Attach and verify attestations (SBOM and simple provenance) to the image and inspect the attestation envelope.
+
+```bash
+mkdir -p labs/lab4/syft
+docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
+ -v "$(pwd)":/tmp anchore/syft:latest \
+ "$REF" -o syft-json=/tmp/labs/lab4/syft/juice-shop-syft-native.json
+```
+
+Generate CycloneDX SBOM for attestation:
+
+```bash
+# Option A: Convert Syft-native SBOM from Lab 4 โ CycloneDX JSON
+docker run --rm \
+ -v "$(pwd)/labs/lab4/syft":/in:ro \
+ -v "$(pwd)/labs/lab8/attest":/out \
+ anchore/syft:latest \
+ convert /in/juice-shop-syft-native.json -o cyclonedx-json=/out/juice-shop.cdx.json
+```
+
+#### 2.1: SBOM as an attestation (CycloneDX)
+```bash
+# Example using CycloneDX SBOM created above
+cosign attest --yes \
+ --allow-insecure-registry \
+ --tlog-upload=false \
+ --key labs/lab8/signing/cosign.key \
+ --predicate labs/lab8/attest/juice-shop.cdx.json \
+ --type cyclonedx \
+ "$REF"
+
+# Verify the SBOM attestation
+cosign verify-attestation \
+ --allow-insecure-registry \
+ --insecure-ignore-tlog \
+ --key labs/lab8/signing/cosign.pub \
+ --type cyclonedx \
+ "$REF" \
+ | tee labs/lab8/attest/verify-sbom-attestation.txt
+```
+
+#### 2.2: Simple provenance attestation
+
+```bash
+# Create a minimal, valid SLSA Provenance v1 predicate with a proper RFC3339 timestamp
+BUILD_TS=$(date -u +%Y-%m-%dT%H:%M:%SZ)
+cat > labs/lab8/attest/provenance.json << EOF
+{
+ "_type": "https://slsa.dev/provenance/v1",
+ "buildType": "manual-local-demo",
+ "builder": {"id": "student@local"},
+ "invocation": {"parameters": {"image": "${REF}"}},
+ "metadata": {"buildStartedOn": "${BUILD_TS}", "completeness": {"parameters": true}}
+}
+EOF
+
+cosign attest --yes \
+ --allow-insecure-registry \
+ --tlog-upload=false \
+ --key labs/lab8/signing/cosign.key \
+ --predicate labs/lab8/attest/provenance.json \
+ --type slsaprovenance \
+ "$REF"
+
+# Verify the provenance attestation
+cosign verify-attestation \
+ --allow-insecure-registry \
+ --insecure-ignore-tlog \
+ --key labs/lab8/signing/cosign.pub \
+ --type slsaprovenance \
+ "$REF" | tee labs/lab8/attest/verify-provenance.txt
+```
+
+In `labs/submission8.md`, document:
+ - How attestations differ from signatures
+ - What information the SBOM attestation contains
+ - What provenance attestations provide for supply chain security
+---
+
+### Task 3 โ Artifact (Blob/Tarball) Signing (2 pts)
+
+**Objective:** Sign a non-container artifact (e.g., a tarball) and verify the signature.
+
+```bash
+echo "sample content $(date -u)" > labs/lab8/artifacts/sample.txt
+tar -czf labs/lab8/artifacts/sample.tar.gz -C labs/lab8/artifacts sample.txt
+
+# Option A: Cosign sign-blob using a bundle (recommended)
+cosign sign-blob \
+ --yes \
+ --tlog-upload=false \
+ --key labs/lab8/signing/cosign.key \
+ --bundle labs/lab8/artifacts/sample.tar.gz.bundle \
+ labs/lab8/artifacts/sample.tar.gz
+
+cosign verify-blob \
+ --key labs/lab8/signing/cosign.pub \
+ --bundle labs/lab8/artifacts/sample.tar.gz.bundle \
+ labs/lab8/artifacts/sample.tar.gz | tee labs/lab8/artifacts/verify-blob.txt
+```
+
+In `labs/submission8.md`, document:
+ - Use cases for signing non-container artifacts (e.g., release binaries, configuration files)
+ - How blob signing differs from container image signing
+
+---
+
+## Acceptance Criteria
+
+- โ
`labs/submission8.md` includes analysis and evidence for Tasks 1โ3
+- โ
Image pushed to local registry; Cosign signature created and verified
+- โ
Tamper scenario demonstrated and explained
+- โ
At least one attestation attached and verified (SBOM or provenance); payload inspected with `jq`
+- โ
Artifact signing performed and verified
+- โ
All outputs saved under `labs/lab8/` and committed
+
+---
+
+## How to Submit
+
+1. Create a branch for this lab and push it to your fork:
+
+```bash
+git switch -c feature/lab8
+# create labs/submission8.md with your findings
+git add labs/lab8/ labs/submission8.md
+git commit -m "docs: add lab8 submission โ signing + attestations"
+git push -u origin feature/lab8
+```
+
+2. Open a PR from your forkโs `feature/lab8` โ course repoโs `main`.
+3. Include this checklist in the PR description:
+
+```text
+- [x] Task 1 โ Local registry, signing, verification (+ tamper demo)
+- [x] Task 2 โ Attestations (SBOM or provenance) + payload inspection
+- [x] Task 3 โ Artifact signing (blob/tarball)
+```
+
+4. Submit the PR URL via Moodle before the deadline.
+
+---
+
+## Rubric (10 pts)
+
+| Criterion | Points |
+| ------------------------------------------------------------- | -----: |
+| Task 1 โ Local Registry, Signing & Verification | 4.0 |
+| Task 2 โ SBOM/Provenance Attestations (verify + inspect) | 4.0 |
+| Task 3 โ Artifact (Blob/Tarball) Signing | 2.0 |
+| Total | 10.0 |
+
+---
+
+## Guidelines
+
+- Use the Cosign binary (most widely tested in 2025 for local flows)
+- Keep keys out of version control; commit only logs and reports
+- Use strong passphrases; rotate and store securely
+- Reuse your Lab 4 SBOM for attestation if possible; otherwise create a minimal predicate JSON
+
+
+References
+
+- Cosign install: https://docs.sigstore.dev/cosign/system_config/installation/
+- in-toto/attestations: https://github.com/in-toto/attestation
+- CycloneDX: https://cyclonedx.org/
+- SPDX: https://spdx.dev/
+
+
+
+
diff --git a/labs/lab9.md b/labs/lab9.md
new file mode 100644
index 00000000..91e20bef
--- /dev/null
+++ b/labs/lab9.md
@@ -0,0 +1,239 @@
+# Lab 9 โ Monitoring & Compliance: Falco Runtime Detection + Conftest Policies
+
+
+
+
+
+> Goal: Detect suspicious container behavior with Falco and enforce deployment hardening via policy-as-code using Conftest (Rego) โ all runnable locally.
+> Deliverable: A PR from `feature/lab9` with `labs/submission9.md` containing Falco alert evidence, custom rule/tuning notes, Conftest test results, and analysis of provided manifests/policies. Submit the PR link via Moodle.
+
+---
+
+## Overview
+
+In this lab you will practice:
+- Runtime threat detection for containers with Falco (eBPF)
+- Writing/customizing Falco rules and tuning noise/false positives
+- Policy-as-code with Conftest (OPA/Rego) against Kubernetes manifests
+- Analyzing how security policies enforce deployment hardening best practices
+
+> Runtime target for Task 1: BusyBox helper container (`alpine:3.19`).
+
+---
+
+## Prerequisites
+
+- Docker (or Docker Desktop)
+- `jq`
+- Optional: `kubectl` or a local K8s (kind/minikube) is NOT required โ Conftest runs offline against YAML
+
+Prepare working directories:
+```bash
+mkdir -p labs/lab9/{falco/{rules,logs},analysis}
+```
+
+---
+
+## Tasks
+
+### Task 1 โ Runtime Security Detection with Falco (6 pts)
+**Objective:** Run Falco with modern eBPF, trigger alerts from a shell-enabled BusyBox container, and add one custom rule with basic tuning.
+
+#### 1.1: Start a shell-enabled helper container
+```bash
+# Use Alpine (BusyBox) to trigger events โ no app needed
+docker run -d --name lab9-helper alpine:3.19 sleep 1d
+```
+
+#### 1.2: Run Falco (containerized) with modern eBPF
+```bash
+# Start Falco container (JSON output to stdout)
+docker run -d --name falco \
+ --privileged \
+ -v /proc:/host/proc:ro \
+ -v /boot:/host/boot:ro \
+ -v /lib/modules:/host/lib/modules:ro \
+ -v /usr:/host/usr:ro \
+ -v /var/run/docker.sock:/host/var/run/docker.sock \
+ -v "$(pwd)/labs/lab9/falco/rules":/etc/falco/rules.d:ro \
+ falcosecurity/falco:latest \
+ falco -U \
+ -o json_output=true \
+ -o time_format_iso_8601=true
+
+# Follow Falco logs
+docker logs -f falco | tee labs/lab9/falco/logs/falco.log &
+```
+
+Note: The official Falco image defaults to the modern eBPF engine (engine.kind=modern_ebpf). No extra flag is needed beyond running with the required privileges and mounts.
+
+#### 1.3: Trigger two baseline alerts
+```bash
+# A) Terminal shell inside container (expected rule: Terminal shell in container)
+docker exec -it lab9-helper /bin/sh -lc 'echo hello-from-shell'
+
+# B) Container drift: write under a binary directory
+# Writes to /usr/local/bin should trigger Falco's drift detection
+docker exec --user 0 lab9-helper /bin/sh -lc 'echo boom > /usr/local/bin/drift.txt'
+```
+
+#### 1.4: Add one custom Falco rule and validate
+Create `labs/lab9/falco/rules/custom-rules.yaml`:
+```yaml
+# Detect new writable file under /usr/local/bin inside any container
+- rule: Write Binary Under UsrLocalBin
+ desc: Detects writes under /usr/local/bin inside any container
+ condition: evt.type in (open, openat, openat2, creat) and
+ evt.is_open_write=true and
+ fd.name startswith /usr/local/bin/ and
+ container.id != host
+ output: >
+ Falco Custom: File write in /usr/local/bin (container=%container.name user=%user.name file=%fd.name flags=%evt.arg.flags)
+ priority: WARNING
+ tags: [container, compliance, drift]
+```
+
+Falco auto-reloads rules in `/etc/falco/rules.d`. If you don't see your custom alert after a minute, force a reload:
+```bash
+docker kill --signal=SIGHUP falco && sleep 2
+```
+
+Validate the custom rule by triggering another write:
+```bash
+# This should trigger BOTH the built-in drift rule AND your custom rule
+docker exec --user 0 lab9-helper /bin/sh -lc 'echo custom-test > /usr/local/bin/custom-rule.txt'
+```
+
+#### 1.5: Generate Falco test events
+```bash
+# Falco event generator creates a short burst of detectable actions
+docker run --rm --name eventgen \
+ --privileged \
+ -v /proc:/host/proc:ro -v /dev:/host/dev \
+ falcosecurity/event-generator:latest run syscall
+```
+
+What this does
+Executes a curated set of syscalls (e.g., fileless execution, sensitive file reads) that should appear as Falco alerts. This helps verify your Falco setup is working correctly.
+
+
+In `labs/submission9.md`, document:
+- Baseline alerts observed from `falco.log`
+- Your custom ruleโs purpose and when it should/shouldnโt fire
+
+---
+
+### Task 2 โ Policy-as-Code with Conftest (Rego) (4 pts)
+**Objective:** Run provided security policies against K8s manifests, analyze policy violations, and understand how hardening satisfies compliance requirements.
+
+#### 2.1: Review provided Kubernetes manifests
+Open and review the provided manifests:
+- `labs/lab9/manifests/k8s/juice-unhardened.yaml` (baseline โ do NOT edit)
+- `labs/lab9/manifests/k8s/juice-hardened.yaml` (compliant version)
+
+Compare both manifests to understand what hardening changes were applied.
+
+#### 2.2: Review provided Conftest Rego policies
+Examine the provided security policies:
+- `labs/lab9/policies/k8s-security.rego` โ enforces Kubernetes security best practices
+- `labs/lab9/policies/compose-security.rego` โ enforces Docker Compose security patterns
+
+These policies check for common misconfigurations like running as root, missing resource limits, privileged containers, etc.
+
+#### 2.3: Run Conftest against both manifests
+```bash
+# Test unhardened manifest (expect policy violations)
+docker run --rm -v "$(pwd)/labs/lab9":/project \
+ openpolicyagent/conftest:latest \
+ test /project/manifests/k8s/juice-unhardened.yaml -p /project/policies --all-namespaces | tee labs/lab9/analysis/conftest-unhardened.txt
+
+# Test hardened manifest (should pass or only warnings)
+docker run --rm -v "$(pwd)/labs/lab9":/project \
+ openpolicyagent/conftest:latest \
+ test /project/manifests/k8s/juice-hardened.yaml -p /project/policies --all-namespaces | tee labs/lab9/analysis/conftest-hardened.txt
+
+# Test Docker Compose manifest
+docker run --rm -v "$(pwd)/labs/lab9":/project \
+ openpolicyagent/conftest:latest \
+ test /project/manifests/compose/juice-compose.yml -p /project/policies --all-namespaces | tee labs/lab9/analysis/conftest-compose.txt
+```
+
+In `labs/submission9.md`, document:
+- The policy violations from the unhardened manifest and why each matters for security
+- The specific hardening changes in the hardened manifest that satisfy policies
+- Analysis of the Docker Compose manifest results
+
+---
+
+## Acceptance Criteria
+
+- โ
Branch `feature/lab9` contains Falco setup, logs, and a custom rule file
+- โ
At least two Falco alerts captured and explained (baseline + custom)
+- โ
Conftest policies reviewed and tested against manifests
+- โ
Unhardened K8s manifest fails; hardened manifest passes (warnings OK)
+- โ
`labs/submission9.md` includes evidence and analysis for both tasks
+
+---
+
+## How to Submit
+
+1. Create a branch and push it to your fork:
+```bash
+git switch -c feature/lab9
+# create labs/submission9.md with your findings
+git add labs/lab9/ labs/submission9.md
+git commit -m "docs: add lab9 โ falco runtime + conftest policies"
+git push -u origin feature/lab9
+```
+2. Open a PR from your forkโs `feature/lab9` โ course repoโs `main`.
+3. In the PR description include:
+```text
+- [x] Task 1 โ Falco runtime detection (alerts + custom rule)
+- [x] Task 2 โ Conftest policies (failโpass hardening)
+```
+4. Submit the PR URL via Moodle before the deadline.
+
+---
+
+## Rubric (10 pts)
+
+| Criterion | Points |
+| --------------------------------------------------------------- | -----: |
+| Task 1 โ Falco runtime detection + custom rule | 6.0 |
+| Task 2 โ Conftest policies + hardened manifests | 4.0 |
+| Total | 10.0 |
+
+---
+
+## Guidelines
+
+- Keep Falco running while you trigger events; copy only relevant alert lines into your submission
+- Place custom Falco rules under `labs/lab9/falco/rules/` and commit them
+- Conftest โdenyโ enforces hard requirements; โwarnโ provides guidance without failing
+- Aim for minimal, practical policies that reflect production hardening baselines
+
+
+References
+
+- Falco: https://falco.org/docs/
+- Falco container: https://github.com/falcosecurity/falco
+- Event Generator: https://github.com/falcosecurity/event-generator
+- Conftest: https://github.com/open-policy-agent/conftest
+- OPA/Rego: https://www.openpolicyagent.org/docs/
+
+
+
+
+Troubleshooting
+
+- Falco engine: If Falco logs show that modern eBPF is unsupported, switch engine with: `-o engine.kind=ebpf` in the `docker run` command.
+- Permissions: Ensure Docker is running and you can run privileged containers. If `--privileged` or mounts fail, try a Linux host or WSL2.
+- Container context: For drift tests, write from inside the container (not `docker cp`) so Falco reports a non-host `container.id`.
+- Conftest: If pulling the image fails, try specifying a version tag, e.g., `openpolicyagent/conftest:v0.63.0`.
+
+
+
+### Cleanup
+```bash
+docker rm -f falco lab9-helper 2>/dev/null || true
+```
diff --git a/labs/lab9/manifests/compose/juice-compose.yml b/labs/lab9/manifests/compose/juice-compose.yml
new file mode 100644
index 00000000..acfcb64b
--- /dev/null
+++ b/labs/lab9/manifests/compose/juice-compose.yml
@@ -0,0 +1,11 @@
+services:
+ juice:
+ image: bkimminich/juice-shop:v19.0.0
+ ports: ["3006:3000"]
+ user: "10001:10001"
+ read_only: true
+ tmpfs: ["/tmp"]
+ security_opt:
+ - no-new-privileges:true
+ cap_drop: ["ALL"]
+
diff --git a/labs/lab9/manifests/k8s/juice-hardened.yaml b/labs/lab9/manifests/k8s/juice-hardened.yaml
new file mode 100644
index 00000000..10521196
--- /dev/null
+++ b/labs/lab9/manifests/k8s/juice-hardened.yaml
@@ -0,0 +1,45 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: juice-hardened
+spec:
+ replicas: 1
+ selector:
+ matchLabels: { app: juice }
+ template:
+ metadata:
+ labels: { app: juice }
+ spec:
+ containers:
+ - name: juice
+ image: bkimminich/juice-shop:v19.0.0
+ securityContext:
+ runAsNonRoot: true
+ allowPrivilegeEscalation: false
+ readOnlyRootFilesystem: true
+ capabilities:
+ drop: ["ALL"]
+ resources:
+ requests: { cpu: "100m", memory: "256Mi" }
+ limits: { cpu: "500m", memory: "512Mi" }
+ ports:
+ - containerPort: 3000
+ readinessProbe:
+ httpGet: { path: /, port: 3000 }
+ initialDelaySeconds: 5
+ periodSeconds: 10
+ livenessProbe:
+ httpGet: { path: /, port: 3000 }
+ initialDelaySeconds: 10
+ periodSeconds: 20
+---
+apiVersion: v1
+kind: Service
+metadata:
+ name: juice-hardened
+spec:
+ selector: { app: juice }
+ ports:
+ - port: 80
+ targetPort: 3000
+
diff --git a/labs/lab9/manifests/k8s/juice-unhardened.yaml b/labs/lab9/manifests/k8s/juice-unhardened.yaml
new file mode 100644
index 00000000..94e96fc3
--- /dev/null
+++ b/labs/lab9/manifests/k8s/juice-unhardened.yaml
@@ -0,0 +1,28 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+ name: juice-unhardened
+spec:
+ replicas: 1
+ selector:
+ matchLabels: { app: juice }
+ template:
+ metadata:
+ labels: { app: juice }
+ spec:
+ containers:
+ - name: juice
+ image: bkimminich/juice-shop:latest
+ ports:
+ - containerPort: 3000
+---
+apiVersion: v1
+kind: Service
+metadata:
+ name: juice-unhardened
+spec:
+ selector: { app: juice }
+ ports:
+ - port: 80
+ targetPort: 3000
+
diff --git a/labs/lab9/policies/compose-security.rego b/labs/lab9/policies/compose-security.rego
new file mode 100644
index 00000000..eebca76b
--- /dev/null
+++ b/labs/lab9/policies/compose-security.rego
@@ -0,0 +1,33 @@
+package compose.security
+
+containers := input.services
+
+# Helper: true if array arr contains value v
+has_value(arr, v) if {
+ some i
+ arr[i] == v
+}
+
+deny contains msg if {
+ svc := containers[_]
+ not svc.user
+ msg := "services must set an explicit non-root user"
+}
+
+deny contains msg if {
+ svc := containers[_]
+ not svc.read_only
+ msg := "services must set read_only: true"
+}
+
+deny contains msg if {
+ svc := containers[_]
+ not has_value(svc.cap_drop, "ALL")
+ msg := "services must drop ALL capabilities"
+}
+
+warn contains msg if {
+ svc := containers[_]
+ not has_value(svc.security_opt, "no-new-privileges:true")
+ msg := "services should enable no-new-privileges"
+}
diff --git a/labs/lab9/policies/k8s-security.rego b/labs/lab9/policies/k8s-security.rego
new file mode 100644
index 00000000..041ff3bd
--- /dev/null
+++ b/labs/lab9/policies/k8s-security.rego
@@ -0,0 +1,88 @@
+package k8s.security
+
+# Helper: true if array arr contains value v
+has_value(arr, v) if {
+ some i
+ arr[i] == v
+}
+
+# No :latest tags
+deny contains msg if {
+ input.kind == "Deployment"
+ c := input.spec.template.spec.containers[_]
+ endswith(c.image, ":latest")
+ msg := sprintf("container %q uses disallowed :latest tag", [c.name])
+}
+
+# Require essential securityContext settings
+deny contains msg if {
+ input.kind == "Deployment"
+ c := input.spec.template.spec.containers[_]
+ not c.securityContext.runAsNonRoot
+ msg := sprintf("container %q must set runAsNonRoot: true", [c.name])
+}
+
+deny contains msg if {
+ input.kind == "Deployment"
+ c := input.spec.template.spec.containers[_]
+ not c.securityContext.allowPrivilegeEscalation == false
+ msg := sprintf("container %q must set allowPrivilegeEscalation: false", [c.name])
+}
+
+deny contains msg if {
+ input.kind == "Deployment"
+ c := input.spec.template.spec.containers[_]
+ not c.securityContext.readOnlyRootFilesystem == true
+ msg := sprintf("container %q must set readOnlyRootFilesystem: true", [c.name])
+}
+
+deny contains msg if {
+ input.kind == "Deployment"
+ c := input.spec.template.spec.containers[_]
+ not has_value(c.securityContext.capabilities.drop, "ALL")
+ msg := sprintf("container %q must drop ALL capabilities", [c.name])
+}
+
+# Require CPU/Memory requests and limits
+deny contains msg if {
+ input.kind == "Deployment"
+ c := input.spec.template.spec.containers[_]
+ not c.resources.requests.cpu
+ msg := sprintf("container %q missing resources.requests.cpu", [c.name])
+}
+
+deny contains msg if {
+ input.kind == "Deployment"
+ c := input.spec.template.spec.containers[_]
+ not c.resources.requests.memory
+ msg := sprintf("container %q missing resources.requests.memory", [c.name])
+}
+
+deny contains msg if {
+ input.kind == "Deployment"
+ c := input.spec.template.spec.containers[_]
+ not c.resources.limits.cpu
+ msg := sprintf("container %q missing resources.limits.cpu", [c.name])
+}
+
+deny contains msg if {
+ input.kind == "Deployment"
+ c := input.spec.template.spec.containers[_]
+ not c.resources.limits.memory
+ msg := sprintf("container %q missing resources.limits.memory", [c.name])
+}
+
+# Recommend probes
+warn contains msg if {
+ input.kind == "Deployment"
+ c := input.spec.template.spec.containers[_]
+ not c.readinessProbe
+ msg := sprintf("container %q should define readinessProbe", [c.name])
+}
+
+warn contains msg if {
+ input.kind == "Deployment"
+ c := input.spec.template.spec.containers[_]
+ not c.livenessProbe
+ msg := sprintf("container %q should define livenessProbe", [c.name])
+}
diff --git a/labs/submission12.md b/labs/submission12.md
new file mode 100644
index 00000000..94846308
--- /dev/null
+++ b/labs/submission12.md
@@ -0,0 +1,131 @@
+### Task 1
+
+```bash
+$ containerd-shim-kata-v2 --version
+Kata Containers containerd shim (Rust): id: io.containerd.kata.v2, version: 3.23.0, commit: 8534afb9e8de3a529a537185f0fd55b66d9bc5d5
+```
+
+```bash
+$ sudo nerdctl run --rm --runtime io.containerd.kata.v2 alpine:3.19 uname -a
+[sudo] password for bulatgazizov:
+WARN[0000] cannot set cgroup manager to "systemd" for runtime "io.containerd.kata.v2"
+Linux 329d9f7433ab 6.12.47 #1 SMP Fri Nov 14 15:34:06 UTC 2025 x86_64 Linux
+```
+
+### Task 2
+
+Runc:
+```
+juice-runc: HTTP 000
+```
+
+Kernels version:
+
+- Runc - 6.15.4
+- Kata - 6.12.47
+
+=== CPU Model Comparison ===
+- Host CPU:
+model name : 12th Gen Intel(R) Core(TM) i5-12450H
+- Kata VM CPU:
+model name : Intel(R) Xeon(R) Processor
+
+
+| Feature | runc | Kata Containers |
+| :--- | :--- | :--- |
+| **Primary Isolation** | Linux kernel namespaces & cgroups | Hardware-assisted Virtualization (VM) |
+| **Security Boundary** | The Linux Kernel (single, shared) | The Hypervisor (dedicated kernel per pod) |
+| **Architecture** | Single kernel, multiple isolated processes | Multiple, lightweight Virtual Machines |
+| **Performance** | **Native** (very low overhead) | **Near-Native** (low, but higher than runc) |
+| **Attack Surface** | Larger (shared kernel syscall interface) | Smaller (hardware-enforced VM isolation) |
+
+
+### Task 3
+
+#### Kata dmesg output:
+```
+[ 0.000000] Linux version 6.12.47 (@4bcec8f4443d) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04.2) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #1 SMP Fri Nov 14 15:34:06 UTC 2025
+[ 0.000000] Command line: reboot=k panic=1 systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service root=/dev/vda1 rootflags=data=ordered,errors=remount-ro ro rootfstype=ext4 agent.container_pipe_size=1 console=ttyS1 agent.log_vport=1025 agent.passfd_listener_port=1027 virtio_mmio.device=8K@0xe0000000:5 virtio_mmio.device=8K@0xe0002000:5
+[ 0.000000] BIOS-provided physical RAM map:
+[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
+```
+
+#### Comparison of /proc filesystem visibility
+
+* Host: 528
+* Kata VM: 53
+
+#### Network interface configuration in Kata VM
+
+```
+Kata VM network:
+1: lo: mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
+ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
+ inet 127.0.0.1/8 scope host lo
+ valid_lft forever preferred_lft forever
+ inet6 ::1/128 scope host noprefixroute
+ valid_lft forever preferred_lft forever
+2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
+ link/ether 7a:70:25:f0:55:84 brd ff:ff:ff:ff:ff:ff
+ inet 10.4.0.13/24 brd 10.4.0.255 scope global eth0
+ valid_lft forever preferred_lft forever
+ inet6 fe80::7870:25ff:fef0:5584/64 scope link tentative
+ valid_lft forever preferred_lft forever
+```
+
+#### Comparison of kernel module counts (host vs guest VM)
+* Host kernel modules: 354
+* Kata guest kernel modules: 72
+
+
+#### Explain isolation boundary differences:
+
+runc: All containers share the host kernel. A kernel panic or exploit affects everyone.
+
+Kata: Each pod has its own kernel. A kernel crash/exploit inside Kata only affects that specific pod - the host and other pods remain unaffected.
+
+---
+runc: Uses PID namespaces to hide processes, but all containers see the same kernel's /proc structure and potentially can probe kernel state
+
+Kata: The guest VM only sees processes and kernel information from its own isolated kernel instance. It cannot see host processes or other pods' processes at all.
+
+---
+runc: Uses network namespaces with veth pairs. Container shares host kernel networking stack.
+
+Kata: Gets a virtual network device (virtio) in its own VM. The network stack is completely isolated at the kernel level - different TCP/IP stack, different routing tables, different connection tracking.
+
+---
+runc: Exposes the entire host kernel with 354 loaded modules to each container
+
+Kata: The guest VM uses a minimized, hardened kernel with only essential modules (72). Even if compromised, the attacker only gets a reduced kernel, not the full host kernel.
+
+#### Discuss security implications:
+Container escape in runc = Breaking out of Linux namespaces/cgroups to access the host system
+
+Container escape in Kata = Minimal guest kernel with 72 modules + hypervisor
+
+### Task 4
+
+#### Startup time comparison
+
+* Runc - 0.6sec
+* Kata - 6.6sec
+
+#### HTTP latency for juice-runc baseline:
+
+avg=0.0003s min=0.0001s max=0.0005s n=50
+
+#### Analyze performance tradeoffs:
+
+Startup Overhead: 10x slower
+* runc: 0.6s (near-instant process creation)
+* Kata: 6.6s (VM boot + guest kernel initialization)
+
+Runtime overhead: 1-5% runtime overhead for most workloads
+
+CPU overhead: Hypervisor translation layer adds minor instruction overhead
+
+Interpret when to use each:
+- Use runc when: High-density microservices OR Serverless functions running on controlled environments.
+
+- Use Kata when: Untrusted code execution, kernel vulnerabilities would be catastrophic
\ No newline at end of file
diff --git a/lectures/lec1.md b/lectures/lec1.md
index 1cfe8b8a..21063c0c 100644
--- a/lectures/lec1.md
+++ b/lectures/lec1.md
@@ -934,8 +934,8 @@ else:
```mermaid
flowchart TD
- ATTACK[๐งญ MITRE ATT&CK] --> Tactics[๐ Tactics (why?)]
- ATTACK --> Techniques[๐ ๏ธ Techniques (how?)]
+ ATTACK[๐งญ MITRE ATT&CK] --> Tactics[๐ Tactics why?]
+ ATTACK --> Techniques[๐ ๏ธ Techniques how?]
ATTACK --> Mitigations[๐ก๏ธ Mitigations]
ATTACK --> Detections[๐ Detection Methods]
```
diff --git a/lectures/lec10.md b/lectures/lec10.md
new file mode 100644
index 00000000..b6f8edd5
--- /dev/null
+++ b/lectures/lec10.md
@@ -0,0 +1,2129 @@
+# ๐ฏ Lecture 10 - Vulnerability Management & Response: Discovery, Triage & Remediation
+
+## ๐ Group 1: Vulnerability Discovery
+
+## ๐ Slide 1 โ ๐ Vulnerability Discovery Methods
+
+* ๐ **Vulnerability discovery** = finding security issues before attackers do
+* ๐ฏ **Multiple sources:** Scanners, researchers, users, attackers
+* ๐ **Coverage:** Different methods find different vulnerabilities
+* ๐ **Defense in depth:** Use all methods for maximum coverage
+
+```mermaid
+flowchart LR
+ subgraph "๐ Discovery Methods"
+ Auto[๐ค Automated
Scanners]
+ Manual[๐จโ๐ป Manual
Testing]
+ External[๐ External
Sources]
+ end
+
+ Auto --> Vulns[๐ Vulnerabilities]
+ Manual --> Vulns
+ External --> Vulns
+
+ Vulns --> Triage[๐ฏ Triage]
+
+ style Vulns fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+```
+
+```mermaid
+flowchart LR
+ SAST[๐ SAST
Code Analysis] --> Coverage[๐ Total Coverage]
+ DAST[๐ DAST
Runtime Testing] --> Coverage
+ SCA[๐ฆ SCA
Dependencies] --> Coverage
+ Pentest[๐ฏ Pentesting
Manual] --> Coverage
+ BugBounty[๐ฐ Bug Bounty
Researchers] --> Coverage
+
+ Coverage --> Target[๐ฏ 95%+ Goal]
+
+ style Coverage fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+ style Target fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ค Automated Scanning Methods
+
+**๐ SAST (Static Application Security Testing):**
+* โ
Scans source code without running it
+* ๐ฏ Finds: SQL injection, XSS, hardcoded secrets, buffer overflows
+* โฐ When: Every commit, pull request
+* ๐ ๏ธ Tools: Snyk Code, Semgrep, SonarQube, Checkmarx
+* ๐ Coverage: ~70% of code vulnerabilities
+
+**๐ DAST (Dynamic Application Security Testing):**
+* โ
Tests running application (black-box approach)
+* ๐ฏ Finds: Authentication flaws, runtime issues, injection attacks
+* โฐ When: Staging/pre-production environments
+* ๐ ๏ธ Tools: OWASP ZAP, Burp Suite, Acunetix
+* ๐ Coverage: Runtime vulnerabilities
+
+**๐ฆ SCA (Software Composition Analysis):**
+* โ
Scans dependencies for known vulnerabilities
+* ๐ฏ Finds: Vulnerable libraries, outdated packages, license issues
+* โฐ When: Every build, continuous monitoring
+* ๐ ๏ธ Tools: Snyk, Grype, Dependabot, OWASP Dependency-Check
+* ๐ Covered in: Lab 8 (Supply Chain Security)
+
+**โ๏ธ IaC Scanning:**
+* โ
Scans infrastructure code
+* ๐ฏ Finds: Misconfigurations, compliance violations, overpermissions
+* โฐ When: Pre-commit, pull request
+* ๐ ๏ธ Tools: Checkov, tfsec, Terrascan, KICS
+* ๐ Covered in: Lab 6 (Infrastructure Security)
+
+**๐ณ Container Scanning:**
+* โ
Scans container images and layers
+* ๐ฏ Finds: OS vulnerabilities, malware, secrets in images
+* โฐ When: Build time, registry push
+* ๐ ๏ธ Tools: Trivy, Grype, Snyk Container, Aqua
+* ๐ Covered in: Lab 7 (Container Security)
+
+---
+
+### ๐จโ๐ป Manual Testing Methods
+
+**๐ฏ Penetration Testing:**
+* โ
Ethical hackers simulate real attacks
+* ๐ Finds: Complex logic flaws, business logic vulnerabilities, chained exploits
+* โฐ When: Quarterly, before major releases, after architecture changes
+* ๐ฅ Who: External security firms or internal red team
+* ๐ฐ Cost: $10K-$100K per engagement
+* ๐ Coverage: Real-world exploitability
+
+**๐ Security Code Review:**
+* โ
Developers review code for security issues
+* ๐ Finds: Logic errors, design flaws, subtle vulnerabilities
+* โฐ When: Every pull request (peer review process)
+* ๐ฏ Focus: Critical paths, authentication, authorization, data handling
+* ๐ Best practice: Security champion reviews critical changes
+
+**๐ Security Audits:**
+* โ
Comprehensive security assessment
+* ๐ Finds: Process gaps, architectural issues, compliance violations
+* โฐ When: Annually, before compliance audits (SOC 2, ISO 27001)
+* ๐ฅ Who: External auditors, security consultants
+* ๐ Coverage: People, process, technology
+
+---
+
+### ๐ External Discovery Sources
+
+**๐ฐ Bug Bounty Programs:**
+* โ
Security researchers find bugs for rewards
+* ๐ Platforms: HackerOne, Bugcrowd, Synack, Intigriti
+* ๐ Finds: Real-world exploitable issues, creative attack vectors
+* ๐ต Cost: Pay per valid bug ($100-$100K+ per finding)
+* ๐ฏ Benefit: Continuous testing by global researchers
+
+**๐จ CVE Alerts & Feeds:**
+* โ
New vulnerabilities in your dependencies
+* ๐ Sources: NVD, GitHub Advisory, OSV, vendor feeds
+* ๐ค Automated: Dependabot alerts, Snyk monitoring
+* โฐ Frequency: Daily monitoring required
+* ๐ง Notification: Real-time alerts for critical CVEs
+
+**๐ต๏ธ Threat Intelligence:**
+* โ
Known attack patterns, indicators of compromise (IOCs)
+* ๐ก Sources: CISA, vendor threat feeds, ISACs, dark web monitoring
+* ๐ฏ Benefit: Proactive defense against emerging threats
+* ๐ Integration: SIEM, EDR, firewalls
+
+**๐ง User/Customer Reports:**
+* โ
Customers discover and report issues
+* ๐ฌ Channel: security@company.com mailbox
+* ๐ Portal: Bug reporting form
+* ๐ค Response: Thank users, validate, fix, credit (if requested)
+
+
+๐ญ Coverage Gap Analysis: Why multiple methods?
+
+**โ Each method has blind spots:**
+
+| Method | โ
Finds | โ Misses |
+|--------|---------|----------|
+| ๐ **SAST** | Code-level flaws | Runtime issues, dependencies |
+| ๐ **DAST** | Runtime flaws | Internal logic, code quality |
+| ๐ฆ **SCA** | Dependency vulns | Custom code vulnerabilities |
+| ๐ฏ **Pentesting** | Real exploits | Doesn't scale, expensive |
+| ๐ฅ **Code Review** | Design flaws | Automated detectable issues |
+
+**โ
Defense in depth:** Use all methods for 95%+ coverage
+
+**๐ก Strategy:**
+* ๐ค Automate: SAST, DAST, SCA (daily/weekly)
+* ๐จโ๐ป Manual: Pentests, audits (quarterly)
+* ๐ External: Bug bounty (continuous)
+
+
+```mermaid
+flowchart TD
+ Method[๐ Method] --> Finds[โ
Finds] & Misses[โ Misses]
+
+ SAST[๐ SAST] --> F1[Code flaws] & M1[Runtime issues]
+ DAST[๐ DAST] --> F2[Runtime flaws] & M2[Logic issues]
+ SCA[๐ฆ SCA] --> F3[Dependency vulns] & M3[Custom code]
+
+ F1 --> Solution[โ
Use ALL Methods]
+ F2 --> Solution
+ F3 --> Solution
+ M1 --> Solution
+ M2 --> Solution
+ M3 --> Solution
+
+ Solution --> Result[๐ฏ 95%+ Coverage]
+
+ style Solution fill:#e8f5e8,stroke:#388e3c,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+## ๐ Slide 2 โ ๐ ๏ธ Security Testing Orchestration
+
+* ๐ฏ **Orchestration** = coordinating multiple security tools into unified workflow
+* ๐ **Problem:** Tool sprawl (10+ security tools, different outputs, duplicates)
+* ๐ **Solution:** Centralized platform for aggregation and deduplication
+* โก **Benefit:** Single pane of glass, consistent prioritization
+
+```mermaid
+flowchart LR
+ SAST[๐ SAST
Semgrep] --> Platform[๐ Orchestration
Platform]
+ DAST[๐ DAST
ZAP] --> Platform
+ SCA[๐ฆ SCA
Snyk] --> Platform
+ IaC[โ๏ธ IaC
Checkov] --> Platform
+ Container[๐ณ Container
Trivy] --> Platform
+
+ Platform --> Dedupe[๐ Deduplicate]
+ Dedupe --> Enrich[๐ Enrich]
+ Enrich --> Output[๐ Unified View]
+
+ style Platform fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+```
+
+```mermaid
+flowchart LR
+ Before[โ 5000 Alerts
From 5 Tools] --> Orchestration[๐ฏ Orchestration]
+ Orchestration --> After[โ
1200 Unique
76% Reduction]
+
+ After --> Benefits[โก Benefits]
+ Benefits --> B1[โฐ 80% Time Saved]
+ Benefits --> B2[๐ฏ Clear Priorities]
+ Benefits --> B3[๐ No Alert Fatigue]
+
+ style Before fill:#ffebee,stroke:#c62828,stroke-width:2px,color:#2c3e50
+ style After fill:#e8f5e8,stroke:#388e3c,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ Orchestration Workflow Steps
+
+**1๏ธโฃ Collection:**
+* ๐ฅ Gather results from all scanners
+* ๐ Normalize data (different formats โ standard format)
+* ๐ Standardize severity levels (tool-specific โ CVSS)
+
+**2๏ธโฃ Deduplication:**
+* ๐ฏ Same vulnerability found by multiple tools
+* ๐ Group by: File + line + vulnerability type
+* โ
Reduces noise (5 tools reporting same issue โ 1 unified report)
+* ๐ Result: 80% fewer alerts (focus on unique issues)
+
+**3๏ธโฃ Enrichment:**
+* ๐ Add CVSS scores, EPSS probability, KEV status
+* ๐ Link to remediation guidance (patches, code examples)
+* ๐ผ Calculate business impact (production vs dev)
+* ๐ฏ Add reachability analysis (if available)
+
+**4๏ธโฃ Prioritization:**
+* ๐ฏ Risk-based scoring (CVSS + EPSS + context)
+* ๐ข Context-aware (production > staging > dev)
+* ๐ Actionable queue for development teams
+* โฐ SLA assignment based on severity
+
+---
+
+### ๐ ๏ธ Orchestration Platform Options
+
+**๐ DefectDojo (Open-Source):**
+* โ
Free and open-source
+* ๐ Imports 100+ scanner formats
+* ๐ Built-in deduplication
+* ๐ Metrics and dashboards
+* ๐ฏ Workflow management (assign, track, verify)
+* ๐ฅ Best for: Medium to large teams
+
+**๐ผ ThreadFix (Commercial):**
+* ๐ฐ Enterprise platform
+* ๐ Advanced analytics and reporting
+* ๐ SIEM integration
+* ๐ข Multi-tenant support
+* ๐ต Cost: $$$
+
+**๐ฏ Dependency-Track (SBOM-focused):**
+* โ
Free and open-source
+* ๐ SBOM-based vulnerability management
+* ๐ Continuous monitoring
+* ๐ Policy engine
+* ๐ Covered in: Lab 8
+
+**๐ง Custom Solutions:**
+* โ
Parse tool outputs via API
+* ๐พ Store in database (PostgreSQL, MongoDB)
+* ๐ Build custom dashboards (Grafana)
+* ๐ Integration flexibility
+
+---
+
+### ๐ Integration Patterns
+
+**๐ Data Flow:**
+* ๐ Scanners โ API calls โ Orchestration platform
+* ๐ Platform โ Jira/GitHub Issues (ticketing)
+* ๐จ Platform โ SIEM (alerting)
+* ๐ Platform โ Dashboards (visualization)
+
+**๐ค Automation:**
+* โฐ Scheduled scans (nightly builds)
+* ๐ Real-time alerts (critical findings)
+* ๐ง Email notifications (team assignments)
+* ๐ Webhook triggers (Slack, PagerDuty)
+
+```mermaid
+flowchart LR
+ Scanners[๐ Scanners] -->|API| Platform[๐ Platform]
+ Platform --> Jira[๐ซ Jira]
+ Platform --> Slack[๐ฌ Slack]
+ Platform --> Dashboard[๐ Grafana]
+
+ style Platform fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+## ๐ Slide 3 โ ๐ Centralized Vulnerability Management
+
+* ๐ **Centralization** = single source of truth for all vulnerabilities
+* ๐ฏ **Benefits:** No duplicates, consistent tracking, clear ownership, audit trail
+* ๐ **Integrations:** CI/CD pipelines, issue trackers, security dashboards
+
+**๐ Common Approaches:**
+
+**๐ซ Jira/GitHub Issues:**
+* โ
Familiar to developers (existing workflow)
+* โ
Easy integration with dev process
+* โ ๏ธ Not security-optimized (no deduplication)
+* ๐ฏ Use case: Small teams, simple needs, existing Jira setup
+
+**๐ก๏ธ DefectDojo (Security-Focused):**
+* โ
Built for vulnerability management
+* โ
Deduplication and correlation built-in
+* โ
Security-specific metrics and reporting
+* ๐ฏ Use case: Medium to large teams, mature security programs
+
+**๐ฆ Dependency-Track (SBOM-Based):**
+* โ
SBOM-centric approach (from Lab 8)
+* โ
Continuous component monitoring
+* โ
Policy engine for governance
+* ๐ฏ Use case: Supply chain security focus
+
+**๐ฐ Commercial Platforms:**
+* ๐ท Snyk, Veracode, Checkmarx, Fortify
+* โ
All-in-one (scan + manage + report)
+* ๐ต Expensive but comprehensive
+* ๐ฏ Use case: Enterprise with budget
+
+```mermaid
+flowchart LR
+ Sources[๐ All Sources] --> Central[๐ Central Platform]
+ Central --> Dashboard[๐ Dashboard]
+ Central --> Tracking[๐ Tracking]
+ Central --> Reports[๐ Reports]
+
+ style Central fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ Vulnerability Tracking Fields
+
+**๐ Essential Fields:**
+* ๐ Unique ID (tracking identifier)
+* ๐ Source (which tool found it)
+* ๐ Location (file, line number, component)
+* ๐ฏ Severity (Critical/High/Medium/Low)
+* ๐ CVSS score (numerical rating)
+* ๐ Description (what's vulnerable)
+* ๐ค Owner (assigned developer/team)
+* ๐
Discovered date (when found)
+* โฐ Age (days open)
+* ๐ Status (Open/In Progress/Fixed/Closed)
+* ๐ง Remediation guidance (how to fix)
+
+**๐ Optional but Valuable:**
+* โก EPSS score (exploitation likelihood)
+* ๐จ KEV status (actively exploited?)
+* ๐ผ Business impact (critical service?)
+* ๐ Recurrence flag (fixed before?)
+* ๐งช Test status (verification completed?)
+* ๐ Risk score (contextual priority)
+
+```mermaid
+flowchart TD
+ Vuln[๐จ Vulnerability] --> Essential[๐ Essential
ID, Severity, Owner]
+ Vuln --> Optional[๐ Optional
EPSS, KEV, Risk]
+
+ Essential --> Track[๐ Track & Prioritize]
+ Optional --> Track
+
+ style Track fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+
+๐ญ Deduplication Magic: From chaos to clarity
+
+**โ Before deduplication:**
+* ๐ Snyk: SQL injection in auth.js:45
+* ๐ Semgrep: SQL injection in auth.js:45
+* ๐ SonarQube: SQL injection in auth.js:45
+* ๐ Checkmarx: SQL injection in auth.js:45
+* ๐ **Total: 4 separate tickets, 4 alerts, 4 meetings**
+
+**โ
After deduplication:**
+* ๐ฏ SQL injection in auth.js:45 (found by 4 tools, confidence: very high)
+* ๐ **Total: 1 ticket, 1 fix, 1 verification**
+
+**๐ Benefits:**
+* โฐ Save time (no duplicate work)
+* ๐ฏ Clear priorities (focus on unique issues)
+* ๐ Better metrics (accurate vulnerability counts)
+* ๐ฅ Less alert fatigue
+
+**๐ก Deduplication criteria:**
+* Same file + line + vulnerability type = duplicate
+* CWE matching (same weakness category)
+* Hash-based matching (exact code pattern)
+
+
+```mermaid
+flowchart LR
+ Before[โ 4 Tools
4 Tickets] --> Dedupe[๐ Deduplication]
+ Dedupe --> After[โ
1 Ticket
High Confidence]
+
+ Before --> Work1[๐ต 4ร Work]
+ After --> Work2[โ
1ร Work]
+
+ style Before fill:#ffebee,stroke:#c62828,stroke-width:2px,color:#2c3e50
+ style After fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+๐ **Resources for Group 1:**
+* [DefectDojo](https://www.defectdojo.org/)
+* [OWASP Testing Guide](https://owasp.org/www-project-web-security-testing-guide/)
+* [HackerOne](https://www.hackerone.com/)
+* [Bugcrowd](https://www.bugcrowd.com/)
+
+---
+
+## ๐ Fun Break: "The Scanner That Cried Wolf"
+
+* ๐ข Company: 7 scanners, 200 alerts/day, 85% false positives
+* ๐ด Critical bug (Log4Shell) buried in noise, missed for 3 days
+* ๐ฅ Exploited on day 4: $2M breach cost
+* โ
Fix: DefectDojo โ 200 alerts became 30 unique findings
+* ๐ก Lesson: More tools โ more security. Orchestration saves lives!
+
+---
+
+## ๐ Group 2: Vulnerability Assessment
+
+## ๐ Slide 4 โ ๐ CVSS Scoring Deep Dive
+
+* ๐ **CVSS (Common Vulnerability Scoring System)** = standardized severity rating 0.0-10.0
+* ๐ฏ **Purpose:** Consistent prioritization across organizations and tools
+* ๐ **Current versions:** v3.1 (widely used), v4.0 (new, more nuanced)
+* ๐ **Global standard:** Used by NVD, vendors, security teams worldwide
+* ๐ **Calculator:** [first.org/cvss/calculator](https://www.first.org/cvss/calculator/)
+
+```mermaid
+flowchart LR
+ Vuln[๐จ Vulnerability] --> Base[๐ Base Score
0-10]
+ Base --> Temporal[โฐ Temporal
Adjustments]
+ Temporal --> Environmental[๐ข Context]
+ Environmental --> Final[๐ฏ Final Score]
+
+ Final --> Action[โก Action Required]
+
+ style Final fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+```
+
+```mermaid
+flowchart LR
+ Base[๐ Base Score
Intrinsic properties] --> Final[๐ฏ Final CVSS
0.0 - 10.0]
+ Temporal[โฐ Temporal Score
Time-dependent] --> Final
+ Environmental[๐ข Environmental
Organization-specific] --> Final
+
+ style Final fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ CVSS v3.1 Base Metrics
+
+**๐ Exploitability Metrics:**
+* **๐ Attack Vector (AV):** Network (N) / Adjacent (A) / Local (L) / Physical (P)
+* **๐งฉ Attack Complexity (AC):** Low (L) / High (H)
+* **๐ Privileges Required (PR):** None (N) / Low (L) / High (H)
+* **๐ค User Interaction (UI):** None (N) / Required (R)
+
+**๐ฅ Impact Metrics:**
+* **๐ Confidentiality (C):** None (N) / Low (L) / High (H)
+* **โ
Integrity (I):** None (N) / Low (L) / High (H)
+* **โก Availability (A):** None (N) / Low (L) / High (H)
+* **๐ฏ Scope (S):** Unchanged (U) / Changed (C)
+
+**๐ก Example: SQL Injection**
+* ๐ AV:Network (remotely exploitable)
+* ๐งฉ AC:Low (easy to exploit)
+* ๐ PR:None (no authentication needed)
+* ๐ค UI:None (no user interaction)
+* ๐ฏ S:Changed (can access other systems)
+* ๐ C:High, โ
I:High, โก A:High
+* **๐ Score: 10.0 (Critical)**
+
+---
+
+### ๐ Severity Ranges & Actions
+
+| Score | Severity | Color | Action | SLA |
+|-------|----------|-------|--------|-----|
+| 9.0-10.0 | ๐ด **Critical** | Red | Fix immediately | โฐ 24 hours |
+| 7.0-8.9 | ๐ **High** | Orange | Fix urgently | โฐ 7 days |
+| 4.0-6.9 | ๐ก **Medium** | Yellow | Fix soon | โฐ 30 days |
+| 0.1-3.9 | ๐ข **Low** | Green | Fix eventually | โฐ 90 days |
+| 0.0 | โช **None** | White | Informational | ๐ No fix needed |
+
+```mermaid
+flowchart LR
+ CVSS[๐ CVSS] --> Critical[๐ด 9-10
24h SLA]
+ CVSS --> High[๐ 7-8.9
7d SLA]
+ CVSS --> Medium[๐ก 4-6.9
30d SLA]
+ CVSS --> Low[๐ข 0.1-3.9
90d SLA]
+
+ style Critical fill:#ffebee,stroke:#c62828,stroke-width:2px,color:#2c3e50
+ style High fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### โฐ Temporal Score (Optional)
+
+**๐ง Modifying Factors:**
+* **๐ฃ Exploit Code Maturity:** Unproven / Proof-of-Concept / Functional / High
+* **๐ง Remediation Level:** Official Fix / Temporary Fix / Workaround / Unavailable
+* **๐ Report Confidence:** Unknown / Reasonable / Confirmed
+
+**๐ Impact:** Can lower base score
+* ๐ Example: CVSS 9.0 base โ 7.5 final (no exploit available yet, patch ready)
+* โฐ Changes over time (exploit released = score increases)
+
+---
+
+### ๐ข Environmental Score (Optional)
+
+**๐ฏ Organization-Specific Adjustments:**
+* **๐ Confidentiality Requirement:** How sensitive is your data?
+* **โ
Integrity Requirement:** How critical is data accuracy?
+* **โก Availability Requirement:** How critical is uptime?
+
+**๐ผ Example Scenarios:**
+* ๐ **E-commerce site:** Availability = High (downtime = lost revenue)
+* ๐ **Blog site:** Availability = Low (downtime = minimal impact)
+* ๐ฅ **Healthcare:** Confidentiality = High (HIPAA data)
+* ๐ฐ **Finance:** Integrity = High (transaction accuracy critical)
+
+**๐ Result:** Same vulnerability = different scores per organization
+
+
+๐ญ CVSS Limitations: What it doesn't tell you
+
+**โ CVSS doesn't consider:**
+* ๐ฏ **Exploitability in the wild** (use EPSS for this)
+* ๐ผ **Business impact** (use environmental score)
+* ๐ง **Ease of remediation** (patch available vs. major refactor)
+* ๐ **Reachability** (is vulnerable code actually executed?)
+* ๐ข **Your specific environment** (production vs. dev)
+* โฐ **Attack trends** (is it being exploited now?)
+
+**โ
CVSS is ONE input, not the ONLY factor:**
+* ๐ Combine: CVSS + EPSS + KEV + Context = Smart prioritization
+* ๐ฏ Use as baseline, adjust with intelligence
+* ๐ง Apply judgment, don't follow blindly
+
+**๐ก Pro tip:** CVSS 9.0 with 0% exploitation = lower priority than CVSS 7.0 with active exploits
+
+
+```mermaid
+flowchart TD
+ CVSS[๐ CVSS 9.0] --> Question{โ But is it exploited?}
+ Question -->|No EPSS 0%| Lower[๐ Lower Priority]
+ Question -->|Yes EPSS 80%| Higher[๐ Highest Priority]
+
+ style Higher fill:#ffebee,stroke:#c62828,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+## ๐ Slide 5 โ โก Advanced Prioritization: EPSS, KEV, SSVC
+
+* ๐ฏ **Problem:** CVSS measures severity, NOT likelihood of exploitation
+* ๐ **Solution:** Combine multiple signals for intelligent prioritization
+* ๐ง **Smart approach:** Likelihood ร Impact ร Context = Priority
+
+```mermaid
+flowchart LR
+ CVSS[๐ CVSS
Severity] --> Priority[๐ฏ Smart Priority]
+ EPSS[โก EPSS
Likelihood] --> Priority
+ KEV[๐จ KEV
Exploited] --> Priority
+ Context[๐ข Context
Prod/Dev] --> Priority
+
+ Priority --> P0[๐ด P0: Today]
+ Priority --> P1[๐ P1: Week]
+ Priority --> P2[๐ก P2: Month]
+
+ style Priority fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+```
+
+```mermaid
+flowchart LR
+ CVSS[๐ CVSS
Severity] --> Decision{๐ฏ Priority?}
+ EPSS[โก EPSS
Likelihood] --> Decision
+ KEV[๐จ KEV
Exploited?] --> Decision
+ Context[๐ข Context
Your env] --> Decision
+
+ Decision --> High[๐ด P0: Fix Today]
+ Decision --> Medium[๐ก P1: Fix Week]
+ Decision --> Low[๐ข P2: Backlog]
+
+ style Decision fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### โก EPSS (Exploit Prediction Scoring System)
+
+* ๐ฏ **EPSS:** Probability of exploitation in next 30 days
+* ๐ **Score range:** 0-100% (e.g., 45% = 45% chance of active exploitation)
+* ๐ค **ML-powered:** Trained on real-world exploitation data from honeypots, IDS, threat intel
+* ๐
**Updated:** Daily with new data
+* ๐ **Database:** [first.org/epss](https://www.first.org/epss/)
+
+```mermaid
+flowchart LR
+ EPSS[โก EPSS Score] --> High[> 70%
Fix NOW]
+ EPSS --> Med[30-70%
Watch Close]
+ EPSS --> Low[< 10%
Normal Priority]
+
+ style High fill:#ffebee,stroke:#c62828,stroke-width:3px,color:#2c3e50
+```
+
+**๐ก Example Prioritization:**
+* ๐ด **CVE-2021-44228 (Log4Shell):** CVSS 10.0 + EPSS 97% โ **DROP EVERYTHING, FIX NOW**
+* ๐ก **CVE-2023-12345:** CVSS 9.8 + EPSS 0.3% โ High severity but low exploitation โ lower priority
+
+**๐ฏ How to Use EPSS:**
+* ๐จ EPSS > 70% โ Treat as urgent (high exploitation risk)
+* โ ๏ธ EPSS > 30% โ Monitor closely (emerging threat)
+* โ
EPSS < 10% โ Can deprioritize (low exploitation risk)
+
+---
+
+### ๐จ CISA KEV (Known Exploited Vulnerabilities)
+
+* ๐๏ธ **CISA KEV:** Catalog of vulnerabilities actively exploited in the wild RIGHT NOW
+* ๐ฅ **If in KEV:** Being exploited by attackers at this moment
+* โฐ **US Gov mandate:** Patch KEV vulnerabilities within 15 days (federal agencies)
+* ๐ **Catalog size:** 1,000+ actively exploited vulnerabilities
+* ๐ **Catalog:** [cisa.gov/known-exploited-vulnerabilities](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
+
+**๐ฏ KEV = Always Highest Priority:**
+* ๐ด Even Low CVSS + in KEV = Fix immediately
+* โก Real-world exploitation confirmed
+* ๐จ Attackers have tools and knowledge
+
+```mermaid
+flowchart LR
+ Vuln[๐จ Vulnerability] --> Check{In KEV?}
+ Check -->|Yes| Emergency[๐ด EMERGENCY
Fix in 15 days]
+ Check -->|No| Normal[๐ Normal Process]
+
+ style Emergency fill:#ffebee,stroke:#c62828,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ฏ SSVC (Stakeholder-Specific Vulnerability Categorization)
+
+* ๐ฏ **SSVC:** Decision tree for vulnerability prioritization
+* ๐ **Factors:** Exploitation status, Technical impact, Automatable, Mission impact
+* ๐ **Output:** Act immediately / Act / Track / Track*
+* ๐ง **Benefit:** More nuanced than simple CVSS scoring
+
+**๐ณ Decision Tree Questions:**
+1. โ Is it being exploited? (KEV check)
+2. โ Is it automatable? (wormable, self-spreading?)
+3. โ What's technical impact? (Total/Partial/Minor)
+4. โ What's mission impact? (Mission Essential/Support/Not Critical)
+
+**๐ Result:** Context-aware prioritization decision
+
+---
+
+### ๐ Combined Prioritization Matrix
+
+| CVSS | EPSS | KEV | Final Priority | Action | Timeline |
+|------|------|-----|----------------|--------|----------|
+| 9-10 | >70% | โ
Yes | ๐ด **P0** | Fix immediately | โฐ 24 hours |
+| 9-10 | >70% | โ No | ๐ **P1** | Fix urgently | โฐ 48 hours |
+| 9-10 | <30% | โ No | ๐ก **P2** | Fix this week | โฐ 7 days |
+| 7-8.9 | >70% | โ
Yes | ๐ **P1** | Fix urgently | โฐ 48 hours |
+| 7-8.9 | <30% | โ No | ๐ก **P2** | Fix this month | โฐ 30 days |
+| 4-6.9 | <10% | โ No | ๐ข **P3** | Backlog | โฐ 90 days |
+
+**๐ก Key Insight:** High CVSS + Low EPSS + Not in KEV = Lower priority than you think!
+
+```mermaid
+flowchart LR
+ V1[CVSS 9.8
EPSS 2%
No KEV] --> P2[๐ก P2: Month]
+ V2[CVSS 7.0
EPSS 80%
In KEV] --> P0[๐ด P0: Today]
+
+ style P0 fill:#ffebee,stroke:#c62828,stroke-width:3px,color:#2c3e50
+ style P2 fill:#fffde7,stroke:#f9a825,stroke-width:2px,color:#2c3e50
+```
+
+
+๐ญ Real Scenario: 100 Vulnerabilities, What to Fix First?
+
+**โ Old Approach (CVSS only):**
+* ๐ด Fix all 30 Critical (CVSS 9-10) first
+* โฐ Timeline: 6 months to clear all Critical
+* ๐จ Meanwhile, actively exploited High severity vulns remain
+
+**โ
Smart Approach (Combined signals):**
+* ๐ฅ **3 in KEV catalog** โ Fix TODAY (P0)
+* โก **7 with EPSS > 50%** โ Fix THIS WEEK (P1)
+* ๐ฏ **20 with CVSS 9+ but EPSS < 5%** โ Fix NEXT MONTH (P2)
+
+**๐ Result:**
+* โ
Fixed the 10 that matter most in 1 week
+* ๐ฏ 80% risk reduction with 10% effort
+* โฐ Not 6 months, just 1 week for critical threats
+
+**๐ก Lesson:** Work smarter, not harder. Prioritize by actual threat, not just severity.
+
+
+```mermaid
+flowchart LR
+ Scenario[100 Vulns] --> Old[โ Old: Fix all 30 Critical
6 months]
+ Scenario --> Smart[โ
Smart: Fix 10 KEV+High EPSS
1 week]
+
+ Smart --> Result[๐ฏ 80% Risk Reduction
10% Effort]
+
+ style Smart fill:#e8f5e8,stroke:#388e3c,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+## ๐ Slide 6 โ ๐ฏ Risk-Based Prioritization
+
+* ๐ฏ **Risk = Likelihood ร Impact ร Exposure**
+* ๐ข **Context matters:** Same vulnerability = different risk in different environments
+* ๐ **Your environment:** Production vs. dev, internet-facing vs. internal, customer data vs. test data
+
+```mermaid
+flowchart LR
+ Likelihood[๐ Likelihood
EPSS+KEV] --> Risk[๐ฏ Risk Score]
+ Impact[๐ฅ Impact
CVSS] --> Risk
+ Context[๐ข Context
Environment] --> Risk
+
+ Risk --> Final[โก Final Priority]
+
+ style Risk fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+```
+
+```mermaid
+flowchart LR
+ Likelihood[๐ Likelihood
EPSS, KEV] --> Risk[๐ฏ Risk Score]
+ Impact[๐ฅ Impact
CVSS, Business] --> Risk
+ Context[๐ข Context
Exposure, Criticality] --> Risk
+
+ Risk --> Priority[โก Priority Queue]
+
+ style Risk fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ข Contextual Risk Factors
+
+**๐ฏ Asset Criticality:**
+* ๐ด Production, customer-facing โ **Highest priority**
+* ๐ก Staging, internal tools โ **Medium priority**
+* ๐ข Development, testing โ **Lower priority**
+* โช Sandbox, demo โ **Lowest priority**
+
+**๐ Exposure Level:**
+* ๐ Internet-facing public API โ **Highest priority**
+* ๐ข Internal service, VPN-only โ **Medium priority**
+* ๐ Private network, authenticated โ **Lower priority**
+* ๐๏ธ Air-gapped system โ **Lowest priority**
+
+**๐ผ Data Sensitivity:**
+* ๐ณ Payment data (PCI-DSS), PII (GDPR) โ **Highest priority**
+* ๐ Confidential business data โ **Medium priority**
+* ๐ Non-sensitive business data โ **Lower priority**
+* ๐ Public data โ **Lowest priority**
+
+**๐ก๏ธ Compensating Controls:**
+* โ
WAF in front (Web Application Firewall) โ **Reduce priority**
+* โ
Network segmentation (isolated) โ **Reduce priority**
+* โ
Strong authentication (MFA) โ **Reduce priority**
+* โ No controls โ **Increase priority**
+
+---
+
+### ๐ Reachability Analysis
+
+* ๐ฏ **Critical question:** Is vulnerable code actually executed in your application?
+* ๐ **Reality:** ~70% of vulnerabilities may be unreachable (code exists but never runs)
+* ๐ง **Tools:** Snyk (reachability feature), GitHub CodeQL (dataflow analysis)
+
+**๐ก Example:**
+* ๐ฆ Vulnerability in lodash.template() function
+* ๐ Your code imports lodash but never calls .template()
+* โ
Vulnerability exists but **NOT exploitable**
+* ๐ฏ Action: Lower priority (but don't ignore forever - transitive risk)
+
+```mermaid
+flowchart LR
+ Vuln[๐จ lodash vuln] --> Reach{๐ Reachable?}
+ Reach -->|Yes| High[๐ด High Priority]
+ Reach -->|No| Lower[๐ก Lower Priority]
+
+ style High fill:#ffebee,stroke:#c62828,stroke-width:2px,color:#2c3e50
+ style Lower fill:#fffde7,stroke:#f9a825,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Custom Risk Scoring
+
+**๐งฎ Example Formula:**
+
+**Risk Score = (CVSS ร 0.3) + (EPSS ร 100 ร 0.3) + (Criticality ร 0.2) + (Exposure ร 0.2)**
+
+**Where:**
+* ๐ CVSS: 0-10 (severity)
+* โก EPSS: 0-1, multiplied by 100 (likelihood)
+* ๐ข Criticality: 0-10 (0=dev, 5=staging, 10=prod)
+* ๐ Exposure: 0-10 (0=internal, 5=VPN, 10=internet)
+
+**๐ก Example Calculation:**
+* ๐ด SQL injection in production API
+* ๐ CVSS: 9.8
+* โก EPSS: 0.45 (45%)
+* ๐ข Criticality: 10 (production)
+* ๐ Exposure: 10 (internet-facing)
+* **๐ฏ Risk Score:** (9.8ร0.3) + (45ร0.3) + (10ร0.2) + (10ร0.2) = **20.4/30 (HIGH)**
+
+**๐จ Action:** Fix immediately (P0 priority)
+
+```mermaid
+flowchart LR
+ Inputs[๐ Inputs] --> Formula[๐งฎ Risk Formula]
+ Formula --> Score[๐ฏ Risk Score 0-30]
+ Score --> Priority[โก Priority Level]
+
+ style Formula fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+```
+
+
+๐ญ Tune Your Formula: One size doesn't fit all
+
+**๐ E-commerce Company:**
+* โฌ๏ธ Higher weight: Availability impact (downtime = lost sales)
+* โฌ๏ธ Higher weight: Exposure (public-facing)
+* โฌ๏ธ Lower weight: Internal tools
+
+**๐ฅ Healthcare Organization:**
+* โฌ๏ธ Higher weight: Data sensitivity (HIPAA compliance)
+* โฌ๏ธ Higher weight: Integrity impact (data accuracy)
+* โฌ๏ธ Higher weight: Confidentiality
+
+**๐ข Internal Tools Company:**
+* โฌ๏ธ Lower weight: Exposure (mostly internal)
+* โฌ๏ธ Higher weight: Criticality (mission-critical vs. nice-to-have)
+
+**๐ฏ Strategy:**
+1. โ
Start with default weights (balanced approach)
+2. ๐ Track outcomes (are you fixing the right things?)
+3. ๐ Adjust weights based on your incidents
+4. ๐ Iterate quarterly (refine based on data)
+
+**๐ก Remember:** Your risk tolerance โ other companies' risk tolerance
+
+
+---
+
+## ๐ Slide 7 โ ๐จ Triage Workflows & Decisions
+
+* ๐จ **Triage** = rapid assessment and categorization of vulnerabilities
+* ๐ฏ **Possible outcomes:** Accept, Fix, Mitigate, Defer, False Positive
+* โฐ **Speed matters:** Don't let vulnerabilities age in triage queue
+* ๐ **Goal:** Every vulnerability triaged within 24-48 hours
+
+```mermaid
+flowchart LR
+ Vuln[๐ Discovered] --> Triage{๐จ Decision}
+
+ Triage --> Fix[๐ง Fix]
+ Triage --> Mitigate[๐ก๏ธ Mitigate]
+ Triage --> Accept[โ
Accept]
+ Triage --> Defer[โฐ Defer]
+ Triage --> FP[โ False Positive]
+
+ style Triage fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+```
+
+```mermaid
+flowchart LR
+ Vuln[๐ Vulnerability
Discovered] --> Triage{๐จ Triage
Decision}
+
+ Triage --> Accept[โ
Accept Risk
Document & Monitor]
+ Triage --> Fix[๐ง Fix
Patch/Code Change]
+ Triage --> Mitigate[๐ก๏ธ Mitigate
Workaround/Controls]
+ Triage --> Defer[โฐ Defer
Add to Backlog]
+ Triage --> FP[โ False Positive
Mark & Close]
+
+ style Triage fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### โ
Triage Decision Matrix
+
+| Condition | Decision | Action | Timeline |
+|-----------|----------|--------|----------|
+| ๐จ In KEV catalog | **๐ง Fix** | Immediate remediation | โฐ 24h |
+| ๐ด Critical + Production | **๐ง Fix** | Urgent patch | โฐ 24-48h |
+| ๐ High + No patch available | **๐ก๏ธ Mitigate** | WAF rule, network block | โฐ 48h |
+| ๐ข Low + Legacy system EOL | **โ
Accept** | Document risk, monitor | ๐ Review quarterly |
+| ๐ค Scanner false detection | **โ False Positive** | Mark, tune scanner | โฐ Same day |
+| ๐ก Medium + Low EPSS | **โฐ Defer** | Add to backlog | ๐ Next sprint |
+
+---
+
+### ๐ง Fix Decision (Permanent Remediation)
+
+**โ
When to Fix:**
+* ๐ด High risk (CVSS + EPSS + KEV + context)
+* ๐ญ Production environment affected
+* ๐ Patch available from vendor
+* ๐ซ No acceptable workaround
+* ๐ Business impact significant
+
+**๐ ๏ธ Fix Strategies:**
+* ๐ฆ Update dependency (SCA findings)
+* ๐ Apply security patch (OS/library updates)
+* ๐ป Code change (SAST findings - rewrite vulnerable code)
+* โ๏ธ Configuration change (IaC findings)
+
+---
+
+### ๐ก๏ธ Mitigate Decision (Temporary Control)
+
+**โ ๏ธ When to Mitigate:**
+* โ No patch available yet (zero-day situation)
+* ๐งช Patch breaks functionality (needs testing)
+* โฐ Fix requires major refactor (time-consuming)
+* ๐ Waiting for vendor patch release
+
+**๐ง Mitigation Strategies:**
+* ๐ฅ **WAF rule:** Block exploit pattern (ModSecurity, AWS WAF)
+* ๐ **Network segmentation:** Limit access (VPN, IP whitelisting)
+* ๐ **Authentication layer:** Add additional auth requirement
+* โฑ๏ธ **Rate limiting:** Slow down potential attacks
+* ๐ **Enhanced monitoring:** Detect exploitation attempts
+* ๐ซ **Feature flag:** Temporarily disable vulnerable feature
+
+**โ ๏ธ Remember:** Mitigations are temporary - must still fix root cause
+
+---
+
+### โ
Accept Risk Decision (Documented Exception)
+
+**๐ When to Accept:**
+* ๐ข Low risk (Low CVSS + Low EPSS + Not in KEV)
+* ๐ซ Not reachable (dead code, never executed)
+* ๐ก๏ธ Strong compensating controls (already well-protected)
+* ๐ฐ Cost > Benefit (legacy system retiring in 30 days)
+* ๐๏ธ Architectural limitation (would require full rewrite)
+
+**๐ Requirements for Risk Acceptance:**
+* ๐ Document decision (why accepting, what's the risk)
+* ๐ Get approval (manager, security team, or risk committee)
+* ๐
Set review date (re-evaluate quarterly or when context changes)
+* ๐ Monitor continuously (ensure assumption remains valid)
+* โ๏ธ Legal sign-off (if compliance-related)
+
+---
+
+### โ False Positive Handling
+
+**๐ Common False Positives:**
+* ๐งช Test code flagged as vulnerable (not in production)
+* ๐ Dead code never executed (commented out, unreachable)
+* โ๏ธ Scanner misconfiguration (wrong context)
+* ๐ Duplicate of already-fixed issue (tool lag)
+* ๐ฏ Context misunderstanding (looks vulnerable but isn't)
+
+**โ
Process:**
+1. ๐ Validate (is it really a false positive? Double-check)
+2. ๐ท๏ธ Mark in tool (prevent re-reporting in future scans)
+3. โ๏ธ Tune scanner (adjust rules, add exceptions)
+4. ๐ Track FP rate (metric: should be < 20%)
+5. ๐ Review periodically (false positives can become real)
+
+
+๐ญ Triage SLA: Speed kills (vulnerabilities, that is!)
+
+**โฐ Recommended Triage Speed:**
+* ๐ด **Critical:** Triage within 4 hours (same business day)
+* ๐ **High:** Triage within 24 hours (next business day)
+* ๐ก **Medium:** Triage within 3 days
+* ๐ข **Low:** Triage within 1 week
+
+**๐ Why Speed Matters:**
+* โฐ Old vulnerabilities = forgotten vulnerabilities
+* ๐ Triage backlog = accumulating risk
+* ๐ฏ Fast triage = faster fixes
+* ๐ Metric: Average triage time (track and improve)
+
+**๐ฏ Goal:** Zero vulnerabilities untriaged > 1 week
+
+**๐ก Pro Tip:**
+* ๐ค Automate triage where possible (auto-FP, auto-defer low EPSS)
+* ๐ฅ Dedicated triage rotation (security champion duty)
+* ๐ Daily standup includes triage queue review
+
+
+---
+
+๐ **Resources for Group 2:**
+* [CVSS Calculator](https://www.first.org/cvss/calculator/)
+* [EPSS Scores](https://www.first.org/epss/)
+* [CISA KEV Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
+* [SSVC Framework](https://www.cisa.gov/ssvc)
+
+---
+
+## ๐ญ Interactive: "Triage Challenge"
+
+**๐ฏ Scenario: You have 10 vulnerabilities. Prioritize them!**
+
+1. ๐ SQL injection in admin portal (CVSS 9.8, EPSS 2%, internal-only, VPN)
+2. ๐ XSS in public blog (CVSS 6.5, EPSS 15%, internet-facing)
+3. ๐ Outdated OpenSSL (CVSS 9.0, EPSS 80%, in KEV, dev environment only)
+4. ๐ Hardcoded API key in test code (CVSS 7.5, never deployed to prod)
+5. ๐ฅ RCE in production API (CVSS 10.0, EPSS 85%, in KEV, production)
+6. ๐ Info disclosure staging (CVSS 5.3, EPSS 1%, staging environment)
+7. ๐ Weak password policy (CVSS 4.0, EPSS 5%, all environments)
+8. ๐ SSRF in internal tool (CVSS 8.8, EPSS 25%, VPN-only access)
+9. ๐ณ Deserialization in payment service (CVSS 9.8, EPSS 60%, production)
+10. ๐ฑ Unpatched library mobile app (CVSS 7.0, EPSS 10%, app store)
+
+
+๐ Click to reveal expert prioritization
+
+**๐ฏ Priority Ranking:**
+
+**๐ด P0 (Fix Today - Drop Everything):**
+1. **#5:** ๐ฅ RCE + production + KEV + EPSS 85% = **CRITICAL EMERGENCY**
+2. **#9:** ๐ณ Deserialization + production payment + EPSS 60% = **CRITICAL**
+
+**๐ P1 (Fix This Week - High Urgency):**
+3. **#3:** ๐ KEV status trumps dev environment (shows active exploitation)
+4. **#2:** ๐ Public-facing + medium EPSS (real exposure)
+
+**๐ก P2 (Fix This Month - Medium Priority):**
+5. **#8:** ๐ High CVSS but VPN-only (limited exposure)
+6. **#10:** ๐ฑ Mobile requires app update cycle (delayed deployment)
+7. **#1:** ๐ High CVSS but internal-only + low EPSS
+
+**๐ข P3 (Backlog - Low Priority):**
+8. **#7:** ๐ Process issue, long-term fix
+9. **#6:** ๐ Staging only, low risk
+
+**โ False Positive / No Action:**
+10. **#4:** ๐ Test code never deployed (mark as FP, remove from prod builds)
+
+**๐ก Key Insights:**
+* ๐ฏ #5 and #9 are true emergencies (production + high exploitation)
+* ๐จ #3 is in KEV despite being dev (active exploitation elsewhere)
+* ๐ #1 has highest CVSS but lowest actual risk (internal + low EPSS)
+* โฐ Can address top 4 (real threats) within 1 week
+* ๐ฐ Ignore CVSS-only prioritization (would put #1 before #2, wrong!)
+
+**๐ Result:** Fixed highest risks in days, not months!
+
+
+---
+
+๐ **Resources for Group 2:**
+* [CVSS Calculator](https://www.first.org/cvss/calculator/)
+* [EPSS Scores](https://www.first.org/epss/)
+* [CISA KEV Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
+* [SSVC Framework](https://www.cisa.gov/ssvc)
+
+---
+
+## ๐ญ Interactive: "Triage Challenge" (See details in slide)
+
+---
+
+## ๐ Group 3: Remediation Workflows
+
+## ๐ Slide 8 โ ๐ง Remediation Strategies
+
+* ๐ง **Remediation** = permanently fixing vulnerabilities
+* ๐ฏ **Strategies vary:** Patch, upgrade, code rewrite, configuration change
+* โฐ **Speed = Risk Reduction:** Faster fixes = lower exposure window
+* โ
**Verification required:** "Fixed" must be validated
+
+```mermaid
+flowchart LR
+ Vuln[๐จ Vulnerability] --> Strategy{๐ง Strategy?}
+
+ Strategy --> Patch[๐ Patch
Update Library]
+ Strategy --> Code[๐ป Code Fix
Rewrite Logic]
+ Strategy --> Config[โ๏ธ Config Change
Settings]
+ Strategy --> Workaround[๐ก๏ธ Workaround
Temporary]
+
+ Patch --> Test[๐งช Test & Verify]
+ Code --> Test
+ Config --> Test
+
+ Test --> Deploy[๐ Deploy Fix]
+
+ style Strategy fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+```
+
+```mermaid
+flowchart TD
+ Type[๐จ Vuln Type] --> Patch[๐ Patch
Dependencies]
+ Type --> Code[๐ป Code Fix
SAST]
+ Type --> Config[โ๏ธ Config
IaC]
+ Type --> Temp[๐ก๏ธ Workaround
Temporary]
+
+ Patch --> Test[๐งช Test]
+ Code --> Test
+ Config --> Test
+ Test --> Deploy[๐ Deploy]
+
+ style Test fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Patching Strategy (Dependencies)
+
+**โ
When:** Vulnerability in third-party library or package
+
+**๐ Process:**
+1. ๐ Check patch availability (is update available?)
+2. ๐ Review changelog (breaking changes? migration needed?)
+3. ๐ Update version in manifest (package.json, pom.xml, requirements.txt)
+4. ๐ Update lockfile (package-lock.json, Pipfile.lock)
+5. ๐งช Test thoroughly (automated tests + manual testing)
+6. ๐ Deploy (gradual rollout recommended)
+
+**๐ค Automation Options:**
+* ๐ Dependabot creates auto-PRs
+* โ
CI/CD runs automated test suite
+* ๐ Auto-merge for patch updates (if tests pass)
+* ๐ Rollback on failure detection
+
+---
+
+### ๐ป Code Change Strategy (Application Vulnerabilities)
+
+**โ
When:** Vulnerability in your own code (SAST findings)
+
+**๐ Process:**
+1. ๐ง Understand vulnerability (root cause analysis, not just symptom)
+2. ๐ง Write secure fix (follow secure coding guidelines)
+3. ๐งช Write regression test (prevent reoccurrence)
+4. ๐ Security-focused code review (peer review with security lens)
+5. ๐ Deploy through normal release cycle
+
+**๐ก Example Types:**
+* ๐ SQL injection โ Use parameterized queries
+* ๐ XSS โ Proper output encoding
+* ๐ Weak crypto โ Use strong algorithms
+* ๐ Auth bypass โ Fix authorization logic
+
+---
+
+### โ๏ธ Configuration Change Strategy
+
+**โ
When:** Misconfiguration vulnerability (IaC findings)
+
+**๐ Process:**
+1. ๐ Update IaC code (Terraform, CloudFormation, Ansible)
+2. ๐ Run IaC security scan (verify fix)
+3. ๐งช Test in staging environment
+4. ๐ Apply changes (terraform apply, cloudformation update)
+5. โ
Verify actual state (check cloud console)
+
+**๐ก Example Fixes:**
+* ๐ชฃ Public S3 bucket โ Set ACL to private, enable block public access
+* ๐ Open security group โ Restrict to specific IPs/ports
+* ๐ Unencrypted database โ Enable encryption at rest
+
+---
+
+### ๐ก๏ธ Workaround Strategy (Temporary Mitigation)
+
+**โ ๏ธ When:** Cannot fix immediately (zero-day, testing needed, major refactor)
+
+**๐ง Temporary Options:**
+* ๐ฅ **WAF rule:** Block specific attack patterns
+* ๐ **Network isolation:** Restrict network access
+* ๐ **Additional authentication:** Add extra auth layer
+* โฑ๏ธ **Rate limiting:** Slow down potential attacks
+* ๐ซ **Feature flag:** Disable vulnerable functionality
+* ๐ **Enhanced logging:** Detect exploitation attempts
+
+**โ ๏ธ Critical:** Workarounds are NOT solutions - must still fix permanently
+
+---
+
+### โ When NOT to Fix
+
+**๐ Valid Reasons:**
+* โ
False positive (not actually vulnerable)
+* โ
Risk accepted (documented, approved decision)
+* โ
Not reachable (dead code, never executed)
+* โ
System retiring (EOL < 30 days)
+* โ
Compensating controls sufficient
+
+**๐ Important:** Document decision, get approval, set review date
+
+
+๐ญ Remediation Reality Check: How fast can you really fix?
+
+**โฐ Ideal vs. Reality:**
+
+| Severity | ๐ฏ Ideal SLA | ๐ Reality | ๐ซ Bottleneck |
+|----------|-------------|-----------|---------------|
+| ๐ด Critical | 24 hours | 3-5 days | Testing, approvals, deployment windows |
+| ๐ High | 7 days | 2-3 weeks | Prioritization, resource availability |
+| ๐ก Medium | 30 days | 1-3 months | Backlog, competing priorities |
+| ๐ข Low | 90 days | 6+ months | Never gets prioritized |
+
+**๐ How to Speed Up:**
+* ๐ค Automate testing (comprehensive test suite)
+* ๐ Pre-approve patches (security exception process)
+* ๐ Continuous deployment (deploy multiple times daily)
+* ๐ฅ Empower teams (reduce approval bottlenecks)
+* ๐ฏ Clear SLAs (accountability and urgency)
+
+** ๐ฏ Goal:** Critical vulnerabilities fixed in < 48 hours consistently
+
+
+```mermaid
+flowchart LR
+ Ideal[๐ฏ Ideal SLA
24h Critical] --> Reality[๐ Reality
3-5 days]
+ Reality --> Improve[๐ Speed Up]
+ Improve --> Auto[๐ค Automate]
+ Improve --> Pre[๐ Pre-approve]
+ Improve --> CD[๐ Continuous Deploy]
+
+ style Improve fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+## ๐ Slide 9 โ โฑ๏ธ SLA Management & Tracking
+
+* โฑ๏ธ **SLA (Service Level Agreement)** = maximum time to fix vulnerability
+* ๐ฏ **Based on severity:** Critical faster than Low
+* ๐ **Track compliance:** Percentage fixed within SLA targets
+* ๐จ **Escalate violations:** Don't let things slip through cracks
+
+**๐ Standard SLA Table:**
+
+| Severity | ๐ฏ SLA Target | โฐ Clock Starts | ๐จ Escalation Point |
+|----------|---------------|-----------------|---------------------|
+| ๐ด Critical | 24 hours | โ
After triage | ๐จ 12h โ Manager |
+| ๐ High | 7 days | โ
After triage | ๐จ 5d โ Manager |
+| ๐ก Medium | 30 days | โ
After triage | ๐จ 25d โ Track closely |
+| ๐ข Low | 90 days | โ
After triage | ๐จ 80d โ Review validity |
+
+```mermaid
+flowchart LR
+ Triage[โ
Triaged] --> Clock[โฐ SLA Starts]
+ Clock --> Critical[๐ด 24h]
+ Clock --> High[๐ 7d]
+ Clock --> Medium[๐ก 30d]
+ Clock --> Low[๐ข 90d]
+
+ Critical --> Escalate[๐จ 12h โ Manager]
+
+ style Clock fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Critical fill:#ffebee,stroke:#c62828,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### โฐ SLA Clock Management
+
+**โ
When SLA Starts:**
+* โ
After vulnerability triaged and assigned
+* โ
Not when scanner finds it (unknown at that point)
+* โ
Not when it first existed (impossible to know)
+
+**โธ๏ธ SLA Pause Scenarios:**
+* โธ๏ธ Waiting for vendor patch (documented)
+* โธ๏ธ Blocked by external dependency
+* โธ๏ธ Requires business decision (escalated)
+
+**โ Not Valid Pauses:**
+* โ "We're busy with features" (security is priority)
+* โ "Waiting for next sprint" (security doesn't wait)
+* โ "Not enough resources" (escalate for resources)
+
+---
+
+### ๐ SLA Metrics to Track
+
+**๐ฏ Key Metrics:**
+* ๐ **SLA compliance rate:** % vulnerabilities fixed within SLA
+* โฐ **Average fix time:** Mean time by severity
+* ๐จ **SLA violations:** Count of breaches
+* ๐
**Aging violations:** Vulnerabilities past SLA deadline
+* ๐ **Trend analysis:** Improving or degrading over time
+
+**๐ผ Dashboard Example:**
+* ๐ด Critical: 95% within SLA (Target: 100%) - โ ๏ธ Needs improvement
+* ๐ High: 88% within SLA (Target: 90%) - ๐ Close to target
+* ๐ก Medium: 72% within SLA (Target: 80%) - ๐จ Action needed
+* ๐ข Low: 65% within SLA (Target: 70%) - ๐ Backlog issue
+
+---
+
+### ๐จ SLA Escalation Path
+
+**๐ Escalation Workflow:**
+* ๐
**Day 0:** Developer assigned, notification sent
+* โฐ **50% SLA:** Automated reminder (Slack, email)
+* ๐ข **75% SLA:** Team lead notified, daily check-ins
+* ๐จ **100% SLA (breach):** Manager escalation, root cause analysis
+* ๐ด **150% SLA:** Executive involvement, process review
+
+**๐ฏ Goal:** Prevent slipping through cracks, ensure accountability
+
+---
+
+## ๐ Slide 10 โ ๐ Remediation Tracking & Verification
+
+* ๐ **Track lifecycle:** Open โ In Progress โ Fixed โ Verified โ Closed
+* ๐งช **Verification critical:** Don't trust "fixed" without testing
+* ๐ **Prevent recurrence:** Same vulnerability shouldn't return
+* ๐ **Metrics matter:** Fix rate, aging, recurrence rate
+
+```mermaid
+flowchart LR
+ Open[๐ Open] --> InProgress[โ๏ธ In Progress]
+ InProgress --> Fixed[โ
Fixed]
+ Fixed --> Verify[๐งช Verify]
+ Verify --> Closed[๐ Closed]
+
+ Verify -.->|Fail| InProgress
+ Closed -.->|Regression| Open
+
+ style Closed fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+```mermaid
+flowchart LR
+ Open[๐ Open
Triaged] --> InProgress[โ๏ธ In Progress
Being Fixed]
+ InProgress --> Fixed[โ
Fixed
Deployed]
+ Fixed --> Verify[๐งช Verify
Test]
+ Verify --> Closed[๐ Closed
Done]
+
+ Verify -->|Failed| InProgress
+ Closed -.->|Regression| Open
+
+ style Closed fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Vulnerability States Explained
+
+* ๐ **Open:** Triaged, waiting for developer assignment or pickup
+* โ๏ธ **In Progress:** Developer actively working on fix
+* โ
**Fixed:** Code changed, patch applied, deployed to environment
+* ๐งช **Verified:** Tested and confirmed vulnerability no longer exists
+* ๐ **Closed:** Permanently resolved, archived
+* โ **False Positive:** Not a real vulnerability, marked and closed
+
+**๐ Metric:** Average days in each state (identify bottlenecks)
+
+---
+
+### ๐งช Verification Checklist
+
+**โ
Before closing vulnerability:**
+1. ๐ **Rescan:** Vulnerability scanner no longer detects it
+2. ๐งช **Test:** Exploitation attempt fails (try to exploit manually)
+3. ๐ **Code review:** Fix is actually secure (not just hiding symptom)
+4. ๐ **Regression test:** Added to test suite (won't return)
+5. ๐ **Documentation:** Updated secure coding guidelines (if applicable)
+
+**โ ๏ธ Don't Skip Verification:**
+* ๐จ "Fixed" โ Actually fixed (common mistake)
+* ๐งช Always test the fix
+* ๐ Verify in production (not just staging)
+
+```mermaid
+flowchart LR
+ Fixed[โ
Fixed] --> Rescan[๐ Rescan]
+ Rescan --> Test[๐งช Test]
+ Test --> Review[๐ Review]
+ Review --> Verified[โ
Verified]
+
+ Rescan -.->|Still There| Reopen[๐ Reopen]
+ Test -.->|Fails| Reopen
+
+ style Verified fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Recurrence Prevention
+
+* ๐ **Recurrence:** Same vulnerability type reappears
+* ๐ฏ **Root causes:** Incomplete fix, code duplication, no tests, lack of training
+* ๐ **Target metric:** Recurrence rate < 5%
+
+**โ
Prevention Strategies:**
+* ๐ **Root cause analysis:** Why did it happen? Why did it return?
+* ๐งช **Regression tests:** Automated tests prevent reoccurrence
+* ๐ **Secure coding training:** Educate developers on patterns
+* ๐ง **Linting rules:** Detect pattern automatically (ESLint, SonarQube rules)
+* ๐ **Secure code templates:** Provide secure examples
+* ๐ **Code review focus:** Watch for similar patterns
+
+```mermaid
+flowchart LR
+ Fixed[โ
Fixed] --> Check{๐ First Time?}
+ Check -->|Yes| Close[โ
Close]
+ Check -->|No| RCA[๐ง Root Cause]
+ RCA --> Prevent[๐ฏ Prevention]
+ Prevent --> Monitor[๐ Track < 5%]
+
+ style RCA fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+## ๐ Slide 11 โ ๐ป Hands-On: Automated Remediation Pipelines
+
+* ๐ค **Automated remediation:** Fix vulnerabilities with minimal human intervention
+* ๐ฏ **Use cases:** Dependency updates, config fixes, common patterns
+* โ ๏ธ **Safety first:** Only automate low-risk, well-tested fixes
+* โก **Speed benefit:** Fix in minutes, not days
+
+```mermaid
+flowchart LR
+ Detect[๐ Detect] --> Auto[๐ค Auto-Fix]
+ Auto --> PR[๐ Create PR]
+ PR --> Test[๐งช CI/CD]
+ Test --> Merge[๐ Auto-Merge]
+ Merge --> Deploy[๐ Deploy]
+ Deploy --> Done[โ
Fixed in 10min]
+
+ style Auto fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Done fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+**๐ Example Automated Workflow:**
+1. ๐ค Dependabot detects new patch for vulnerable dependency
+2. ๐ Automatically creates pull request with update
+3. ๐งช CI/CD runs full test suite automatically
+4. ๐ Security scan runs (verify fix, no new issues)
+5. โ
All tests pass โ Auto-merge (or flag for review)
+6. ๐ Automatic deployment to staging/production
+
+---
+
+### ๐ค Automated Dependency Updates
+
+**๐ง Dependabot Configuration:**
+* โฐ **Schedule:** Daily checks for security updates
+* ๐ **Limits:** Max 5 open PRs (avoid overwhelming team)
+* ๐ฅ **Reviewers:** Auto-assign security team
+* ๐ท๏ธ **Labels:** Tag as "dependencies" and "security"
+* ๐ **Auto-merge:** Enabled for patch updates only
+
+**โ
Auto-Merge Criteria:**
+* ๐ Patch updates only (1.2.3 โ 1.2.4, not 1.2.3 โ 1.3.0)
+* โ
All automated tests pass
+* โ
Security scan shows no new issues
+* โ Minor/major updates require manual review
+
+```mermaid
+flowchart LR
+ Dependabot[๐ค Dependabot] --> Vuln{๐จ Vuln?}
+ Vuln -->|Yes| Type{๐ Type?}
+ Type -->|Patch| Auto[โ
Auto-Merge]
+ Type -->|Minor/Major| Manual[๐ Manual Review]
+
+ Auto --> Deploy[๐ Auto-Deploy]
+
+ style Auto fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ง Auto-Fix Tools & Features
+
+**๐ท Snyk Auto-Fix:**
+* โ
Creates PRs with dependency upgrades
+* ๐ Shows fix impact and test results
+* ๐ฏ Includes upgrade path explanation
+
+**๐ GitHub CodeQL Auto-Fix:**
+* โ
Suggests code changes for vulnerabilities
+* ๐ Security-specific fixes (not just code quality)
+* ๐ก Explains why change is secure
+
+**๐ Semgrep Auto-Fix:**
+* โ
Pattern-based automated fixes
+* โก Can auto-apply safe transformations
+* ๐ฏ Works for common vulnerability patterns
+
+---
+
+### ๐ Automated Patch Testing Pipeline
+
+**๐งช Ephemeral Environment Testing:**
+1. ๐ Dependency update available (webhook trigger)
+2. ๐๏ธ Create temporary test environment (Docker, cloud)
+3. ๐ Deploy application with patch
+4. ๐งช Run test suite (unit, integration, security)
+5. โ
Tests pass โ Promote to production
+6. โ Tests fail โ Alert for manual review + rollback
+7. ๐๏ธ Destroy test environment (cleanup)
+
+**๐ ๏ธ Automation Tools:**
+* ๐ Renovate (advanced Dependabot alternative)
+* ๐ท Snyk auto-remediation
+* ๐ฏ Custom scripts + CI/CD integration
+
+
+๐ญ Safety Guidelines: What to automate vs. manual review
+
+**โ
Safe to Automate:**
+* ๐ Patch updates (security fixes, no breaking changes)
+* ๐งช Changes with comprehensive test coverage
+* โ๏ธ Well-tested config fixes
+* ๐ข Dev/staging deployments
+* ๐ Dependency updates with auto-rollback
+
+**โ ๏ธ Manual Review Required:**
+* ๐ Minor/major version updates (breaking changes possible)
+* ๐ด Production deployments (final human approval)
+* ๐๏ธ Architectural changes
+* ๐ป Complex code refactors
+* ๐ Security-critical components (auth, payment)
+
+**๐ฏ Golden Rule:** Automate what you can test thoroughly and rollback safely
+
+**๐ Gradual Approach:**
+1. ๐ข Month 1: Automate in dev only
+2. ๐ก Month 2: Automate in staging
+3. ๐ Month 3: Auto-merge with manual deploy
+4. ๐ด Month 4: Fully automated with monitoring
+
+**๐จ Always have:** Kill switch, monitoring, rollback plan
+
+
+```mermaid
+flowchart LR
+ Safe[โ
Safe to Automate] --> Patch[๐ Patch Updates]
+ Safe --> Tests[๐งช Good Test Coverage]
+ Safe --> Dev[๐ข Dev Environment]
+
+ Manual[โ ๏ธ Manual Review] --> Major[๐ Major Updates]
+ Manual --> Prod[๐ด Production]
+ Manual --> Critical[๐ Auth/Payment]
+
+ style Safe fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Manual fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+๐ **Resources for Group 3:**
+* [Dependabot Docs](https://docs.github.com/en/code-security/dependabot)
+* [Renovate](https://www.mend.io/free-developer-tools/renovate/)
+* [Snyk Auto-Remediation](https://docs.snyk.io/)
+
+---
+
+๐ **Resources for Group 3:**
+* [Dependabot Docs](https://docs.github.com/en/code-security/dependabot)
+* [Renovate](https://www.mend.io/free-developer-tools/renovate/)
+* [Snyk Auto-Remediation](https://docs.snyk.io/)
+
+---
+
+## ๐ Fun Break: "10-Minute Fix That Saved $1M"
+
+* ๐จ Critical npm vulnerability (CVSS 9.8, KEV, EPSS 95%)
+* โฐ Company with automation: 09:00 detect โ 09:10 fixed (10 min)
+* ๐ Competitors without automation: 6 weeks (ticketโsprintโtestโrelease)
+* ๐ฐ Competitors breached: $1M+ in costs
+* ๐ก Lesson: Automation = competitive advantage!
+
+---
+
+## ๐ Group 4: Vulnerability Lifecycle Management
+
+## ๐ Slide 12 โ ๐ Vulnerability Lifecycle Overview
+
+* ๐ **Complete lifecycle:** Discovery โ Triage โ Remediation โ Verification โ Closure
+* ๐ **Track everything:** Every vulnerability tracked through all states
+* ๐ **Measure effectiveness:** Metrics at each stage reveal bottlenecks
+* ๐ฏ **Continuous improvement:** Data-driven optimization of processes
+
+```mermaid
+flowchart LR
+ Discovery[๐ Discovery] --> Triage[๐จ Triage]
+ Triage --> Remediation[๐ง Remediation]
+ Remediation --> Verification[๐งช Verification]
+ Verification --> Closure[๐ Closure]
+
+ Closure -.->|Regression| Discovery
+
+ style Discovery fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Closure fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+**๐ Key Lifecycle Metrics:**
+* **MTTD:** Mean Time To Detect vulnerabilities
+* **MTTR:** Mean Time To Remediate (fix)
+* **Backlog size:** Total open vulnerabilities
+* **Velocity:** Vulns fixed vs. introduced per sprint
+* **Recurrence rate:** % returning vulns (target: <5%)
+
+```mermaid
+flowchart TD
+ Metrics[๐ Lifecycle Metrics] --> Time[โฐ Time Metrics]
+ Metrics --> Volume[๐ Volume Metrics]
+ Metrics --> Quality[๐ฏ Quality Metrics]
+
+ Time --> MTTD[โฑ๏ธ MTTD
Time to Detect]
+ Time --> MTTR[โฑ๏ธ MTTR
Time to Fix]
+
+ Volume --> Backlog[๐ Backlog Size]
+ Volume --> Velocity[โก Fix Velocity]
+
+ Quality --> Recurrence[๐ Recurrence < 5%]
+ Quality --> SLA[โ
SLA Compliance]
+
+ style Metrics fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+## ๐ Slide 13 โ ๐ Backlog Management & Health
+
+* ๐ **Backlog health:** Most critical vulnerability management metric
+* ๐ฏ **Goal:** Fix rate > Discovery rate = Shrinking backlog
+* ๐จ **Warning:** Growing backlog = Accumulating technical security debt
+* ๐
**Age matters:** Old vulnerabilities harder to fix (code drift, dependencies)
+
+**๐ Backlog Segmentation:**
+* ๐ด **Critical/High:** Should be near zero (active work)
+* ๐ก **Medium:** Controlled queue (30-day pipeline)
+* ๐ข **Low:** Acceptable backlog (managed risk)
+
+```mermaid
+flowchart LR
+ Backlog[๐ Vulnerability Backlog] --> Healthy{๐ฏ Status?}
+
+ Healthy -->|Fix > Discovery| Shrinking[๐ Shrinking
โ
Improving]
+ Healthy -->|Fix = Discovery| Stable[๐ Stable
โ ๏ธ Maintaining]
+ Healthy -->|Fix < Discovery| Growing[๐ Growing
๐จ Danger]
+
+ Shrinking --> Good[โ
Keep Going]
+ Stable --> Action1[โก Increase Velocity]
+ Growing --> Action2[๐จ Emergency Action]
+
+ style Shrinking fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Stable fill:#fffde7,stroke:#f9a825,stroke-width:2px,color:#2c3e50
+ style Growing fill:#ffebee,stroke:#c62828,stroke-width:3px,color:#2c3e50
+```
+
+**โฐ Age Buckets:**
+* ๐ข **0-30 days:** Fresh, normal pipeline
+* ๐ก **31-90 days:** Aging, needs attention
+* ๐ **91-180 days:** Old, prioritize now
+* ๐ด **180+ days:** Ancient, exec attention
+
+```mermaid
+flowchart TD
+ Total[๐ Backlog: 500 Vulns] --> BySeverity[๐ฏ By Severity]
+ Total --> ByAge[โฐ By Age]
+
+ BySeverity --> Crit[๐ด Critical: 5
Target: 0]
+ BySeverity --> High[๐ High: 25
Target: <10]
+ BySeverity --> Med[๐ก Medium: 150]
+ BySeverity --> Low[๐ข Low: 320]
+
+ ByAge --> Fresh[๐ข 0-30d: 200
Normal]
+ ByAge --> Aging[๐ก 31-90d: 180
Watch]
+ ByAge --> Old[๐ 91-180d: 80
Priority]
+ ByAge --> Ancient[๐ด 180+d: 40
๐จ Action!]
+
+ Crit --> Alert[๐จ Immediate Fix]
+ Ancient --> Alert
+
+ style Crit fill:#ffebee,stroke:#c62828,stroke-width:2px,color:#2c3e50
+ style Ancient fill:#ffebee,stroke:#c62828,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+## ๐ Slide 14 โ โก Velocity & Continuous Improvement
+
+* โก **Velocity:** Vulnerabilities fixed per time period (week/sprint/month)
+* ๐ **Throughput:** Rate of moving vulns through pipeline
+* ๐ฏ **Target:** Consistent or increasing velocity
+* ๐ **Track trends:** Are we improving or degrading?
+
+**๐ Velocity Example:**
+
+| Week | ๐ Found | ๐ง Fixed | ๐ Net | ๐ Backlog |
+|------|--------|---------|--------|----------|
+| Week 1 | 60 | 45 | +15 | 515 |
+| Week 2 | 55 | 50 | +5 | 520 |
+| Week 3 | 50 | 65 | -15 | 505 |
+| Week 4 | 48 | 70 | -22 | 483 |
+
+๐ก **Analysis:** Velocity improving, backlog shrinking โ
+
+```mermaid
+flowchart LR
+ Week[๐
This Week] --> Found[๐ Found: 50]
+ Week --> Fixed[๐ง Fixed: 75]
+
+ Found --> Net[๐ Net: -25
โ
Good]
+ Fixed --> Net
+
+ Net --> Velocity[โก Velocity
75/week]
+ Velocity --> Trend{๐ Trend?}
+
+ Trend -->|Up| Good[๐ Improving]
+ Trend -->|Stable| OK[๐ Steady]
+ Trend -->|Down| Bad[๐ Investigate]
+
+ style Net fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Good fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Bad fill:#ffebee,stroke:#c62828,stroke-width:2px,color:#2c3e50
+```
+
+**๐ก Improvement Drivers:**
+* ๐ค **Automation:** 60% auto-fixable = +30 fixes/week
+* ๐ฅ **Security champions:** 5 trained = +20 fixes/week
+* ๐ฏ **Better prioritization:** Risk-based = +15 fixes/week
+* ๐ง **Modernized stack:** Less tech debt = +10 fixes/week
+
+---
+
+๐ **Resources for Group 4:**
+* [OWASP Vulnerability Management](https://owasp.org/www-community/Vulnerability_Management_Lifecycle)
+* [Measuring DevSecOps](https://www.devsecops.org/)
+
+---
+
+## ๐ Fun Break: "The Backlog That Ate Manhattan"
+
+* ๐ข Company: 15,000 vuln backlog, growing +50/month
+* ๐ฐ Security team: Constant stress, never catching up
+* ๐ฏ **Turnaround:** Risk-based priority, closed 8K unreachable vulns, automated 70%
+* ๐ **6 months later:** 15K โ 2K (86% reduction), velocity 150 โ 400/month
+* ๐ก **Lesson:** Can't fix everything. Prioritize, automate, accept risk strategically!
+
+---
+
+## ๐ Group 5: Incident Response
+
+## ๐ Slide 15 โ ๐ฅ Incident Response Framework
+
+* ๐ฅ **Incident:** Active security breach or exploitation in progress
+* ๐จ **Different from vuln:** Vuln = potential risk, Incident = actual harm
+* โฐ **Time critical:** Minutes matter during active incidents
+* ๐ **Structured approach:** Follow NIST/SANS IR frameworks
+
+**๐ NIST IR Lifecycle (6 Phases):**
+
+**1๏ธโฃ Preparation:**
+* ๐ IR plan documented, tested
+* ๐ฅ IR team with clear roles
+* ๐ ๏ธ Tools ready (forensics, backups)
+* ๐ Regular tabletop exercises
+
+**2๏ธโฃ Detection & Analysis:**
+* ๐ Identify incident (SIEM, alerts)
+* ๐ Determine scope, severity
+* ๐ฏ Classify type (malware, breach, DDoS)
+* โฐ Start incident timeline
+
+**3๏ธโฃ Containment:**
+* ๐ง Short-term: Isolate systems
+* ๐ Long-term: Patch vulnerabilities
+* ๐พ Preserve evidence
+
+**4๏ธโฃ Eradication:**
+* ๐๏ธ Remove malware, backdoors
+* ๐ง Fix root cause
+* ๐ Reset compromised credentials
+
+**5๏ธโฃ Recovery:**
+* ๐ Restore to normal operations
+* ๐ Monitor for attacker return
+* โ
Verify systems clean
+
+**6๏ธโฃ Post-Incident:**
+* ๐ Blameless post-mortem
+* ๐ Document lessons learned
+* ๐ง Update IR procedures
+
+```mermaid
+flowchart LR
+ Prep[๐ 1. Prep
Plan] --> Detect[๐ 2. Detect
Identify]
+ Detect --> Contain[๐ง 3. Contain
Stop Spread]
+ Contain --> Eradicate[โก 4. Eradicate
Remove]
+ Eradicate --> Recover[๐ 5. Recover
Restore]
+ Recover --> PostInc[๐ 6. Learn
Improve]
+
+ PostInc -.->|Continuous| Prep
+
+ style Detect fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Contain fill:#ffebee,stroke:#c62828,stroke-width:2px,color:#2c3e50
+ style PostInc fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+```mermaid
+flowchart TD
+ Incident[๐ฅ Incident] --> Severity{๐จ Severity?}
+
+ Severity -->|Critical| P0[๐ด P0: All Hands
CEO Notified]
+ Severity -->|High| P1[๐ P1: IR Team
Manager]
+ Severity -->|Medium| P2[๐ก P2: Security
Standard]
+
+ P0 --> Timeline[โฐ Critical Timeline]
+ Timeline --> T1[โฑ๏ธ 0-15min: Respond]
+ Timeline --> T2[โฑ๏ธ 15-60min: Contain]
+ Timeline --> T3[โฑ๏ธ 1-4h: Eradicate]
+ Timeline --> T4[โฑ๏ธ 4-24h: Recover]
+
+ style P0 fill:#ffebee,stroke:#c62828,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+## ๐ Slide 16 โ ๐ฅ IR Team Roles & Escalation
+
+* ๐ฅ **IR Team:** Cross-functional with clear responsibilities
+* ๐ฏ **Defined roles:** Decided before incident (not during chaos)
+* ๐ **Clear escalation:** Contact lists, decision authority
+* ๐ **24/7 coverage:** On-call rotation
+
+**๐ฏ Core IR Roles:**
+
+**1๏ธโฃ Incident Commander:**
+* ๐ฏ Overall leader, decision maker
+* ๐ Coordinates all activities
+* โฐ Declares severity, escalations
+* ๐จ Authority to take systems offline
+
+**2๏ธโฃ Technical Lead:**
+* ๐ป Leads investigation
+* ๐ Analyzes logs, forensics
+* ๐ง Implements containment
+
+**3๏ธโฃ Communications:**
+* ๐ข Internal/external comms
+* ๐ฐ Media, customers, regulators
+* ๐ฏ Consistent messaging
+
+**4๏ธโฃ Scribe:**
+* ๐ Documents all actions
+* โฐ Maintains timeline
+* ๐ Tracks decisions
+
+**5๏ธโฃ Legal/Compliance:**
+* โ๏ธ Regulatory requirements
+* ๐ Evidence preservation
+
+```mermaid
+flowchart TD
+ Alert[๐จ Alert] --> IC[๐ฏ Incident Commander]
+
+ IC --> Tech[๐ป Tech Lead]
+ IC --> Comms[๐ข Communications]
+ IC --> Scribe[๐ Scribe]
+ IC --> Legal[โ๏ธ Legal]
+
+ Tech --> A1[๐ Investigate]
+ Tech --> A2[๐ง Contain]
+
+ Comms --> A3[๐ง Internal]
+ Comms --> A4[๐ฐ External]
+
+ Scribe --> A5[โฐ Timeline]
+ Scribe --> A6[๐ Decisions]
+
+ Legal --> A7[๐ Breach Notice]
+
+ style IC fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+```
+
+**๐ Escalation Matrix:**
+
+| Severity | IC | Notify | Response |
+|----------|-----|---------|----------|
+| ๐ด P0 | CISO | CEO, Board | 15 min |
+| ๐ P1 | Sec Mgr | CTO | 1 hour |
+| ๐ก P2 | Sec Lead | Eng Mgr | 4 hours |
+
+---
+
+## ๐ Slide 17 โ ๐ Blameless Post-Mortems
+
+* ๐ **Post-mortem:** Analyze what happened (no blame!)
+* ๐ฏ **Goal:** Learn and improve, not punish
+* ๐ **Documentation:** Thorough report for future
+* ๐ **Action items:** Concrete prevention steps
+
+**๐ Post-Mortem Components:**
+
+**1๏ธโฃ Timeline:**
+* โฐ Detailed chronology
+* When detected, contained, resolved?
+
+**2๏ธโฃ Root Cause:**
+* ๐ What vulnerability exploited?
+* ๐ค Why did it exist?
+* ๐ซ Why didn't we detect sooner?
+
+**3๏ธโฃ Impact:**
+* ๐ฐ Financial (downtime, recovery)
+* ๐ Data (accessed/exfiltrated?)
+* ๐ฅ Customers (how many affected?)
+* ๐ฐ Reputational (media?)
+
+**4๏ธโฃ What Went Well:**
+* โ
Fast detection
+* โ
Quick response
+* โ
Clear communication
+* โ
Backups available
+
+**5๏ธโฃ What Went Wrong:**
+* โ Known vuln unpatched
+* โ Incomplete containment
+* โ Delayed escalation
+* โ Tools not ready
+
+**6๏ธโฃ Action Items:**
+* ๐ง Patch similar vulns (by Friday)
+* ๐ Improve monitoring
+* ๐ Train team
+* ๐ Update IR playbook
+
+```mermaid
+flowchart TD
+ Resolved[๐ฅ Incident Resolved] --> PM[๐ Post-Mortem
48h after]
+
+ PM --> Timeline[โฐ Timeline]
+ PM --> RCA[๐ Root Cause]
+ PM --> Impact[๐ฐ Impact]
+ PM --> Good[โ
Went Well]
+ PM --> Bad[โ Went Wrong]
+
+ Timeline --> Actions[๐ฏ Action Items]
+ RCA --> Actions
+ Impact --> Actions
+ Good --> Actions
+ Bad --> Actions
+
+ Actions --> Fix[๐ง Technical]
+ Actions --> Process[๐ Process]
+ Actions --> Training[๐ Training]
+ Actions --> Tools[๐ ๏ธ Tooling]
+
+ Fix --> Track[๐ Track]
+ Process --> Track
+ Training --> Track
+ Tools --> Track
+
+ Track --> Better[โ
Improved]
+
+ style PM fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+ style Better fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+**๐ก Blameless Culture:**
+* ๐ซ No finger-pointing
+* โ
Focus on systems, not individuals
+* ๐ฏ Psychological safety
+* ๐ Honest = real improvements
+
+```mermaid
+flowchart LR
+ Culture[๐ฏ Culture] --> Type{Type?}
+
+ Type -->|Blameful| Bad[โ Fear
Hide Problems
No Learning]
+ Type -->|Blameless| Good[โ
Safety
Report Issues
Improve]
+
+ Good --> Better[๐ Better IR]
+
+ style Bad fill:#ffebee,stroke:#c62828,stroke-width:2px,color:#2c3e50
+ style Good fill:#e8f5e8,stroke:#388e3c,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+๐ **Resources for Group 5:**
+* [NIST IR Guide (SP 800-61)](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final)
+* [SANS IR Handbook](https://www.sans.org/white-papers/33901/)
+* [Google Postmortem Culture](https://sre.google/sre-book/postmortem-culture/)
+
+---
+
+## ๐ Fun Break: "The $200K S3 Bucket Typo"
+
+**๐ชฃ The Story:**
+* ๐จโ๐ป Developer needs to delete test S3 bucket
+* โจ๏ธ Types: aws s3 rm s3://prod-bucket --recursive (typo!)
+* โฐ Friday 5pm execution
+* ๐ฅ **Result:** 10TB production data deleted instantly
+
+**๐ Impact:**
+* ๐ Website down 8 hours
+* ๐ฐ Lost revenue: $150K
+* ๐ง Recovery cost: $50K
+* ๐ Team weekend: Ruined
+
+**โ
Prevention:**
+* ๐ MFA delete enabled
+* ๐ข Separate AWS accounts (dev vs prod)
+* ๐ Versioning enabled (could restore)
+* ๐จ Better alerting (mass deletion alerts)
+
+**๐ก Lesson:** Test your incident response BEFORE you need it!
+
+```mermaid
+flowchart TD
+ Incident[๐ฅ Incident] --> Team[๐ฅ IR Team]
+ Team --> IC[๐ฏ Incident Commander]
+ Team --> Tech[๐ป Tech Lead]
+ Team --> Comms[๐ข Communications]
+ Team --> Scribe[๐ Scribe]
+
+ IC --> Response[โก Coordinate Response]
+
+ style Incident fill:#ffebee,stroke:#c62828,stroke-width:2px,color:#2c3e50
+ style Response fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+## ๐ Summary: Vulnerability Management Essentials
+
+**๐ Discovery:** Use multiple methods (SAST, DAST, SCA, pentests) for defense in depth
+**๐ Assessment:** CVSS + EPSS + KEV + Context = Smart prioritization
+**๐ง Remediation:** Fix fast per SLA, automate where safe, verify always
+**๐ Lifecycle:** Track metrics (backlog, velocity, age), improve continuously
+**๐ฅ Incidents:** Prepare before they happen, respond fast, learn from every event
+
+```mermaid
+flowchart TD
+ VulnMgmt[๐ฏ Vuln Management] --> Discovery[๐ Discovery]
+ VulnMgmt --> Assessment[๐ Assessment]
+ VulnMgmt --> Remediation[๐ง Remediation]
+ VulnMgmt --> Lifecycle[๐ Lifecycle]
+ VulnMgmt --> IR[๐ฅ IR]
+
+ Discovery --> C1[๐ 95%+ Coverage]
+ Assessment --> C2[๐ง Smart Decisions]
+ Remediation --> C3[โก High Velocity]
+ Lifecycle --> C4[๐ Data-Driven]
+ IR --> C5[๐ฏ Always Ready]
+
+ C1 --> Success[โ
Secure Org]
+ C2 --> Success
+ C3 --> Success
+ C4 --> Success
+ C5 --> Success
+
+ style VulnMgmt fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+ style Success fill:#e8f5e8,stroke:#388e3c,stroke-width:3px,color:#2c3e50
+```
+
+**๐ฏ Key Takeaways:**
+* ๐ ๏ธ Orchestrate tools to reduce alert fatigue
+* ๐ง Prioritize by actual threat (not just CVSS)
+* ๐ค Automate everything you can safely
+* ๐ Track metrics for continuous improvement
+* ๐ฅ Prepare IR before incidents happen
+* ๐ Learn from every incident (blameless)
+
+---
+
+๐ **Essential Resources:**
+* [OWASP Vulnerability Management](https://owasp.org/www-community/Vulnerability_Management_Lifecycle)
+* [CVSS Calculator](https://www.first.org/cvss/calculator/)
+* [CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
+* [NIST IR Guide (SP 800-61)](https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final)
+* [Dependency-Track](https://dependencytrack.org/)
+
+---
+
+## ๐ Final Thoughts
+
+**๐ก Vulnerability Management is a Journey:**
+* ๐ Start small: One tool, one metric, one improvement
+* ๐ Iterate: Continuous improvement > perfection
+* ๐ค Automate: Let machines do repetitive work
+* ๐ฅ Collaborate: Security is everyone's job
+* ๐ Measure: What gets measured gets improved
+
+**๐ฏ Remember:**
+* โ
Can't fix everything โ Prioritize by risk
+* โ
Older โ worse โ Focus on exploitability
+* โ
Automation saves time โ Invest in tooling
+* โ
Metrics drive decisions โ Track what matters
+* โ
Incidents will happen โ Be prepared
+
+**๐ Goal: Not zero vulnerabilities (impossible), but effective risk management!**
+
+---
diff --git a/lectures/lec4.md b/lectures/lec4.md
new file mode 100644
index 00000000..1fe04116
--- /dev/null
+++ b/lectures/lec4.md
@@ -0,0 +1,2316 @@
+# ๐Lecture 4 - CI/CD Security & Build Hardening
+
+## ๐ Group 1: CI/CD Pipeline Foundations & Architecture
+
+## ๐ Slide 1 โ ๐๏ธ What is CI/CD? (Continuous Integration/Continuous Deployment)
+
+* ๐๏ธ **CI = Continuous Integration** โ developers merge code changes frequently (multiple times daily) into a shared repository, triggering **automated builds and tests**.
+* ๐ **CD = Continuous Deployment/Delivery** โ automated deployment of validated code changes to **staging/production environments**.
+* ๐ **Core principle**: "**integrate early, deploy often**" โ catch issues fast, reduce integration hell, enable rapid releases.
+* ๐ฏ **Benefits**: faster feedback loops, reduced manual errors, consistent deployments, improved team collaboration.
+* ๐ **Industry adoption**: **85% of organizations** use CI/CD practices as of 2024 (GitLab DevOps Report).
+* ๐ **Learn more**: [What is CI/CD? - GitLab](https://about.gitlab.com/topics/ci-cd/)
+
+```mermaid
+flowchart LR
+ Dev[๐จโ๐ป Developer Commit] --> CI[๐๏ธ CI: Build + Test]
+ CI --> CD[๐ CD: Deploy]
+ CD --> Prod[๐ Production]
+ CI -->|โ Fail| Feedback[๐ง Fast Feedback]
+ Feedback --> Dev
+```
+
+---
+
+## ๐ Slide 2 โ ๐ Evolution of CI/CD: From Manual Builds to Modern Pipelines
+
+* ๐
**1990s-2000s**: Manual builds, nightly builds, "integration hell" โ developers fear merging code.
+* ๐
**2006**: **CruiseControl** introduces automated CI โ "build on every commit" concept emerges.
+* ๐
**2011**: **Jenkins** (Hudson fork) revolutionizes CI with plugins and distributed builds.
+* ๐
**2018**: **Cloud-native CI/CD** emerges โ GitHub Actions, GitLab CI, CircleCI offer **serverless pipelines**.
+* ๐
**2020-2024**: **GitOps**, **Infrastructure-as-Code (IaC)**, and **security-first pipelines** become standard.
+* ๐ **Today**: **AI-assisted pipelines**, **policy-as-code**, and **supply chain security** are the new frontier.
+* ๐ **History deep-dive**: [Evolution of CI/CD - ThoughtWorks](https://www.thoughtworks.com/insights/articles/continuous-integration)
+
+```mermaid
+timeline
+ title ๐ CI/CD Evolution
+ 1990s : ๐ Manual Builds & Integration Hell
+ 2006 : โ๏ธ CruiseControl - Automated CI
+ 2011 : ๐ง Jenkins - Plugin Ecosystem
+ 2018 : โ๏ธ Cloud-Native Pipelines
+ 2024 : ๐ค AI + Security-First Pipelines
+```
+
+---
+
+## ๐ Slide 3 โ ๐๏ธ CI/CD Architecture Components & Trust Boundaries
+
+* ๐๏ธ **Core components** of modern CI/CD architecture:
+ * ๐ **Source Control** (Git repositories) โ code storage and version control
+ * โ๏ธ **Build Agents/Runners** โ compute resources executing pipeline jobs
+ * ๐๏ธ **Artifact Repositories** โ storing build outputs (Docker images, packages)
+ * ๐ **Deployment Targets** โ staging/production environments
+* ๐ก๏ธ **Trust boundaries** โ security perimeters where **privilege levels change**:
+ * ๐ **Internet โ SCM**: public access vs. authenticated repository access
+ * ๐ง **SCM โ Build System**: code checkout vs. build execution
+ * ๐ฆ **Build โ Artifact Store**: temporary builds vs. permanent storage
+ * ๐ฏ **Artifact Store โ Production**: staging approval vs. live deployment
+* โ ๏ธ **Attack surface**: each boundary represents potential **compromise points**.
+* ๐ **Architecture guide**: [CI/CD Security Architecture - NIST](https://csrc.nist.gov/pubs/sp/800/204/final)
+
+```mermaid
+flowchart LR
+ subgraph "๐ Internet Zone"
+ Dev[๐จโ๐ป Developers]
+ end
+
+ subgraph "๐ SCM Zone"
+ Git[๐ Git Repository]
+ end
+
+ subgraph "โ๏ธ Build Zone"
+ Agent[๐ง Build Agent]
+ Tests[๐งช Test Suite]
+ end
+
+ subgraph "๐ฆ Artifact Zone"
+ Registry[๐๏ธ Artifact Registry]
+ end
+
+ subgraph "๐ฏ Deployment Zone"
+ Staging[๐งช Staging]
+ Prod[๐ Production]
+ end
+
+ Dev -->|HTTPS + Auth| Git
+ Git -->|Webhook| Agent
+ Agent --> Tests
+ Tests -->|Success| Registry
+ Registry --> Staging
+ Staging -->|Approval| Prod
+
+ %% Trust boundaries
+ classDef boundary stroke:#ff4444,stroke-width:3px,stroke-dasharray: 5 5
+```
+
+---
+
+## ๐ Slide 4 โ โ๏ธ Popular CI/CD Platforms Overview (Jenkins, GitHub Actions, GitLab CI, Azure DevOps)
+
+* ๐ง **Jenkins** (2011, open-source):
+ * โ
**Strengths**: massive plugin ecosystem (1800+ plugins), self-hosted flexibility
+ * โ **Challenges**: complex setup, security maintenance burden, legacy UI
+ * ๐ข **Best for**: enterprises with dedicated DevOps teams, hybrid cloud
+* โก **GitHub Actions** (2019, cloud-native):
+ * โ
**Strengths**: native Git integration, marketplace ecosystem, serverless
+ * โ **Challenges**: vendor lock-in, pricing for private repos, limited self-hosting
+ * ๐ฅ **Best for**: open-source projects, GitHub-centric workflows
+* ๐ฆ **GitLab CI** (2012, integrated platform):
+ * โ
**Strengths**: built-in SCM+CI+CD+security, self-hosted options
+ * โ **Challenges**: resource-heavy, learning curve for complex workflows
+ * ๐ข **Best for**: teams wanting all-in-one DevSecOps platform
+* ๐ท **Azure DevOps** (2018, Microsoft ecosystem):
+ * โ
**Strengths**: tight Microsoft integration, enterprise features, hybrid support
+ * โ **Challenges**: complexity, licensing costs, less popular in open-source
+ * ๐ข **Best for**: Microsoft-stack enterprises, .NET applications
+
+```mermaid
+quadrantChart
+ title CI/CD Platform Comparison
+ x-axis Low Complexity --> High Complexity
+ y-axis Cloud-Native --> Self-Hosted
+ quadrant-1 Enterprise Self-Hosted
+ quadrant-2 Cloud Enterprise
+ quadrant-3 Simple Cloud
+ quadrant-4 Complex Self-Hosted
+
+ GitHub Actions: [0.3, 0.8]
+ GitLab CI: [0.6, 0.5]
+ Jenkins: [0.8, 0.2]
+ Azure DevOps: [0.7, 0.6]
+ CircleCI: [0.4, 0.9]
+ TeamCity: [0.7, 0.1]
+```
+
+* ๐ **Market share (2024)**: Jenkins 47%, GitHub Actions 31%, GitLab CI 12%, Azure DevOps 7% ([JetBrains DevEcosystem Survey](https://www.jetbrains.com/lp/devecosystem-2024/))
+
+---
+
+## ๐ Slide 5 โ ๐จ Why CI/CD Pipelines Became High-Value Attack Targets
+
+* ๐ฏ **Central position**: CI/CD pipelines have **privileged access** to:
+ * ๐ **Source code repositories** โ intellectual property, secrets
+ * ๐ **Production credentials** โ cloud accounts, databases, APIs
+ * ๐๏ธ **Build infrastructure** โ compute resources, internal networks
+ * ๐ฆ **Artifact repositories** โ deployment packages, container images
+* โก **Attack amplification**: compromising CI/CD enables:
+ * ๐ฆ **Supply chain poisoning** โ inject malicious code into software releases
+ * ๐ **Lateral movement** โ pivot to production systems using pipeline credentials
+ * ๐ฅ **Data exfiltration** โ access sensitive data across multiple environments
+* ๐ฅ **Real-world impact examples**:
+ * **SolarWinds (2020)**: attackers compromised build system โ 18,000 customers affected
+ * **Codecov (2021)**: CI system breach โ customer secrets exposed for months
+ * **NPM ecosystem (2021-2024)**: multiple supply chain attacks via compromised CI/CD
+* ๐ **Growing threat**: **45% increase** in CI/CD-targeted attacks since 2022 ([Checkmarx Supply Chain Report](https://checkmarx.com/resource/documents/en/report/2024-software-supply-chain-security-report/))
+
+```mermaid
+flowchart TD
+ Attacker[๐ Attacker] -->|Compromise| Pipeline[โ๏ธ CI/CD Pipeline]
+ Pipeline -->|Access| Source[๐ Source Code]
+ Pipeline -->|Use| Creds[๐ Production Credentials]
+ Pipeline -->|Control| Infra[๐๏ธ Build Infrastructure]
+ Pipeline -->|Poison| Artifacts[๐ฆ Build Artifacts]
+
+ Source --> Theft[๐ต๏ธ IP Theft]
+ Creds --> Lateral[โ๏ธ Lateral Movement]
+ Infra --> Mining[โ๏ธ Crypto Mining]
+ Artifacts --> Supply[๐ฆ Supply Chain Attack]
+
+ Supply --> Customers[๐ฅ End Users Compromised]
+
+ classDef attack fill:#ffebee,stroke:#d32f2f,stroke-width:2px
+ class Attacker,Theft,Lateral,Mining,Supply,Customers attack
+```
+
+---
+
+## ๐ Slide 6 โ ๐ The OWASP Top 10 CI/CD Security Risks (2024)
+
+* ๐ **OWASP CI/CD Security Top 10** โ framework identifying **most critical risks** in CI/CD environments ([OWASP CI/CD Security](https://owasp.org/www-project-top-10-ci-cd-security-risks/)):
+
+1. **๐ซ CICD-SEC-1: Insufficient Flow Control** โ inadequate pipeline stage controls
+2. **๐ CICD-SEC-2: Inadequate Identity and Access Management** โ excessive permissions
+3. **โ ๏ธ CICD-SEC-3: Dependency Chain Abuse** โ compromised third-party components
+4. **โ ๏ธ CICD-SEC-4: Poisoned Pipeline Execution (PPE)** โ malicious pipeline modifications
+5. **๐ CICD-SEC-5: Insufficient PBAC (Pipeline-Based Access Control)** โ weak pipeline permissions
+6. **๐ CICD-SEC-6: Insufficient Credential Hygiene** โ exposed secrets and credentials
+7. **๐๏ธ CICD-SEC-7: Insecure System Configuration** โ misconfigured CI/CD infrastructure
+8. **๐ CICD-SEC-8: Ungoverned Usage of 3rd Party Services** โ unvetted external services
+9. **๐ CICD-SEC-9: Improper Artifact Integrity Validation** โ unsigned/unverified artifacts
+10. **๐ CICD-SEC-10: Insufficient Logging and Visibility** โ poor monitoring and auditing
+
+* ๐ฏ **Why this matters**: provides **structured approach** to securing CI/CD pipelines
+* ๐ **Industry adoption**: used by **60% of enterprises** for CI/CD security assessments
+
+```mermaid
+pie title ๐ OWASP CI/CD Top 10 Risk Categories
+ "Identity & Access" : 25
+ "Pipeline Security" : 20
+ "Dependency Management" : 15
+ "Configuration" : 15
+ "Monitoring" : 10
+ "Artifact Integrity" : 15
+```
+
+---
+
+## ๐ Slide 7 โ ๐ Supply Chain Attacks via CI/CD: Famous Case Studies
+
+* ๐ **SolarWinds Orion (2020)**:
+ * ๐ฏ **Attack vector**: compromised build system โ malicious code injected during build process
+ * ๐ **Impact**: 18,000+ organizations affected, including US government agencies
+ * โฑ๏ธ **Duration**: undetected for **9 months**, demonstrating stealth capabilities
+ * ๐ก **Lesson**: build environment security is **critical infrastructure**
+
+* ๐งช **Codecov Bash Uploader (2021)**:
+ * ๐ฏ **Attack vector**: compromised CI script in Codecov's infrastructure
+ * ๐ **Impact**: customer environment variables and secrets exposed for **2+ months**
+ * ๐ **Scope**: affected hundreds of companies using Codecov in their CI/CD
+ * ๐ก **Lesson**: third-party CI/CD tools require **continuous monitoring**
+
+* ๐ฆ **NPM Package Attacks (2021-2024)**:
+ * ๐ฏ **Attack vectors**: compromised developer accounts, dependency confusion, typosquatting
+ * ๐ **Examples**: `event-stream`, `ua-parser-js`, `node-ipc` package compromises
+ * ๐ **Impact**: millions of downloads of malicious packages via automated CI/CD
+ * ๐ก **Lesson**: dependency management requires **automated security scanning**
+
+* ๐ **PyTorch Supply Chain (2022)**:
+ * ๐ฏ **Attack vector**: compromised dependency in PyTorch nightly builds
+ * ๐ **Impact**: malicious code in ML framework affecting AI/ML pipelines
+ * โก **Response**: rapid detection and response **within hours**
+ * ๐ก **Lesson**: even "trusted" ecosystems need **continuous validation**
+
+```mermaid
+timeline
+ title ๐ Major CI/CD Supply Chain Attacks
+ 2020 : ๐ SolarWinds (Build System)
+ : 18K+ orgs affected
+ 2021 : ๐งช Codecov (CI Tool)
+ : Secrets exposed 2+ months
+ 2021-24 : ๐ฆ NPM Ecosystem
+ : Multiple package compromises
+ 2022 : ๐ PyTorch ML Framework
+ : Nightly builds compromised
+```
+
+* ๐ฐ **Economic impact**: supply chain attacks cost organizations **average $4.35M per incident** ([IBM Cost of Data Breach 2024](https://www.ibm.com/reports/data-breach))
+* ๐ **Trend**: **300% increase** in supply chain attacks targeting CI/CD since 2021 ([Sonatype State of Software Supply Chain](https://www.sonatype.com/state-of-the-software-supply-chain/))
+
+---
+
+## ๐ Group 2: Pipeline Access Control & Identity Management
+
+## ๐ Slide 8 โ ๐ Authentication & Authorization in CI/CD Pipelines
+
+* ๐ **Authentication** = verifying **who** is accessing the CI/CD system (users, services, systems)
+* ๐ก๏ธ **Authorization** = determining **what** authenticated entities can do (permissions, roles)
+* ๐งฉ **Common authentication methods**:
+ * ๐ค **Human users**: SSO (SAML/OIDC), API tokens, SSH keys
+ * ๐ค **Service accounts**: machine identities, workload identity, service principals
+ * ๐ง **Build agents**: agent tokens, certificate-based authentication
+* ๐ **Identity sources**: Active Directory, LDAP, cloud identity providers (AWS IAM, Azure AD, Google Cloud Identity)
+* โ ๏ธ **Common failures**: shared accounts, long-lived tokens, excessive permissions
+* ๐ **Best practices**: [NIST SP 800-63 Digital Identity Guidelines](https://pages.nist.gov/800-63-3/)
+
+```mermaid
+flowchart LR
+ User[๐ค User/Service] -->|Credentials| AuthN[๐ Authentication]
+ AuthN -->|Valid?| AuthZ[๐ก๏ธ Authorization]
+ AuthZ -->|Permitted?| Resource[๐ CI/CD Resource]
+ AuthN -->|โ Invalid| Deny[๐ซ Access Denied]
+ AuthZ -->|โ No Permission| Deny
+
+ subgraph "Identity Providers"
+ SSO[๐ SSO/OIDC]
+ AD[๐ข Active Directory]
+ Cloud[โ๏ธ Cloud Identity]
+ end
+
+ User -.-> SSO
+ User -.-> AD
+ User -.-> Cloud
+```
+
+---
+
+## ๐ Slide 9 โ ๐ญ Role-Based Access Control (RBAC) for Pipeline Resources
+
+* ๐ญ **RBAC = Role-Based Access Control** โ users assigned to **roles**, roles granted **permissions**
+* ๐๏ธ **CI/CD-specific roles** (example hierarchy):
+ * ๐ **Pipeline Admin**: full pipeline management, user administration
+ * ๐ง **Pipeline Developer**: create/modify pipelines, trigger builds
+ * ๐ **Pipeline Viewer**: read-only access to pipeline status and logs
+ * ๐ **Deployer**: deployment permissions to specific environments
+ * ๐ **Auditor**: read-only access for compliance and security reviews
+* ๐ฏ **Granular permissions**:
+ * ๐ **Repository access**: read/write to specific repos
+ * ๐ง **Pipeline operations**: create, modify, delete, execute
+ * ๐ **Environment access**: dev, staging, production deployment
+ * ๐ **Secret access**: view/use specific credentials and tokens
+* ๐ **Benefits**: scalable permission management, audit trails, compliance alignment
+* ๐ข **Enterprise example**: developers can deploy to staging but need approval for production
+
+```mermaid
+graph TD
+ subgraph "๐ฅ Users"
+ Dev1[๐จโ๐ป Alice - Developer]
+ Dev2[๐จโ๐ป Bob - Senior Dev]
+ Ops1[๐ฉโ๐ง Carol - DevOps]
+ Audit1[๐ฉโ๐ผ Diana - Auditor]
+ end
+
+ subgraph "๐ญ Roles"
+ ViewerRole[๐ Pipeline Viewer]
+ DevRole[๐ง Pipeline Developer]
+ AdminRole[๐ Pipeline Admin]
+ AuditorRole[๐ Auditor]
+ end
+
+ subgraph "๐ Permissions"
+ ReadPerm[๐ Read Pipelines]
+ WritePerm[โ๏ธ Write Pipelines]
+ DeployPerm[๐ Deploy]
+ AdminPerm[โ๏ธ Admin Access]
+ end
+
+ Dev1 --> ViewerRole
+ Dev2 --> DevRole
+ Ops1 --> AdminRole
+ Audit1 --> AuditorRole
+
+ ViewerRole --> ReadPerm
+ DevRole --> ReadPerm
+ DevRole --> WritePerm
+ AdminRole --> AdminPerm
+ AuditorRole --> ReadPerm
+```
+
+---
+
+## ๐ Slide 10 โ ๐ Service Account Security & Credential Management
+
+* ๐ค **Service accounts** = non-human identities for **automated processes** (build agents, deployment scripts, integrations)
+* ๐ **Types of service credentials**:
+ * ๐ซ **API tokens**: GitHub Personal Access Tokens, GitLab tokens
+ * ๐๏ธ **Service principals**: Azure service principals, AWS IAM roles
+ * ๐ **SSH keys**: for Git operations and server access
+ * ๐ช **Workload identity**: cloud-native identity (AWS IRSA, Azure pod identity)
+* โ ๏ธ **Common security risks**:
+ * ๐ **Hardcoded secrets**: tokens stored in plain text in pipelines
+ * โฐ **Long-lived credentials**: tokens that never expire
+ * ๐ฏ **Over-privileged access**: service accounts with excessive permissions
+ * ๐ **Credential sharing**: same token used across multiple pipelines
+* โ
**Security best practices**:
+ * ๐ Use **credential managers** (HashiCorp Vault, cloud key vaults)
+ * โฑ๏ธ Implement **short-lived tokens** with automatic rotation
+ * ๐ฏ Follow **least privilege principle** for service accounts
+ * ๐ Regular **access reviews** and credential audits
+
+```mermaid
+flowchart TD
+ subgraph "โ Insecure Approach"
+ Pipeline1[๐ง Build Pipeline] -->|Hardcoded Token| Git[๐ Git Repo]
+ Pipeline1 -->|Shared Creds| Cloud[โ๏ธ Cloud Services]
+ end
+
+ subgraph "โ
Secure Approach"
+ Pipeline2[๐ง Build Pipeline] -->|Request| Vault[๐ Credential Vault]
+ Vault -->|Short-lived Token| Pipeline2
+ Pipeline2 -->|Authenticated| Git2[๐ Git Repo]
+ Pipeline2 -->|Workload Identity| Cloud2[โ๏ธ Cloud Services]
+ end
+
+ classDef insecure fill:#ffebee,stroke:#d32f2f
+ classDef secure fill:#e8f5e8,stroke:#2e7d32
+
+ class Pipeline1,Git,Cloud insecure
+ class Pipeline2,Vault,Git2,Cloud2 secure
+```
+
+---
+
+## ๐ Slide 11 โ ๐ก๏ธ Multi-Factor Authentication (MFA) for Pipeline Access
+
+* ๐ก๏ธ **MFA = Multi-Factor Authentication** โ requires **multiple verification factors** beyond password
+* ๐งฉ **Authentication factors**:
+ * ๐ง **Something you know**: password, PIN, security questions
+ * ๐ฑ **Something you have**: smartphone app, hardware token, SMS
+ * ๐๏ธ **Something you are**: fingerprint, face recognition, voice
+* ๐ฏ **CI/CD MFA implementation**:
+ * ๐ค **Human access**: mandatory MFA for all pipeline administrative access
+ * ๐ฑ **TOTP (Time-based OTP)**: Google Authenticator, Microsoft Authenticator
+ * ๐ **Hardware tokens**: YubiKey, FIDO2 security keys
+ * ๐ **Push notifications**: mobile app approval workflows
+* ๐ **MFA effectiveness**: blocks **99.9% of automated attacks** ([Microsoft Security Intelligence Report](https://www.microsoft.com/en-us/security/business/security-intelligence-report))
+* ๐ข **Enterprise requirements**: many organizations mandate MFA for all CI/CD access
+* โ ๏ธ **Bypass risks**: SMS-based MFA vulnerable to SIM swapping, prefer app-based or hardware tokens
+
+```mermaid
+sequenceDiagram
+ participant User as ๐ค User
+ participant CICD as ๐ง CI/CD System
+ participant MFA as ๐ฑ MFA Provider
+
+ User->>CICD: 1. Username + Password
+ CICD->>User: 2. MFA Challenge Required
+ User->>MFA: 3. Generate OTP/Approve Push
+ MFA->>User: 4. OTP Code/Approval
+ User->>CICD: 5. Submit MFA Code
+ CICD->>User: 6. โ
Access Granted
+
+ Note over User,CICD: Without valid MFA:
โ Access Denied
+```
+
+* ๐ **Implementation guides**:
+ * [GitHub MFA Setup](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa)
+ * [GitLab MFA Configuration](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html)
+
+---
+
+## ๐ Slide 12 โ โ๏ธ Principle of Least Privilege in CI/CD Workflows
+
+* โ๏ธ **Least Privilege Principle** โ entities should have **minimum permissions** required to perform their function
+* ๐ฏ **Application in CI/CD**:
+ * ๐ค **Users**: developers only access their team's pipelines
+ * ๐ค **Service accounts**: build agents only access required repositories
+ * ๐ง **Pipelines**: each pipeline only accesses necessary resources
+ * ๐ **Environments**: staging access โ production access
+* ๐ **Permission granularity levels**:
+ * ๐๏ธ **Organization level**: admin vs. member access
+ * ๐ **Repository level**: read, write, admin permissions
+ * ๐ง **Pipeline level**: view, edit, execute, delete
+ * ๐ **Environment level**: deploy, approve, configure
+* โ ๏ธ **Common violations**:
+ * ๐ **Admin by default**: giving users more permissions than needed
+ * ๐ **Permission creep**: accumulating permissions over time
+ * ๐ฏ **Broad service accounts**: single account for multiple purposes
+* โ
**Implementation strategies**:
+ * ๐ **Regular access reviews**: quarterly permission audits
+ * ๐ **Just-in-time access**: temporary elevated permissions
+ * ๐ **Permission analytics**: identify unused or excessive permissions
+
+```mermaid
+flowchart TD
+ subgraph "โ Over-Privileged (Bad)"
+ DevA[๐จโ๐ป Developer A] -->|Admin Access| AllRepos[๐ All Repositories]
+ ServiceA[๐ค Service Account] -->|Full Access| AllEnvs[๐ All Environments]
+ end
+
+ subgraph "โ
Least Privilege (Good)"
+ DevB[๐จโ๐ป Developer B] -->|Read/Write| TeamRepos[๐ Team Repositories Only]
+ ServiceB[๐ค Build Service] -->|Deploy Only| StagingEnv[๐งช Staging Environment]
+ ServiceC[๐ค Deploy Service] -->|Deploy Only| ProdEnv[๐ญ Production Environment]
+ end
+
+ classDef bad fill:#ffebee,stroke:#d32f2f
+ classDef good fill:#e8f5e8,stroke:#2e7d32
+
+ class DevA,ServiceA,AllRepos,AllEnvs bad
+ class DevB,ServiceB,ServiceC,TeamRepos,StagingEnv,ProdEnv good
+```
+
+### ๐ป Example: GitHub Repository Permissions
+
+```yaml
+# โ Over-privileged team permissions
+team_permissions:
+ developers:
+ role: admin # Too much access
+ repositories: "*" # Access to all repos
+
+# โ
Least privilege team permissions
+team_permissions:
+ frontend_devs:
+ role: write # Appropriate for development
+ repositories:
+ - "web-app"
+ - "ui-components"
+ backend_devs:
+ role: write
+ repositories:
+ - "api-service"
+ - "database-migrations"
+```
+
+---
+
+## ๐ Slide 13 โ ๐ธ๏ธ Zero-Trust Approaches to Pipeline Security
+
+* ๐ธ๏ธ **Zero-Trust Security Model** โ "**never trust, always verify**" - assume breach and verify every access attempt
+* ๐ **Core Zero-Trust principles for CI/CD**:
+ * ๐ซ **No implicit trust**: verify identity and device for every access
+ * ๐ **Continuous verification**: monitor and re-authenticate during sessions
+ * ๐ฏ **Micro-segmentation**: isolate pipeline components and limit blast radius
+ * ๐ **Real-time monitoring**: detect and respond to anomalous behavior
+* ๐ก๏ธ **Zero-Trust CI/CD implementation**:
+ * ๐ **Device trust**: only managed/compliant devices access pipelines
+ * ๐ **Location-based access**: restrict access based on geographic location
+ * ๐ **Time-based access**: limit access to business hours or maintenance windows
+ * ๐ **Dynamic permissions**: permissions based on current risk assessment
+* ๐งฉ **Supporting technologies**:
+ * ๐ **Secure Access Service Edge (SASE)**: cloud-native security platform
+ * ๐ **Privileged Access Management (PAM)**: just-in-time privileged access
+ * ๐ **User and Entity Behavior Analytics (UEBA)**: detect anomalous behavior
+* ๐ข **Industry adoption**: **67% of enterprises** implementing Zero-Trust by 2025 ([Gartner Zero Trust Research](https://www.gartner.com/en/newsroom/press-releases/2023-07-11-gartner-identifies-three-factors-influencing-adoption-of-a-zero-trust-architecture))
+
+```mermaid
+flowchart TD
+ subgraph "๐ฐ Traditional Perimeter Security"
+ Internet1[๐ Internet] -->|Firewall| Internal1[๐ข Internal Network]
+ Internal1 --> Pipeline1[๐ง CI/CD Pipeline]
+ Internal1 --> Secrets1[๐ Secrets]
+ Pipeline1 -.->|Trusted Network| Secrets1
+ end
+
+ subgraph "๐ธ๏ธ Zero-Trust Security"
+ Internet2[๐ Internet] --> Gateway[๐ก๏ธ Zero-Trust Gateway]
+ Gateway -->|Verify Identity| Pipeline2[๐ง CI/CD Pipeline]
+ Gateway -->|Verify Device| Pipeline2
+ Pipeline2 -->|Authenticate| Vault[๐ Secure Vault]
+ Pipeline2 -->|Monitor| Logs[๐ Security Logs]
+ end
+
+ classDef traditional fill:#fff3e0,stroke:#f57c00
+ classDef zerotrust fill:#e8f5e8,stroke:#2e7d32
+
+ class Internet1,Internal1,Pipeline1,Secrets1 traditional
+ class Internet2,Gateway,Pipeline2,Vault,Logs zerotrust
+```
+
+### ๐ป Example: Zero-Trust Pipeline Configuration
+
+```yaml
+# Zero-Trust CI/CD Pipeline Configuration
+pipeline_security:
+ identity_verification:
+ mfa_required: true
+ device_compliance: required
+ location_restrictions:
+ - "corporate_office"
+ - "approved_vpn"
+
+ access_controls:
+ session_timeout: 2h
+ re_authentication_interval: 30min
+ privilege_escalation: just_in_time
+
+ monitoring:
+ behavioral_analytics: enabled
+ anomaly_detection: enabled
+ real_time_alerts: enabled
+```
+
+* ๐ก **Benefits**: reduced attack surface, improved compliance, faster threat detection
+* ๐ง **Implementation challenges**: complexity, user experience impact, cultural change required
+
+---
+
+## ๐ Group 3: Secure Pipeline Configuration & Hardening
+
+## ๐ Slide 14 โ ๐ Infrastructure-as-Code (IaC) for Pipeline Configuration
+
+* ๐ **IaC = Infrastructure-as-Code** โ managing CI/CD infrastructure through **version-controlled configuration files**
+* ๐๏ธ **Pipeline-as-Code benefits**:
+ * ๐ **Version control**: track changes, rollback capabilities, audit history
+ * ๐ **Reproducibility**: consistent pipeline deployments across environments
+ * ๐ฅ **Collaboration**: code review processes for infrastructure changes
+ * ๐งช **Testing**: validate pipeline configurations before deployment
+* ๐ ๏ธ **Popular IaC tools for CI/CD**:
+ * โ๏ธ **Terraform**: multi-cloud pipeline infrastructure provisioning
+ * ๐ **Azure ARM/Bicep**: Azure DevOps pipeline infrastructure
+ * โ๏ธ **AWS CDK/CloudFormation**: CodePipeline and CodeBuild setup
+ * ๐ **Pulumi**: modern IaC with familiar programming languages
+* ๐ **Adoption statistics**: **76% of organizations** use IaC for CI/CD infrastructure ([HashiCorp State of Cloud Strategy Report](https://www.hashicorp.com/state-of-the-cloud))
+* ๐ **Security advantages**: immutable infrastructure, consistent security configs, policy enforcement
+* ๐ **Best practices**: [Terraform CI/CD Best Practices](https://developer.hashicorp.com/terraform/tutorials/automation)
+
+```mermaid
+flowchart LR
+ subgraph "Traditional Approach"
+ Admin1[๐จโ๐ป Admin] -->|Manual Config| Jenkins1[๐ง Jenkins Server]
+ Admin1 -->|SSH + GUI| Jenkins1
+ end
+
+ subgraph "Infrastructure-as-Code"
+ Dev[๐จโ๐ป Developer] -->|Git Commit| Repo[๐ IaC Repository]
+ Repo -->|Automated| Terraform[๐๏ธ Terraform]
+ Terraform -->|Provision| Jenkins2[๐ง Jenkins Infrastructure]
+ Terraform -->|Configure| Security[๐ก๏ธ Security Policies]
+ end
+
+ classDef traditional fill:#fff3e0,stroke:#f57c00
+ classDef iac fill:#e8f5e8,stroke:#2e7d32
+
+ class Admin1,Jenkins1 traditional
+ class Dev,Repo,Terraform,Jenkins2,Security iac
+```
+
+---
+
+## ๐ Slide 15 โ ๐ Securing Pipeline Configuration Files (YAML/JSON Security)
+
+* ๐ **Configuration file risks**: pipeline definitions (YAML/JSON) are **code** and need security review
+* โ ๏ธ **Common vulnerabilities in pipeline configs**:
+ * ๐ **Hardcoded secrets**: API keys, passwords directly in YAML/JSON files
+ * ๐ **External script execution**: downloading and executing untrusted scripts
+ * ๐ **Command injection**: user input passed to shell commands without validation
+ * ๐ **Overly permissive triggers**: pipelines triggered by any branch or PR
+* ๐ก๏ธ **Configuration security best practices**:
+ * ๐ **Code review mandatory**: all pipeline changes require peer review
+ * ๐ **Secret scanning**: automated detection of credentials in config files
+ * โ
**Schema validation**: ensure pipeline configs follow secure templates
+ * ๐ซ **Restricted permissions**: limit who can modify pipeline configurations
+* ๐งฉ **Platform-specific protections**:
+ * ๐ **GitHub Actions**: required reviewers for workflow changes
+ * ๐ฆ **GitLab CI**: protected variables and restricted runners
+ * ๐ง **Jenkins**: job configuration restrictions and approval processes
+* ๐ **Impact**: **23% of CI/CD breaches** involve compromised configuration files ([Argon Security Research](https://www.argon.io/blog/argo-cd-security-research-findings/))
+
+```mermaid
+flowchart TD
+ subgraph "โ Insecure Pipeline Config"
+ Config1[๐ Pipeline YAML] -->|Contains| Secret1[๐ Hardcoded API Key]
+ Config1 -->|Downloads| Script1[๐ External Script]
+ Config1 -->|Executes| Command1[๐ป Shell Command with User Input]
+ end
+
+ subgraph "โ
Secure Pipeline Config"
+ Config2[๐ Pipeline YAML] -->|References| Vault[๐ Secret Vault]
+ Config2 -->|Uses Approved| Library[๐ Trusted Script Library]
+ Config2 -->|Sanitizes| Input[๐งน Validated Input]
+ Review[๐ฅ Code Review] --> Config2
+ end
+
+ classDef insecure fill:#ffebee,stroke:#d32f2f
+ classDef secure fill:#e8f5e8,stroke:#2e7d32
+
+ class Config1,Secret1,Script1,Command1 insecure
+ class Config2,Vault,Library,Input,Review secure
+```
+
+---
+
+## ๐ Slide 16 โ ๐ฐ Build Environment Isolation & Sandboxing
+
+* ๐ฐ **Build isolation** = running each build in a **separate, controlled environment** to prevent interference and security breaches
+* ๐งฉ **Isolation techniques**:
+ * ๐ฆ **Containerization**: Docker containers for build execution
+ * ๐ฅ๏ธ **Virtual machines**: dedicated VMs for sensitive builds
+ * ๐ **Process isolation**: separate user accounts and namespaces
+ * ๐ **Network isolation**: restricted network access during builds
+* ๐ก๏ธ **Sandboxing benefits**:
+ * ๐ซ **Malware containment**: malicious code cannot escape build environment
+ * ๐ **Secret protection**: credentials isolated per build
+ * ๐งน **Clean state**: each build starts with fresh environment
+ * ๐ **Resource limits**: CPU, memory, and disk quotas per build
+* โ๏ธ **Implementation approaches**:
+ * ๐ณ **Docker-based**: ephemeral containers destroyed after build
+ * โ๏ธ **Cloud runners**: AWS CodeBuild, Google Cloud Build, Azure DevOps hosted agents
+ * ๐ฅ๏ธ **On-premise**: VMware vSphere, Hyper-V, KVM virtualization
+* ๐ **Performance trade-offs**: stronger isolation = higher resource overhead
+* ๐ **Container security**: [Docker Security Best Practices](https://docs.docker.com/develop/security-best-practices/)
+
+```mermaid
+flowchart TD
+ subgraph "๐ฐ Isolated Build Environment"
+ Build1[๐ง Build Job A] --> Container1[๐ฆ Container A]
+ Build2[๐ง Build Job B] --> Container2[๐ฆ Container B]
+ Build3[๐ง Build Job C] --> VM[๐ฅ๏ธ Virtual Machine]
+ end
+
+ subgraph "๐ก๏ธ Security Boundaries"
+ Container1 -.->|Isolated| Network1[๐ Network Namespace]
+ Container2 -.->|Isolated| Network2[๐ Network Namespace]
+ VM -.->|Isolated| Hypervisor[๐๏ธ Hypervisor Layer]
+ end
+
+ subgraph "๐ Shared Resources"
+ Registry[๐ Artifact Registry]
+ Secrets[๐ Secret Store]
+ end
+
+ Container1 -->|Controlled Access| Registry
+ Container2 -->|Controlled Access| Registry
+ VM -->|Controlled Access| Secrets
+```
+
+---
+
+## ๐ Slide 17 โ ๐ซ Preventing Poisoned Pipeline Execution (PPE) Attacks
+
+* โ ๏ธ **Poisoned Pipeline Execution (PPE)** = attacker modifies pipeline configuration to execute **malicious commands during build**
+* ๐ฏ **PPE attack vectors**:
+ * ๐ **Direct config modification**: altering YAML/JSON pipeline files
+ * ๐ **Pull request attacks**: malicious changes in external contributor PRs
+ * ๐งฌ **Template injection**: exploiting dynamic pipeline generation
+ * ๐ฆ **Dependency confusion**: malicious packages with pipeline modifications
+* โ ๏ธ **Real-world PPE examples**:
+ * ๐ข **Codecov incident (2021)**: bash script modification led to credential theft
+ * ๐ฆ **npm package attacks**: malicious install scripts in CI/CD environments
+ * ๐ง **Jenkins plugins**: compromised plugins executing unauthorized code
+* ๐ก๏ธ **PPE prevention strategies**:
+ * ๐ฅ **Mandatory code review**: all pipeline changes require approval
+ * ๐ **Branch protection**: restrict pipeline modifications to trusted users
+ * ๐ฏ **Least privilege**: pipeline permissions limited to necessary operations
+ * ๐ **Runtime monitoring**: detect unusual pipeline behavior during execution
+* ๐ **Growing threat**: PPE attacks increased **67% in 2023** ([Checkmarx Research](https://checkmarx.com/resource/documents/en/report/2024-software-supply-chain-security-report/))
+
+```mermaid
+sequenceDiagram
+ participant Attacker as ๐ Attacker
+ participant Repo as ๐ Repository
+ participant Pipeline as ๐ง CI/CD Pipeline
+ participant Secrets as ๐ Secret Store
+
+ Attacker->>Repo: 1. Submit malicious PR
+ Note over Repo: Pipeline config modified
to steal secrets
+ Repo->>Pipeline: 2. Trigger automated build
+ Pipeline->>Pipeline: 3. Execute malicious commands
+ Pipeline->>Secrets: 4. Access and exfiltrate secrets
+ Pipeline->>Attacker: 5. Send stolen credentials
+
+ Note over Attacker,Secrets: Prevention: Code review
+ Branch protection
+ Runtime monitoring
+```
+
+* ๐ **OWASP guidance**: [Poisoned Pipeline Execution Prevention](https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-4)
+
+---
+
+## ๐ Slide 18 โ ๐ Network Segmentation for CI/CD Infrastructure
+
+* ๐ **Network segmentation** = isolating CI/CD components in **separate network zones** with controlled communication
+* ๐๏ธ **CI/CD network architecture tiers**:
+ * ๐ **DMZ (Demilitarized Zone)**: public-facing components (webhooks, APIs)
+ * ๐ง **Build network**: isolated build agents and runners
+ * ๐ฆ **Artifact network**: secure storage for build outputs
+ * ๐ญ **Production network**: deployment targets with strict access controls
+* ๐ก๏ธ **Segmentation benefits**:
+ * ๐ซ **Lateral movement prevention**: compromised component cannot access other zones
+ * ๐ **Traffic monitoring**: network flows between segments are logged and analyzed
+ * ๐ **Access control**: firewall rules enforce communication policies
+ * ๐ฏ **Blast radius reduction**: security incidents contained to specific segments
+* โ๏ธ **Implementation technologies**:
+ * ๐งฑ **Firewalls**: next-generation firewalls with application awareness
+ * ๐ท๏ธ **VLANs**: virtual local area networks for logical separation
+ * ๐ธ๏ธ **Software-Defined Networking (SDN)**: programmable network policies
+ * โ๏ธ **Cloud security groups**: AWS security groups, Azure NSGs, GCP firewall rules
+* ๐ **Industry adoption**: **82% of enterprises** use network segmentation for CI/CD ([Cisco Security Report](https://www.cisco.com/c/en/us/products/security/security-reports.html))
+
+```mermaid
+flowchart TD
+ subgraph "๐ DMZ Zone"
+ WebHook[๐ช Webhook Receiver]
+ API[๐ Public API]
+ end
+
+ subgraph "๐ง Build Zone"
+ Agent1[๐๏ธ Build Agent 1]
+ Agent2[๐๏ธ Build Agent 2]
+ Scanner[๐ Security Scanner]
+ end
+
+ subgraph "๐ฆ Artifact Zone"
+ Registry[๐๏ธ Artifact Registry]
+ Cache[๐พ Build Cache]
+ end
+
+ subgraph "๐ญ Production Zone"
+ Staging[๐งช Staging Environment]
+ Production[๐ Production Environment]
+ end
+
+ WebHook -->|HTTPS| Agent1
+ API -->|Authenticated| Agent2
+ Agent1 -->|Push Artifacts| Registry
+ Agent2 -->|Security Scan| Scanner
+ Registry -->|Deploy| Staging
+ Staging -->|Approved| Production
+
+ classDef dmz fill:#fff3e0,stroke:#f57c00
+ classDef build fill:#e3f2fd,stroke:#1976d2
+ classDef artifact fill:#f3e5f5,stroke:#7b1fa2
+ classDef prod fill:#e8f5e8,stroke:#388e3c
+
+ class WebHook,API dmz
+ class Agent1,Agent2,Scanner build
+ class Registry,Cache artifact
+ class Staging,Production prod
+```
+
+---
+
+## ๐ Slide 19 โ ๐ Secure Artifact Storage & Repository Management
+
+* ๐ฆ **Artifacts** = build outputs stored for deployment (container images, packages, binaries, libraries)
+* ๐๏ธ **Artifact repository types**:
+ * ๐ณ **Container registries**: Docker Hub, AWS ECR, Azure ACR, Google GCR
+ * ๐ **Package repositories**: npm registry, Maven Central, NuGet Gallery, PyPI
+ * ๐ **Binary repositories**: JFrog Artifactory, Sonatype Nexus, AWS S3
+ * ๐งฌ **Generic storage**: cloud blob storage with versioning and access control
+* ๐ **Security requirements for artifact storage**:
+ * ๐ **Access control**: role-based permissions for push/pull operations
+ * ๐ **Encryption**: artifacts encrypted at rest and in transit
+ * ๐ท๏ธ **Vulnerability scanning**: automated security scanning of stored artifacts
+ * ๐ **Audit logging**: comprehensive logs of all artifact operations
+* โ ๏ธ **Common security risks**:
+ * ๐ **Public exposure**: accidentally making private artifacts publicly accessible
+ * ๐ **Weak authentication**: inadequate access controls allowing unauthorized access
+ * ๐ฆ **Malware injection**: attackers replacing legitimate artifacts with malicious ones
+ * ๐ **Lack of scanning**: unscanned artifacts deployed with known vulnerabilities
+* ๐ฐ **Cost optimization**: lifecycle policies for automatic cleanup of old artifacts
+* ๐ **Registry security**: [Container Registry Security Best Practices](https://cloud.google.com/artifact-registry/docs/secure)
+
+```mermaid
+flowchart LR
+ subgraph "๐๏ธ Build Process"
+ Build[๐ง CI/CD Pipeline]
+ Test[๐งช Security Tests]
+ Sign[โ๏ธ Artifact Signing]
+ end
+
+ subgraph "๐ฆ Secure Artifact Storage"
+ Registry[๐๏ธ Private Registry]
+ Scan[๐ Vulnerability Scanner]
+ Policy[๐ Retention Policy]
+ end
+
+ subgraph "๐ Deployment"
+ Stage[๐งช Staging Deploy]
+ Prod[๐ Production Deploy]
+ Verify[โ
Signature Verification]
+ end
+
+ Build --> Test
+ Test --> Sign
+ Sign --> Registry
+ Registry --> Scan
+ Registry --> Policy
+ Registry --> Stage
+ Stage --> Verify
+ Verify --> Prod
+
+ classDef build fill:#e3f2fd,stroke:#1976d2
+ classDef storage fill:#f3e5f5,stroke:#7b1fa2
+ classDef deploy fill:#e8f5e8,stroke:#388e3c
+
+ class Build,Test,Sign build
+ class Registry,Scan,Policy storage
+ class Stage,Prod,Verify deploy
+```
+
+---
+
+## ๐ Slide 20 โ ๐งน Container Security in Build Environments
+
+* ๐ณ **Container security** = protecting **containerized build processes** from threats and vulnerabilities
+* ๐ **Container-specific risks in CI/CD**:
+ * ๐๏ธ **Insecure base images**: using images with known vulnerabilities
+ * ๐ **Privileged containers**: running containers with root privileges
+ * ๐ **Host path mounts**: exposing host filesystem to build containers
+ * ๐ **Network exposure**: containers with unnecessary network access
+* ๐ก๏ธ **Container hardening practices**:
+ * ๐ฏ **Minimal base images**: distroless, Alpine, or scratch images
+ * ๐ค **Non-root execution**: running containers as non-privileged users
+ * ๐ **Read-only filesystems**: preventing runtime file modifications
+ * ๐ **Security policies**: Pod Security Standards, OPA Gatekeeper, Falco
+* ๐ **Container image scanning**:
+ * ๐ฆ **Vulnerability detection**: Trivy, Clair, Snyk, Twistlock scanning
+ * ๐ **Policy enforcement**: blocking deployments of vulnerable images
+ * ๐ท๏ธ **Image signing**: Sigstore Cosign for supply chain integrity
+ * ๐ **SBOM generation**: Software Bill of Materials for transparency
+* ๐ **Runtime protection**:
+ * ๐๏ธ **Behavioral monitoring**: detecting anomalous container behavior
+ * ๐ซ **Syscall filtering**: restricting dangerous system calls
+ * ๐ **Network policies**: controlling container-to-container communication
+* ๐ **Statistics**: **75% of organizations** experienced container security incidents in 2023 ([Red Hat State of Kubernetes Security](https://www.redhat.com/en/resources/state-kubernetes-security-report-2024))
+
+```mermaid
+flowchart TD
+ subgraph "โ Insecure Container Build"
+ BadImage[๐ณ Ubuntu:latest + Root User]
+ BadMount[๐ Host Path Mount /var/run/docker.sock]
+ BadNetwork[๐ Full Network Access]
+ end
+
+ subgraph "โ
Secure Container Build"
+ GoodImage[๐ณ Distroless + Non-root User]
+ ReadOnly[๐ Read-only Filesystem]
+ NetworkPolicy[๐ Restricted Network Policy]
+ Scanner[๐ Image Vulnerability Scanner]
+ end
+
+ subgraph "๐ก๏ธ Security Controls"
+ PodSecurity[๐ Pod Security Standards]
+ Falco[๐๏ธ Runtime Monitoring]
+ Cosign[โ๏ธ Image Signing]
+ end
+
+ GoodImage --> Scanner
+ Scanner --> PodSecurity
+ PodSecurity --> Falco
+ Falco --> Cosign
+
+ classDef insecure fill:#ffebee,stroke:#d32f2f
+ classDef secure fill:#e8f5e8,stroke:#2e7d32
+ classDef controls fill:#e3f2fd,stroke:#1976d2
+
+ class BadImage,BadMount,BadNetwork insecure
+ class GoodImage,ReadOnly,NetworkPolicy,Scanner secure
+ class PodSecurity,Falco,Cosign controls
+```
+
+---
+
+## ๐ Slide 21 โ โฑ๏ธ Resource Limits & Denial of Service Prevention
+
+* โฑ๏ธ **Resource limits** = preventing CI/CD processes from consuming **excessive compute resources** (CPU, memory, disk, network)
+* ๐ฏ **DoS attack vectors in CI/CD**:
+ * ๐ป **CPU exhaustion**: infinite loops, cryptomining, CPU-intensive operations
+ * ๐ง **Memory bombs**: memory leaks, large data processing, recursive algorithms
+ * ๐พ **Disk space attacks**: generating large files, log flooding, artifact bloat
+ * ๐ **Network flooding**: DDoS attacks, bandwidth consumption, connection exhaustion
+* ๐ก๏ธ **Resource protection strategies**:
+ * โฐ **Timeout policies**: maximum execution time for builds and deployments
+ * ๐ **Resource quotas**: CPU/memory limits per pipeline, user, and organization
+ * ๐ **Rate limiting**: maximum number of concurrent builds, API requests
+ * ๐ **Monitoring and alerting**: real-time resource usage tracking
+* โ๏ธ **Implementation mechanisms**:
+ * ๐ณ **Container limits**: Docker memory/CPU constraints, Kubernetes resource limits
+ * โ๏ธ **Cloud quotas**: AWS service limits, Azure subscription limits, GCP quotas
+ * ๐ง **Build system controls**: Jenkins executor limits, GitHub Actions usage limits
+ * ๐ **Monitoring tools**: Prometheus, Grafana, cloud monitoring dashboards
+* ๐ฐ **Cost control**: preventing runaway processes from generating unexpected cloud bills
+* ๐ **Industry impact**: **32% of CI/CD incidents** involve resource exhaustion attacks ([SANS DevSecOps Survey](https://www.sans.org/white-papers/devsecops-survey/))
+
+```mermaid
+flowchart TD
+ subgraph "โ ๏ธ Uncontrolled Resources"
+ Pipeline1[๐ง Build Pipeline] --> Unlimited[โพ๏ธ No Limits]
+ Unlimited --> CPUSpike[๐ป CPU 100%]
+ Unlimited --> MemoryLeak[๐ง Memory Overflow]
+ Unlimited --> DiskFull[๐พ Disk Space Full]
+ end
+
+ subgraph "โ
Controlled Resources"
+ Pipeline2[๐ง Build Pipeline] --> Limits[๐ Resource Limits]
+ Limits --> CPULimit[๐ป CPU: 2 cores max]
+ Limits --> MemoryLimit[๐ง Memory: 4GB max]
+ Limits --> TimeoutLimit[โฐ Timeout: 30min max]
+ Monitor[๐ Resource Monitor] --> Alerts[๐จ Usage Alerts]
+ end
+
+ subgraph "๐ก๏ธ Protection Mechanisms"
+ Kubernetes[โธ๏ธ K8s Resource Quotas]
+ Docker[๐ณ Container Limits]
+ Cloud[โ๏ธ Cloud Service Quotas]
+ end
+
+ Limits --> Kubernetes
+ Limits --> Docker
+ Limits --> Cloud
+
+ classDef uncontrolled fill:#ffebee,stroke:#d32f2f
+ classDef controlled fill:#e8f5e8,stroke:#2e7d32
+ classDef protection fill:#e3f2fd,stroke:#1976d2
+
+ class Pipeline1,Unlimited,CPUSpike,MemoryLeak,DiskFull uncontrolled
+ class Pipeline2,Limits,CPULimit,MemoryLimit,TimeoutLimit,Monitor,Alerts controlled
+ class Kubernetes,Docker,Cloud protection
+```
+
+---
+
+## ๐ Group 4: Build Integrity & Artifact Security
+
+## ๐ Slide 22 โ ๐ฆ Secure Artifact Creation & Packaging
+
+* ๐ฆ **Artifacts** = final outputs of CI/CD process (executables, container images, packages, libraries, documentation)
+* ๐๏ธ **Secure artifact creation principles**:
+ * ๐งน **Reproducible builds**: same source code produces identical artifacts every time
+ * ๐ **Tamper evidence**: detect if artifacts modified after creation
+ * ๐ **Metadata inclusion**: version info, build environment, dependencies, timestamps
+ * ๐ท๏ธ **Proper labeling**: semantic versioning, environment tags, security classifications
+* โ ๏ธ **Common artifact security risks**:
+ * ๐ฆ **Malware injection**: malicious code inserted during build process
+ * ๐ **Supply chain tampering**: compromised dependencies affecting final artifact
+ * ๐ **Metadata manipulation**: false version info or dependency information
+ * ๐ **Unauthorized distribution**: artifacts shared through insecure channels
+* ๐ก๏ธ **Security measures during packaging**:
+ * ๐ **Pre-packaging scans**: malware detection, vulnerability assessment
+ * ๐ **Build environment validation**: ensure clean, trusted build systems
+ * ๐ท๏ธ **Immutable tagging**: prevent tag reuse for different artifacts
+ * ๐ **Audit trail creation**: complete record of build process and inputs
+* ๐ **Industry trend**: **89% of organizations** implementing secure packaging practices by 2024 ([Sonatype DevSecOps Report](https://www.sonatype.com/state-of-the-software-supply-chain/))
+
+```mermaid
+flowchart LR
+ subgraph "๐๏ธ Build Process"
+ Source[๐ Source Code]
+ Dependencies[๐ Dependencies]
+ Build[โ๏ธ Build System]
+ end
+
+ subgraph "๐ฆ Secure Packaging"
+ Scan[๐ Security Scan]
+ Package[๐ฆ Package Creation]
+ Metadata[๐ Metadata Addition]
+ Tag[๐ท๏ธ Immutable Tagging]
+ end
+
+ subgraph "โ
Verification"
+ Checksum[๐ข Checksum Generation]
+ Signature[โ๏ธ Digital Signature]
+ Registry[๐๏ธ Secure Registry]
+ end
+
+ Source --> Build
+ Dependencies --> Build
+ Build --> Scan
+ Scan --> Package
+ Package --> Metadata
+ Metadata --> Tag
+ Tag --> Checksum
+ Checksum --> Signature
+ Signature --> Registry
+
+ classDef build fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef package fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+ classDef verify fill:#e8f5e8,stroke:#388e3c,color:#2c3e50
+
+ class Source,Dependencies,Build build
+ class Scan,Package,Metadata,Tag package
+ class Checksum,Signature,Registry verify
+```
+
+---
+
+## ๐ Slide 23 โ ๐ Digital Signing & Verification of Build Artifacts
+
+* ๐ **Digital signing** = cryptographic proof that artifact **came from trusted source** and **hasn't been tampered with**
+* ๐ **Signing technologies**:
+ * ๐ **Code signing certificates**: X.509 certificates from trusted Certificate Authorities (CA)
+ * ๐ **GPG/PGP signatures**: GNU Privacy Guard for open-source artifact signing
+ * ๐ **Sigstore Cosign**: modern, keyless signing for container images and artifacts
+ * โ๏ธ **Cloud HSMs**: Hardware Security Modules for enterprise-grade key management
+* ๐ก๏ธ **Signing best practices**:
+ * ๐ **Private key protection**: store signing keys in secure hardware or cloud HSM
+ * โฐ **Time stamping**: include trusted timestamps to prevent replay attacks
+ * ๐ **Certificate management**: regular renewal, revocation capabilities
+ * ๐ฏ **Principle of least privilege**: limit access to signing operations
+* โ
**Verification process**:
+ * ๐ **Signature validation**: verify artifact signature before deployment
+ * ๐๏ธ **Certificate chain validation**: ensure signing certificate is trusted
+ * โฐ **Timestamp verification**: confirm signing occurred within valid timeframe
+ * ๐ **Policy enforcement**: reject unsigned or improperly signed artifacts
+* ๐ **Adoption statistics**: **73% of enterprises** require signed artifacts for production deployment ([Venafi Machine Identity Report](https://www.venafi.com/resource/2024-machine-identity-security-trends-report))
+
+```mermaid
+sequenceDiagram
+ participant Developer as ๐จโ๐ป Developer
+ participant Pipeline as ๐ง CI/CD Pipeline
+ participant HSM as ๐ HSM/Key Vault
+ participant Registry as ๐๏ธ Artifact Registry
+ participant Deploy as ๐ Deployment
+
+ Developer->>Pipeline: 1. Commit Code
+ Pipeline->>Pipeline: 2. Build Artifact
+ Pipeline->>HSM: 3. Request Signing Key
+ HSM->>Pipeline: 4. Provide Signing Capability
+ Pipeline->>Pipeline: 5. Sign Artifact
+ Pipeline->>Registry: 6. Store Signed Artifact
+ Deploy->>Registry: 7. Retrieve Artifact
+ Deploy->>Deploy: 8. Verify Signature
+ alt Valid Signature
+ Deploy->>Deploy: 9. โ
Deploy Artifact
+ else Invalid Signature
+ Deploy->>Deploy: 9. โ Reject Deployment
+ end
+
+ classDef default fill:#f9f,stroke:#333,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+## ๐ Slide 24 โ ๐ Software Bill of Materials (SBOM) Generation
+
+* ๐ **SBOM = Software Bill of Materials** โ comprehensive inventory of **all components, libraries, and dependencies** used in software
+* ๐ฏ **SBOM importance for security**:
+ * ๐ **Vulnerability tracking**: identify which components have known security issues
+ * ๐ **License compliance**: understand licensing obligations for all dependencies
+ * ๐ต๏ธ **Supply chain visibility**: map entire software supply chain for risk assessment
+ * ๐จ **Incident response**: quickly identify affected systems when vulnerabilities discovered
+* ๐ **SBOM formats and standards**:
+ * ๐ **CycloneDX**: OWASP standard, security-focused, supports vulnerability data
+ * ๐ **SPDX (Software Package Data Exchange)**: Linux Foundation standard, license-focused
+ * ๐งพ **SWID (Software Identification)**: ISO standard for software identification
+* ๐ ๏ธ **SBOM generation tools**:
+ * ๐ง **Syft**: open-source SBOM generator for container images and filesystems
+ * ๐ **CycloneDX generators**: language-specific tools (Maven, npm, pip, etc.)
+ * ๐ข **Commercial tools**: Snyk, JFrog Xray, Sonatype Nexus, FOSSA
+* ๐ **Regulatory requirements**: US Executive Order 14028 **mandates SBOM** for federal software procurement
+* ๐ **Learn more**: [NTIA SBOM Minimum Elements](https://www.ntia.doc.gov/files/ntia/publications/sbom_minimum_elements_report.pdf)
+
+```mermaid
+flowchart TD
+ subgraph "๐ฆ Software Artifact"
+ App[๐ฅ๏ธ Application]
+ Lib1[๐ Library A v1.2]
+ Lib2[๐ Library B v2.5]
+ OS[๐ง Base OS Image]
+ end
+
+ subgraph "๐ SBOM Generation"
+ Scanner[๐ต๏ธ SBOM Scanner]
+ Analysis[๐ฌ Dependency Analysis]
+ Format[๐ Format Generation]
+ end
+
+ subgraph "๐ SBOM Output"
+ CycloneDX[๐ CycloneDX Format]
+ SPDX[๐ SPDX Format]
+ Vulnerabilities[โ ๏ธ Vulnerability Data]
+ Licenses[โ๏ธ License Information]
+ end
+
+ App --> Scanner
+ Lib1 --> Scanner
+ Lib2 --> Scanner
+ OS --> Scanner
+ Scanner --> Analysis
+ Analysis --> Format
+ Format --> CycloneDX
+ Format --> SPDX
+ Format --> Vulnerabilities
+ Format --> Licenses
+
+ classDef artifact fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef generation fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+ classDef output fill:#e8f5e8,stroke:#388e3c,color:#2c3e50
+
+ class App,Lib1,Lib2,OS artifact
+ class Scanner,Analysis,Format generation
+ class CycloneDX,SPDX,Vulnerabilities,Licenses output
+```
+
+---
+
+## ๐ Slide 25 โ ๐ท๏ธ Container Image Signing with Cosign/Notary
+
+* ๐ท๏ธ **Container image signing** = cryptographic verification that **container images are authentic** and **haven't been tampered with**
+* ๐ง **Cosign (Sigstore)**:
+ * ๐ **Keyless signing**: uses OIDC identity providers, no long-term key management
+ * ๐ **Transparency log**: public ledger of all signatures for auditability
+ * ๐ฏ **OCI-compliant**: works with any OCI-compatible container registry
+ * ๐ **Open source**: developed by Linux Foundation, widely adopted
+* ๐ณ **Docker Content Trust (Notary)**:
+ * ๐๏ธ **Established standard**: mature signing solution integrated with Docker
+ * ๐ **Key management**: requires managing signing keys and certificates
+ * ๐ฏ **Role-based signing**: different keys for different purposes (root, targets, snapshot)
+ * โ ๏ธ **Legacy concerns**: less active development, complex key management
+* ๐ก๏ธ **Image signing workflow**:
+ * ๐๏ธ **Build**: create container image in CI/CD pipeline
+ * โ๏ธ **Sign**: cryptographically sign image before pushing to registry
+ * ๐ค **Push**: upload both image and signature to registry
+ * ๐ **Verify**: deployment systems verify signature before pulling/running
+* ๐ **Adoption growth**: container image signing adoption increased **156% in 2023** ([CNCF Security Report](https://www.cncf.io/reports/cncf-annual-survey-2023/))
+
+```mermaid
+flowchart LR
+ subgraph "๐๏ธ Build & Sign"
+ Build[๐จ Build Image]
+ Sign[โ๏ธ Sign with Cosign]
+ Identity[๐ OIDC Identity]
+ end
+
+ subgraph "๐ฆ Registry"
+ Image[๐ณ Container Image]
+ Signature[๐ Digital Signature]
+ Transparency[๐ Transparency Log]
+ end
+
+ subgraph "๐ Deploy & Verify"
+ Pull[๐ฅ Pull Image]
+ Verify[๐ Verify Signature]
+ Deploy[๐ Deploy if Valid]
+ Reject[โ Reject if Invalid]
+ end
+
+ Build --> Sign
+ Identity --> Sign
+ Sign --> Image
+ Sign --> Signature
+ Signature --> Transparency
+ Image --> Pull
+ Pull --> Verify
+ Verify --> Deploy
+ Verify --> Reject
+
+ classDef build fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef registry fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+ classDef deploy fill:#e8f5e8,stroke:#388e3c,color:#2c3e50
+ classDef reject fill:#ffebee,stroke:#d32f2f,color:#2c3e50
+
+ class Build,Sign,Identity build
+ class Image,Signature,Transparency registry
+ class Pull,Verify,Deploy deploy
+ class Reject reject
+```
+
+---
+
+## ๐ Slide 26 โ ๐งช Build Reproducibility & Deterministic Builds
+
+* ๐งช **Reproducible builds** = ability to **recreate identical artifacts** from same source code and build environment
+* ๐ฏ **Benefits of reproducible builds**:
+ * ๐ **Tamper detection**: compare official builds with independent rebuilds
+ * ๐ก๏ธ **Supply chain security**: verify no malicious code injection during build
+ * ๐ต๏ธ **Forensic analysis**: investigate security incidents by recreating exact build conditions
+ * ๐ **Compliance**: meet regulatory requirements for software integrity
+* โ ๏ธ **Challenges to reproducibility**:
+ * โฐ **Timestamps**: build tools embedding current time in artifacts
+ * ๐ฒ **Randomness**: random values, memory addresses, hash ordering
+ * ๐ **Environment variation**: different OS versions, locale settings, timezone
+ * ๐ฆ **Dependency versions**: floating version numbers, latest tags
+* ๐ ๏ธ **Achieving reproducible builds**:
+ * ๐ **Fixed environments**: containerized builds with pinned dependencies
+ * โฐ **Controlled timestamps**: use commit timestamp or fixed build date
+ * ๐ **Normalized outputs**: sort file lists, strip debug information
+ * ๐ฏ **Minimal environments**: reduce build environment complexity
+* ๐ **Industry adoption**: **42% of open-source projects** implementing reproducible builds ([Reproducible Builds Project](https://reproducible-builds.org/))
+* ๐ **Success stories**: Debian, Bitcoin Core, Tor Browser achieve reproducible builds
+
+```mermaid
+flowchart TD
+ subgraph "๐ Input Sources"
+ Source1[๐ Source Code v1.0]
+ Deps1[๐ Dependencies pinned]
+ Env1[๐๏ธ Build Environment]
+ end
+
+ subgraph "๐ญ Build Process"
+ Build1[โ๏ธ Official Build]
+ Build2[โ๏ธ Independent Build]
+ Controls[๐ฏ Reproducibility Controls]
+ end
+
+ subgraph "๐ฆ Artifacts"
+ Artifact1[๐ฆ Official Artifact
Hash: abc123]
+ Artifact2[๐ฆ Independent Artifact
Hash: abc123]
+ Match[โ
Identical Artifacts]
+ end
+
+ Source1 --> Build1
+ Deps1 --> Build1
+ Env1 --> Build1
+
+ Source1 --> Build2
+ Deps1 --> Build2
+ Env1 --> Build2
+
+ Controls --> Build1
+ Controls --> Build2
+
+ Build1 --> Artifact1
+ Build2 --> Artifact2
+ Artifact1 --> Match
+ Artifact2 --> Match
+
+ classDef input fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef build fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+ classDef artifact fill:#e8f5e8,stroke:#388e3c,color:#2c3e50
+
+ class Source1,Deps1,Env1 input
+ class Build1,Build2,Controls build
+ class Artifact1,Artifact2,Match artifact
+```
+
+---
+
+## ๐ Slide 27 โ ๐ Integrity Checks: Checksums, Hashes, and Verification
+
+* ๐ข **Integrity checks** = mathematical verification that **artifacts haven't been corrupted** or **maliciously modified**
+* ๐งฎ **Hash algorithms for integrity**:
+ * ๐ข **SHA-256**: most common, cryptographically secure, 256-bit output
+ * ๐ข **SHA-512**: higher security, 512-bit output, slower but more secure
+ * โก **BLAKE2/BLAKE3**: modern alternatives, faster than SHA with same security
+ * โ **MD5/SHA-1**: deprecated due to collision vulnerabilities
+* ๐ **Checksum implementation patterns**:
+ * ๐ **Manifest files**: separate files listing hashes for each artifact
+ * ๐ท๏ธ **Registry metadata**: hashes stored alongside artifacts in repositories
+ * ๐ **SBOM integration**: checksums included in Software Bill of Materials
+ * ๐ **Chain of custody**: hash verification at each stage of pipeline
+* ๐ก๏ธ **Verification best practices**:
+ * ๐ฏ **Multiple hash algorithms**: use different algorithms to detect sophisticated attacks
+ * ๐ **Pre-deployment verification**: always verify before deployment/installation
+ * ๐ **Automated checking**: integrate verification into CI/CD pipeline
+ * ๐ **Audit logging**: log all verification results for compliance
+* โ ๏ธ **Hash collision attacks**: birthday attacks, chosen-prefix attacks against weak algorithms
+* ๐ **Performance considerations**: balance security vs. speed for different use cases
+
+```mermaid
+flowchart LR
+ subgraph "๐ฆ Artifact Creation"
+ Artifact[๐๏ธ Build Artifact]
+ Hash1[๐ข SHA-256 Hash]
+ Hash2[๐ข SHA-512 Hash]
+ Manifest[๐ Checksum Manifest]
+ end
+
+ subgraph "๐๏ธ Storage & Distribution"
+ Registry[๐ Artifact Registry]
+ CDN[๐ Content Distribution]
+ Mirror[๐ช Mirror Sites]
+ end
+
+ subgraph "โ
Verification Process"
+ Download[๐ฅ Download Artifact]
+ Calculate[๐งฎ Calculate Hash]
+ Compare[โ๏ธ Compare Hashes]
+ Result[โ
Verify Integrity]
+ end
+
+ Artifact --> Hash1
+ Artifact --> Hash2
+ Hash1 --> Manifest
+ Hash2 --> Manifest
+
+ Artifact --> Registry
+ Manifest --> Registry
+ Registry --> CDN
+ Registry --> Mirror
+
+ CDN --> Download
+ Mirror --> Download
+ Download --> Calculate
+ Registry --> Compare
+ Calculate --> Compare
+ Compare --> Result
+
+ classDef creation fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef storage fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+ classDef verify fill:#e8f5e8,stroke:#388e3c,color:#2c3e50
+
+ class Artifact,Hash1,Hash2,Manifest creation
+ class Registry,CDN,Mirror storage
+ class Download,Calculate,Compare,Result verify
+```
+
+---
+
+## ๐ Slide 28 โ ๐ Artifact Provenance & Supply Chain Transparency
+
+* ๐ **Provenance** = comprehensive record of **how, when, where, and by whom** an artifact was created
+* ๐ **Supply chain transparency components**:
+ * ๐จโ๐ป **Build actor**: who or what system performed the build
+ * ๐ **Source materials**: exact source code, dependencies, and build inputs
+ * ๐๏ธ **Build environment**: operating system, tools, configuration used
+ * โฐ **Temporal information**: when build occurred, duration, sequence
+* ๐ **SLSA (Supply-chain Levels for Software Artifacts)**:
+ * ๐ **SLSA Level 1**: basic provenance, automated builds
+ * ๐ **SLSA Level 2**: tamper resistance, hosted build service
+ * ๐ **SLSA Level 3**: hardened builds, non-forgeable provenance
+ * ๐ **SLSA Level 4**: highest security, two-person review, hermetic builds
+* ๐ ๏ธ **Provenance technologies**:
+ * ๐ **in-toto**: framework for securing software supply chain integrity
+ * ๐ **SLSA attestations**: standardized format for build provenance
+ * ๐ **Sigstore Rekor**: transparency log for storing provenance data
+ * โ๏ธ **Cloud build provenance**: native support in major cloud platforms
+* ๐ฏ **Use cases for provenance**:
+ * ๐ต๏ธ **Incident response**: trace compromised artifacts to source
+ * ๐ **Risk assessment**: evaluate supply chain security posture
+ * โ๏ธ **Compliance**: meet regulatory requirements for software traceability
+ * ๐ **Vulnerability management**: quickly identify affected systems
+* ๐ **Industry momentum**: **67% of Fortune 500** planning provenance implementation by 2025 ([Linux Foundation Report](https://www.linuxfoundation.org/research/))
+
+```mermaid
+flowchart TD
+ subgraph "๐ Provenance Collection"
+ Actor[๐จโ๐ป Build Actor
CI/CD System]
+ Source[๐ Source Code
Git Commit SHA]
+ Environment[๐๏ธ Build Environment
OS, Tools, Config]
+ Time[โฐ Temporal Data
Timestamps, Duration]
+ end
+
+ subgraph "๐ Attestation Creation"
+ Collect[๐ Collect Metadata]
+ Format[๐ SLSA Format]
+ Sign[โ๏ธ Sign Attestation]
+ end
+
+ subgraph "๐ Transparency & Storage"
+ Rekor[๐ Rekor Log
Immutable Record]
+ Registry[๐๏ธ Artifact Registry
Linked Attestation]
+ Consumer[๐ฅ Consumers
Verification & Trust]
+ end
+
+ Actor --> Collect
+ Source --> Collect
+ Environment --> Collect
+ Time --> Collect
+
+ Collect --> Format
+ Format --> Sign
+ Sign --> Rekor
+ Sign --> Registry
+ Registry --> Consumer
+ Rekor --> Consumer
+
+ classDef collection fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef attestation fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+ classDef transparency fill:#e8f5e8,stroke:#388e3c,color:#2c3e50
+
+ class Actor,Source,Environment,Time collection
+ class Collect,Format,Sign attestation
+ class Rekor,Registry,Consumer transparency
+```
+
+---
+
+## ๐ Group 5: Quality Gates & Automated Security Controls
+
+## ๐ Slide 29 โ ๐ฆ Quality Gates: Definition and Implementation
+
+* ๐ฆ **Quality Gates** = automated **decision points** in CI/CD pipeline that **block progression** if predefined criteria not met
+* ๐ฏ **Purpose of quality gates**:
+ * ๐ **Prevent defective code**: stop buggy or insecure code from reaching production
+ * ๐ **Enforce standards**: ensure code meets organizational quality requirements
+ * ๐ **Fail fast**: catch issues early when they're cheaper and easier to fix
+ * ๐ **Continuous improvement**: provide feedback for development process optimization
+* ๐งฉ **Common quality gate criteria**:
+ * ๐งช **Test coverage**: minimum percentage of code covered by automated tests
+ * ๐ **Bug thresholds**: maximum number of critical/high severity issues
+ * ๐ **Code quality metrics**: complexity, maintainability, duplication limits
+ * ๐ **Security standards**: vulnerability counts, security policy compliance
+* โ๏ธ **Implementation approaches**:
+ * ๐ง **Pipeline stages**: dedicated quality check stages in CI/CD workflow
+ * ๐ **Policy engines**: centralized rules management with OPA, Sentinel
+ * ๐ค **Automated tools**: SonarQube, CodeClimate, Veracode integration
+ * ๐ฅ **Manual approvals**: human review for critical deployment stages
+* ๐ **Industry adoption**: **91% of high-performing teams** use quality gates ([DORA State of DevOps Report](https://cloud.google.com/devops/state-of-devops/))
+
+```mermaid
+flowchart LR
+ subgraph "๐๏ธ Development"
+ Code[๐ป Code Commit]
+ Build[๐จ Build Process]
+ Tests[๐งช Automated Tests]
+ end
+
+ subgraph "๐ฆ Quality Gates"
+ Gate1[๐ฏ Coverage Gate
โฅ80% Required]
+ Gate2[๐ Bug Gate
0 Critical Issues]
+ Gate3[๐ Security Gate
No High CVEs]
+ Gate4[๐ฅ Manual Approval
Production Ready]
+ end
+
+ subgraph "๐ Deployment"
+ Staging[๐งช Staging Deploy]
+ Production[๐ Production Deploy]
+ end
+
+ Code --> Build
+ Build --> Tests
+ Tests --> Gate1
+ Gate1 -->|โ
Pass| Gate2
+ Gate1 -->|โ Fail| Code
+ Gate2 -->|โ
Pass| Gate3
+ Gate2 -->|โ Fail| Code
+ Gate3 -->|โ
Pass| Gate4
+ Gate3 -->|โ Fail| Code
+ Gate4 -->|โ
Approved| Staging
+ Gate4 -->|โ Rejected| Code
+ Staging --> Production
+
+ classDef dev fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef gate fill:#fff3e0,stroke:#f57c00,color:#2c3e50
+ classDef deploy fill:#e8f5e8,stroke:#388e3c,color:#2c3e50
+
+ class Code,Build,Tests dev
+ class Gate1,Gate2,Gate3,Gate4 gate
+ class Staging,Production deploy
+```
+
+---
+
+## ๐ Slide 30 โ ๐ Security Gates vs. Quality Gates in CI/CD
+
+* ๐ **Security Gates** = specialized quality gates focused on **security-specific criteria** and compliance requirements
+* โ๏ธ **Key differences**:
+ * ๐ฏ **Scope**: quality gates cover all aspects (performance, maintainability), security gates focus on vulnerabilities
+ * ๐๏ธ **Compliance**: security gates often tied to regulatory requirements (SOX, HIPAA, PCI-DSS)
+ * โฐ **Timing**: security gates may have different thresholds for different environments
+ * ๐ฅ **Stakeholders**: security teams define criteria, development teams implement
+* ๐ก๏ธ **Common security gate criteria**:
+ * ๐ **Vulnerability scanning**: SAST, DAST, SCA results within acceptable limits
+ * ๐ **Secret detection**: zero exposed credentials or API keys
+ * ๐ **Policy compliance**: adherence to security policies and standards
+ * ๐ท๏ธ **Artifact integrity**: signed artifacts, verified checksums, SBOM presence
+* ๐ฏ **Risk-based approach**:
+ * ๐ข **Development**: lenient thresholds, focus on education and guidance
+ * ๐ก **Staging**: moderate thresholds, balance security with development velocity
+ * ๐ด **Production**: strict thresholds, zero tolerance for high-severity issues
+* ๐ **Implementation statistics**: **78% of organizations** implement security-specific gates ([Snyk State of Open Source Security](https://snyk.io/reports/open-source-security/))
+
+```mermaid
+flowchart TD
+ subgraph "๐ฏ Quality Gates (Broader Scope)"
+ QualityMetrics[๐ Code Quality Metrics
Complexity, Coverage, Duplication]
+ Performance[โก Performance Tests
Load Time, Memory Usage]
+ Functional[๐งช Functional Tests
Unit, Integration, E2E]
+ end
+
+ subgraph "๐ Security Gates (Security-Focused)"
+ Vulnerabilities[๐ Vulnerability Scans
SAST, DAST, SCA Results]
+ Secrets[๐ Secret Detection
API Keys, Credentials]
+ Compliance[๐ Policy Compliance
SOX, HIPAA, PCI-DSS]
+ Integrity[๐ท๏ธ Artifact Integrity
Signatures, Checksums]
+ end
+
+ subgraph "๐ Environment-Specific Thresholds"
+ Dev[๐ข Development
Lenient, Educational]
+ Stage[๐ก Staging
Moderate, Balanced]
+ Prod[๐ด Production
Strict, Zero Tolerance]
+ end
+
+ QualityMetrics --> Dev
+ Performance --> Dev
+ Functional --> Stage
+
+ Vulnerabilities --> Stage
+ Secrets --> Prod
+ Compliance --> Prod
+ Integrity --> Prod
+
+ classDef quality fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef security fill:#ffebee,stroke:#d32f2f,color:#2c3e50
+ classDef environment fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+
+ class QualityMetrics,Performance,Functional quality
+ class Vulnerabilities,Secrets,Compliance,Integrity security
+ class Dev,Stage,Prod environment
+```
+
+---
+
+## ๐ Slide 31 โ โก Automated Security Controls in Pipelines
+
+* โก **Automated Security Controls** = security checks that run **without human intervention** as part of CI/CD pipeline
+* ๐ง **Types of automated security controls**:
+ * ๐ **Static Analysis**: SAST tools scanning source code for vulnerabilities
+ * ๐ **Dynamic Analysis**: DAST tools testing running applications
+ * ๐ฆ **Dependency Scanning**: SCA tools checking third-party components
+ * ๐ **Secret Scanning**: detecting exposed credentials and API keys
+ * ๐๏ธ **Infrastructure Scanning**: IaC security analysis for misconfigurations
+ * ๐ **Compliance Checking**: automated policy validation and audit trails
+* ๐ฏ **Integration patterns**:
+ * ๐ช **Pre-commit hooks**: local security checks before code submission
+ * ๐ **Pipeline stages**: dedicated security scanning steps in CI/CD
+ * ๐ **Continuous monitoring**: ongoing security assessment of deployed systems
+ * ๐จ **Alerting and reporting**: automated notifications and security dashboards
+* โ
**Benefits of automation**:
+ * โก **Speed**: faster feedback compared to manual security reviews
+ * ๐ฏ **Consistency**: standardized security checks across all projects
+ * ๐ **Scalability**: handle large volumes of code and deployments
+ * ๐ **Continuous protection**: security checks run on every change
+* ๐ **Effectiveness metrics**: automated controls catch **85% of common vulnerabilities** before production ([Veracode State of Software Security](https://www.veracode.com/state-of-software-security-report))
+
+```mermaid
+flowchart LR
+ subgraph "๐ Code Development"
+ Developer[๐จโ๐ป Developer]
+ Commit[๐ Code Commit]
+ PR[๐ Pull Request]
+ end
+
+ subgraph "๐ Automated Security Pipeline"
+ PreCommit[๐ช Pre-commit Hooks
Secrets, Linting]
+ SAST[๐ SAST Scan
Code Vulnerabilities]
+ SCA[๐ฆ SCA Scan
Dependencies]
+ DAST[๐ DAST Scan
Running App]
+ IaC[๐๏ธ IaC Scan
Infrastructure]
+ end
+
+ subgraph "๐ Results & Actions"
+ Dashboard[๐ Security Dashboard]
+ Alerts[๐จ Automated Alerts]
+ Block[๐ Block Deployment]
+ Approve[โ
Approve & Deploy]
+ end
+
+ Developer --> PreCommit
+ PreCommit --> Commit
+ Commit --> PR
+ PR --> SAST
+ SAST --> SCA
+ SCA --> DAST
+ DAST --> IaC
+
+ SAST --> Dashboard
+ SCA --> Dashboard
+ DAST --> Alerts
+ IaC --> Dashboard
+
+ Dashboard --> Block
+ Dashboard --> Approve
+ Alerts --> Block
+
+ classDef dev fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef security fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+ classDef results fill:#e8f5e8,stroke:#388e3c,color:#2c3e50
+
+ class Developer,Commit,PR dev
+ class PreCommit,SAST,SCA,DAST,IaC security
+ class Dashboard,Alerts,Block,Approve results
+```
+
+---
+
+## ๐ Slide 32 โ ๐ Policy-as-Code for Build Security
+
+* ๐ **Policy-as-Code** = defining and enforcing security policies through **version-controlled, executable code**
+* ๐ฏ **Core benefits**:
+ * ๐ **Version control**: policies tracked, reviewed, and rolled back like application code
+ * ๐ **Consistency**: same policies applied across all environments and teams
+ * ๐ค **Automation**: policies automatically enforced without manual intervention
+ * ๐ฅ **Collaboration**: security and development teams jointly define policies
+* ๐ ๏ธ **Policy-as-Code tools and frameworks**:
+ * ๐ง **Open Policy Agent (OPA)**: general-purpose policy engine with Rego language
+ * ๐๏ธ **HashiCorp Sentinel**: policy framework integrated with Terraform and Vault
+ * โ๏ธ **Cloud-native**: AWS Config Rules, Azure Policy, GCP Organization Policy
+ * ๐ **Specialized tools**: Falco for runtime security, Conftest for configuration testing
+* ๐ **Common policy types for CI/CD**:
+ * ๐ **Security policies**: vulnerability thresholds, encryption requirements
+ * ๐๏ธ **Compliance policies**: regulatory requirements (GDPR, SOX, HIPAA)
+ * ๐ฐ **Cost policies**: resource limits, budget constraints
+ * ๐ก๏ธ **Operational policies**: deployment windows, approval requirements
+* ๐ฏ **Implementation workflow**:
+ * ๐ **Define**: write policies in domain-specific language
+ * ๐งช **Test**: validate policies against test scenarios
+ * ๐ **Deploy**: integrate policies into CI/CD pipeline
+ * ๐ **Monitor**: track policy violations and effectiveness
+* ๐ **Adoption trend**: **64% of enterprises** implementing Policy-as-Code by 2024 ([Gartner Infrastructure Automation Survey](https://www.gartner.com/en/information-technology))
+
+```mermaid
+flowchart TD
+ subgraph "๐ Policy Definition"
+ SecurityTeam[๐ก๏ธ Security Team]
+ DevTeam[๐จโ๐ป Development Team]
+ PolicyRepo[๐ Policy Repository]
+ end
+
+ subgraph "๐ง Policy Engine"
+ OPA[๐ง Open Policy Agent]
+ Sentinel[๐๏ธ HashiCorp Sentinel]
+ CloudPolicy[โ๏ธ Cloud Native Policies]
+ end
+
+ subgraph "๐ Enforcement Points"
+ PreDeploy[๐ Pre-deployment Check]
+ Runtime[โก Runtime Validation]
+ Compliance[๐ Compliance Audit]
+ end
+
+ subgraph "๐ Monitoring & Feedback"
+ Violations[โ ๏ธ Policy Violations]
+ Reports[๐ Compliance Reports]
+ Improvement[๐ Policy Refinement]
+ end
+
+ SecurityTeam --> PolicyRepo
+ DevTeam --> PolicyRepo
+ PolicyRepo --> OPA
+ PolicyRepo --> Sentinel
+ PolicyRepo --> CloudPolicy
+
+ OPA --> PreDeploy
+ Sentinel --> PreDeploy
+ CloudPolicy --> Runtime
+
+ PreDeploy --> Violations
+ Runtime --> Violations
+ Runtime --> Compliance
+
+ Violations --> Reports
+ Compliance --> Reports
+ Reports --> Improvement
+ Improvement --> PolicyRepo
+
+ classDef definition fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef engine fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+ classDef enforcement fill:#fff3e0,stroke:#f57c00,color:#2c3e50
+ classDef monitoring fill:#e8f5e8,stroke:#388e3c,color:#2c3e50
+
+ class SecurityTeam,DevTeam,PolicyRepo definition
+ class OPA,Sentinel,CloudPolicy engine
+ class PreDeploy,Runtime,Compliance enforcement
+ class Violations,Reports,Improvement monitoring
+```
+
+---
+
+## ๐ Slide 33 โ ๐ Breaking Builds on Security Policy Violations
+
+* ๐ **Build breaking** = automatically **stopping CI/CD pipeline** when security policies are violated
+* ๐ฏ **When to break builds**:
+ * ๐ด **Critical vulnerabilities**: CVSS score โฅ 9.0 or actively exploited vulnerabilities
+ * ๐ **Exposed secrets**: API keys, passwords, certificates found in code
+ * ๐ **Compliance violations**: regulatory requirement breaches (PCI-DSS, HIPAA)
+ * ๐ท๏ธ **Unsigned artifacts**: missing digital signatures on production deployments
+* โ๏ธ **Risk-based approach to build breaking**:
+ * ๐ข **Development branches**: warnings and guidance, minimal build breaking
+ * ๐ก **Feature branches**: moderate enforcement, break on high-severity issues
+ * ๐ด **Main/production branches**: strict enforcement, break on any policy violation
+* ๐ ๏ธ **Implementation strategies**:
+ * ๐ **Graduated enforcement**: increase strictness closer to production
+ * ๐ **Grace periods**: allow time for teams to adapt to new policies
+ * ๐ **Override mechanisms**: emergency bypasses with proper approval and audit
+ * ๐ **Developer education**: provide clear guidance on fixing violations
+* ๐ **Benefits vs. challenges**:
+ * โ
**Benefits**: prevents security issues reaching production, enforces standards
+ * โ ๏ธ **Challenges**: potential developer productivity impact, false positives
+* ๐ **Industry practice**: **87% of organizations** break builds on critical security issues ([GitLab DevSecOps Survey](https://about.gitlab.com/developer-survey/))
+
+```mermaid
+flowchart TD
+ subgraph "๐ Security Scanning"
+ CodeScan[๐ Code Analysis]
+ DepScan[๐ฆ Dependency Scan]
+ SecretScan[๐ Secret Detection]
+ ComplianceScan[๐ Compliance Check]
+ end
+
+ subgraph "๐ Policy Evaluation"
+ Critical[๐ด Critical Issues
CVSS โฅ 9.0]
+ High[๐ก High Issues
CVSS 7.0-8.9]
+ Medium[๐ข Medium Issues
CVSS 4.0-6.9]
+ Low[โช Low Issues
CVSS < 4.0]
+ end
+
+ subgraph "๐ฏ Decision Logic"
+ ProdBranch[๐ด Production Branch
Strict Enforcement]
+ FeatureBranch[๐ก Feature Branch
Moderate Enforcement]
+ DevBranch[๐ข Dev Branch
Lenient Enforcement]
+ end
+
+ subgraph "๐ฆ Build Actions"
+ Break[๐ Break Build
Block Deployment]
+ Warn[โ ๏ธ Warning Only
Continue with Alert]
+ Pass[โ
Pass
Continue Normally]
+ end
+
+ CodeScan --> Critical
+ DepScan --> High
+ SecretScan --> Critical
+ ComplianceScan --> High
+
+ Critical --> ProdBranch
+ High --> FeatureBranch
+ Medium --> DevBranch
+ Low --> DevBranch
+
+ ProdBranch --> Break
+ FeatureBranch --> Warn
+ DevBranch --> Pass
+
+ classDef scanning fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef policy fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+ classDef decision fill:#fff3e0,stroke:#f57c00,color:#2c3e50
+ classDef action fill:#e8f5e8,stroke:#388e3c,color:#2c3e50
+
+ class CodeScan,DepScan,SecretScan,ComplianceScan scanning
+ class Critical,High,Medium,Low policy
+ class ProdBranch,FeatureBranch,DevBranch decision
+ class Break,Warn,Pass action
+```
+
+---
+
+## ๐ Slide 34 โ ๐ Security Metrics & KPIs for Pipeline Health
+
+* ๐ **Security KPIs (Key Performance Indicators)** = measurable values that track **security effectiveness** in CI/CD pipelines
+* ๐ฏ **Leading indicators** (predict future security issues):
+ * โฑ๏ธ **Mean Time to Fix (MTTF)**: average time to resolve security vulnerabilities
+ * ๐ **Vulnerability detection rate**: percentage of vulnerabilities caught in pipeline vs. production
+ * ๐ **Security test coverage**: percentage of code covered by security-focused tests
+ * ๐โโ๏ธ **Security debt**: accumulation of known but unaddressed security issues
+* ๐ **Lagging indicators** (measure security outcomes):
+ * ๐ **Escaped defects**: security issues that reach production
+ * ๐จ **Security incidents**: actual breaches or exploitation attempts
+ * โฐ **Vulnerability age**: how long security issues remain unpatched
+ * ๐ฐ **Security-related downtime**: service disruptions due to security issues
+* ๐ **Operational metrics**:
+ * ๐ **Pipeline security scan frequency**: how often security checks run
+ * ๐ **Build break rate**: percentage of builds stopped due to security issues
+ * ๐ฅ **Developer engagement**: participation in security training and practices
+ * ๐ **Policy compliance rate**: adherence to security policies and standards
+* ๐ฏ **Industry benchmarks**:
+ * ๐ **High performers**: MTTF < 24 hours, >95% vulnerability detection in pipeline
+ * ๐ **Average performers**: MTTF 1-7 days, 80-95% detection rate
+ * ๐ **Low performers**: MTTF > 7 days, <80% detection rate
+* ๐ **Measurement tools**: DORA metrics, SOAR platforms, security dashboards
+
+```mermaid
+flowchart LR
+ subgraph "๐ฏ Leading Indicators (Predictive)"
+ MTTF[โฑ๏ธ Mean Time to Fix
Target: < 24 hours]
+ DetectionRate[๐ Detection Rate
Target: > 95%]
+ Coverage[๐ Security Coverage
Target: > 80%]
+ Debt[๐โโ๏ธ Security Debt
Target: Decreasing]
+ end
+
+ subgraph "๐ Lagging Indicators (Outcome)"
+ Escaped[๐ Escaped Defects
Target: < 5%]
+ Incidents[๐จ Security Incidents
Target: 0 critical]
+ VulnAge[โฐ Vulnerability Age
Target: < 30 days]
+ Downtime[๐ฐ Security Downtime
Target: < 0.1%]
+ end
+
+ subgraph "โ๏ธ Operational Metrics"
+ ScanFreq[๐ Scan Frequency
Every commit]
+ BreakRate[๐ Build Break Rate
5-10% target]
+ Engagement[๐ฅ Developer Engagement
Training completion]
+ Compliance[๐ Policy Compliance
>98% target]
+ end
+
+ subgraph "๐ Performance Tiers"
+ HighPerf[๐ High Performers
MTTF < 24h, >95% detection]
+ AvgPerf[๐ Average Performers
MTTF 1-7d, 80-95% detection]
+ LowPerf[๐ Low Performers
MTTF > 7d, <80% detection]
+ end
+
+ MTTF --> HighPerf
+ DetectionRate --> HighPerf
+ Coverage --> AvgPerf
+ Debt --> LowPerf
+
+ classDef leading fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef lagging fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+ classDef operational fill:#fff3e0,stroke:#f57c00,color:#2c3e50
+ classDef performance fill:#e8f5e8,stroke:#388e3c,color:#2c3e50
+
+ class MTTF,DetectionRate,Coverage,Debt leading
+ class Escaped,Incidents,VulnAge,Downtime lagging
+ class ScanFreq,BreakRate,Engagement,Compliance operational
+ class HighPerf,AvgPerf,LowPerf performance
+```
+
+---
+
+## ๐ Group 6: Dependency Management & Software Composition Analysis
+
+## ๐ Slide 35 โ ๐ Third-Party Dependency Security Risks
+
+* ๐ **Dependencies** = external libraries, frameworks, and components that applications rely on for functionality
+* ๐ฏ **Why dependencies create security risks**:
+ * ๐ฆ **Inherited vulnerabilities**: security flaws in third-party code affect your application
+ * ๐ **Transitive dependencies**: dependencies of dependencies create deep, complex chains
+ * ๐ **Supply chain exposure**: compromised upstream packages can poison entire ecosystems
+ * ๐ **Scale complexity**: modern apps contain 100s-1000s of dependencies
+* โ ๏ธ **Common dependency security issues**:
+ * ๐ **Known vulnerabilities**: CVEs in popular libraries (Log4Shell, Struts, etc.)
+ * ๐ฆ **Malicious packages**: intentionally harmful code injected into package repositories
+ * ๐ **Dependency confusion**: attackers exploit naming similarities to inject malicious packages
+ * โฐ **Outdated versions**: using old versions with known security issues
+ * ๐ **License violations**: legal risks from incompatible or restrictive licenses
+* ๐ **Scale of the problem**:
+ * ๐ฆ **Average application**: contains 500+ open-source components ([Sonatype Report](https://www.sonatype.com/state-of-the-software-supply-chain/))
+ * ๐ **Vulnerability growth**: 20,000+ new vulnerabilities discovered in open-source components annually
+ * ๐ฏ **Attack frequency**: 742% increase in supply chain attacks from 2019-2022
+* ๐ **Real-world impact**: Equifax breach (Apache Struts), SolarWinds attack (build tool compromise)
+
+```mermaid
+flowchart TD
+ subgraph "๐ฅ๏ธ Your Application"
+ App[๐ป Main Application Code]
+ end
+
+ subgraph "๐ Direct Dependencies"
+ Lib1[๐ฆ Web Framework v2.1]
+ Lib2[๐ฆ Database Driver v1.5]
+ Lib3[๐ฆ JSON Parser v3.2]
+ end
+
+ subgraph "๐ Transitive Dependencies"
+ Trans1[๐ฆ HTTP Client v1.8]
+ Trans2[๐ฆ Crypto Library v2.0]
+ Trans3[๐ฆ XML Parser v1.2]
+ Trans4[๐ฆ Logging Framework v1.9]
+ end
+
+ subgraph "โ ๏ธ Security Risks"
+ Vuln1[๐ Known CVE in XML Parser]
+ Vuln2[๐ฆ Malicious Code in HTTP Client]
+ Vuln3[โฐ Outdated Crypto Library]
+ end
+
+ App --> Lib1
+ App --> Lib2
+ App --> Lib3
+
+ Lib1 --> Trans1
+ Lib1 --> Trans2
+ Lib2 --> Trans3
+ Lib3 --> Trans4
+
+ Trans1 --> Vuln2
+ Trans2 --> Vuln3
+ Trans3 --> Vuln1
+
+ classDef app fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef direct fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+ classDef transitive fill:#fff3e0,stroke:#f57c00,color:#2c3e50
+ classDef risk fill:#ffebee,stroke:#d32f2f,color:#2c3e50
+
+ class App app
+ class Lib1,Lib2,Lib3 direct
+ class Trans1,Trans2,Trans3,Trans4 transitive
+ class Vuln1,Vuln2,Vuln3 risk
+```
+
+---
+
+## ๐ Slide 36 โ ๐ Software Composition Analysis (SCA) in Build Pipelines
+
+* ๐ **SCA = Software Composition Analysis** โ automated identification and security assessment of **open-source and third-party components**
+* ๐ฏ **SCA core capabilities**:
+ * ๐ **Inventory creation**: comprehensive list of all dependencies and versions
+ * ๐ **Vulnerability detection**: matching components against known CVE databases
+ * โ๏ธ **License analysis**: identifying licensing obligations and conflicts
+ * ๐ **Risk assessment**: scoring components based on security, quality, and compliance factors
+* ๐ ๏ธ **Popular SCA tools**:
+ * ๐ข **Commercial**: Snyk, Veracode, Checkmarx, JFrog Xray, Sonatype Nexus
+ * ๐ **Open source**: OWASP Dependency-Check, GitHub Dependabot, GitLab Dependency Scanning
+ * โ๏ธ **Cloud-native**: AWS Inspector, Azure Security Center, Google Container Analysis
+* โ๏ธ **SCA integration in CI/CD**:
+ * ๐ **Pre-commit**: local scanning before code submission
+ * ๐ **Build stage**: automated scanning during compilation
+ * ๐ฆ **Package stage**: scanning before artifact creation
+ * ๐ **Deployment**: scanning before production release
+* ๐ **Effectiveness metrics**:
+ * ๐ฏ **Coverage**: percentage of dependencies actively monitored
+ * โฑ๏ธ **Detection speed**: time from vulnerability disclosure to identification
+ * ๐ **False positive rate**: accuracy of vulnerability identification
+* ๐ **Industry adoption**: **89% of organizations** use SCA tools in their CI/CD pipelines ([Synopsis OSSRA Report](https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis-report.html))
+
+```mermaid
+flowchart LR
+ subgraph "๐ Code Repository"
+ Code[๐ป Application Code]
+ ManifestFiles[๐ Dependency Manifests
package.json, pom.xml, requirements.txt]
+ LockFiles[๐ Lock Files
package-lock.json, Pipfile.lock]
+ end
+
+ subgraph "๐ SCA Analysis Engine"
+ Scanner[๐ต๏ธ Component Scanner]
+ CVEDatabase[๐๏ธ CVE Database
NVD, OSV, GitHub Advisory]
+ LicenseDB[โ๏ธ License Database
SPDX, OSI Approved]
+ RiskEngine[๐ Risk Assessment Engine]
+ end
+
+ subgraph "๐ SCA Outputs"
+ Inventory[๐ Component Inventory
SBOM Generation]
+ Vulnerabilities[๐ Vulnerability Report
CVSS Scores, Exploitability]
+ Licenses[โ๏ธ License Compliance
Obligations, Conflicts]
+ Recommendations[๐ก Remediation Guidance
Updates, Alternatives]
+ end
+
+ Code --> Scanner
+ ManifestFiles --> Scanner
+ LockFiles --> Scanner
+
+ Scanner --> CVEDatabase
+ Scanner --> LicenseDB
+ Scanner --> RiskEngine
+
+ RiskEngine --> Inventory
+ CVEDatabase --> Vulnerabilities
+ LicenseDB --> Licenses
+ RiskEngine --> Recommendations
+
+ classDef code fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef analysis fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+ classDef output fill:#e8f5e8,stroke:#388e3c,color:#2c3e50
+
+ class Code,ManifestFiles,LockFiles code
+ class Scanner,CVEDatabase,LicenseDB,RiskEngine analysis
+ class Inventory,Vulnerabilities,Licenses,Recommendations output
+```
+
+---
+
+## ๐ Slide 37 โ โ ๏ธ Vulnerability Scanning of Dependencies
+
+* โ ๏ธ **Dependency vulnerability scanning** = automated process of **identifying known security flaws** in third-party components
+* ๐ **Vulnerability data sources**:
+ * ๐๏ธ **NVD (National Vulnerability Database)**: US government's official CVE database
+ * ๐ **OSV (Open Source Vulnerabilities)**: distributed vulnerability database for open source
+ * ๐ **GitHub Security Advisory**: platform-specific vulnerability data
+ * ๐ข **Commercial feeds**: vendor-specific vulnerability intelligence (Snyk, VulnDB)
+* ๐ **CVSS scoring and prioritization**:
+ * ๐ด **Critical (9.0-10.0)**: immediate action required, likely remote code execution
+ * ๐ **High (7.0-8.9)**: priority fixing, significant security impact
+ * ๐ก **Medium (4.0-6.9)**: moderate risk, plan remediation
+ * ๐ข **Low (0.1-3.9)**: minimal risk, fix when convenient
+* ๐ฏ **Advanced vulnerability assessment**:
+ * ๐ฅ **Exploit availability**: is there a known exploit in the wild?
+ * ๐ฏ **Reachability analysis**: is the vulnerable code actually used in your application?
+ * ๐ **Environmental factors**: network exposure, data sensitivity, compliance requirements
+* ๐ **Scanning frequency patterns**:
+ * ๐ **Continuous**: real-time monitoring of deployed applications
+ * ๐
**Daily**: scheduled scans for new vulnerabilities
+ * ๐ **On-demand**: triggered by code changes or security events
+* ๐ **Industry challenge**: average of **528 vulnerabilities** per application, with only 9.5% actually exploitable ([Veracode SOSS Report](https://www.veracode.com/state-of-software-security-report))
+
+```mermaid
+flowchart TD
+ subgraph "๐ฆ Component Identification"
+ App[๐ฅ๏ธ Application]
+ Components[๐ Component List
Name, Version, Location]
+ Fingerprint[๐ Component Fingerprinting
Hashes, Metadata]
+ end
+
+ subgraph "๐๏ธ Vulnerability Databases"
+ NVD[๐๏ธ NVD Database
Official CVE Data]
+ OSV[๐ OSV Database
Open Source Focus]
+ GitHub[๐ GitHub Advisory
Platform Specific]
+ Commercial[๐ข Commercial Feeds
Enhanced Intelligence]
+ end
+
+ subgraph "๐ Risk Assessment"
+ CVSS[๐ CVSS Scoring
0.1-10.0 Scale]
+ Exploitability[๐ฅ Exploit Availability
Public PoCs, Active Use]
+ Reachability[๐ฏ Code Reachability
Is Vulnerable Code Used?]
+ Context[๐ Environmental Context
Exposure, Data Sensitivity]
+ end
+
+ subgraph "๐จ Actionable Results"
+ Critical[๐ด Critical Issues
Immediate Action]
+ High[๐ High Priority
Fix Soon]
+ Medium[๐ก Medium Priority
Plan Remediation]
+ Low[๐ข Low Priority
Fix When Convenient]
+ end
+
+ App --> Components
+ Components --> Fingerprint
+
+ Fingerprint --> NVD
+ Fingerprint --> OSV
+ Fingerprint --> GitHub
+ Fingerprint --> Commercial
+
+ NVD --> CVSS
+ OSV --> Exploitability
+ GitHub --> Reachability
+ Commercial --> Context
+
+ CVSS --> Critical
+ Exploitability --> Critical
+ Reachability --> High
+ Context --> Medium
+ CVSS --> Low
+
+ classDef identification fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef database fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+ classDef assessment fill:#fff3e0,stroke:#f57c00,color:#2c3e50
+ classDef results fill:#e8f5e8,stroke:#388e3c,color:#2c3e50
+
+ class App,Components,Fingerprint identification
+ class NVD,OSV,GitHub,Commercial database
+ class CVSS,Exploitability,Reachability,Context assessment
+ class Critical,High,Medium,Low results
+```
+
+---
+
+## ๐ Slide 38 โ ๐ License Compliance Scanning & Management
+
+* ๐ **License compliance** = ensuring all third-party components comply with **legal and organizational licensing policies**
+* โ๏ธ **Common open-source license types**:
+ * ๐ **Permissive licenses**: MIT, Apache 2.0, BSD โ minimal restrictions, commercial-friendly
+ * ๐ **Copyleft licenses**: GPL v2/v3, AGPL โ require source code sharing of derivatives
+ * ๐ข **Commercial licenses**: proprietary software requiring payment or specific terms
+ * ๐ซ **Prohibited licenses**: organization-specific restrictions (e.g., AGPL banned in some companies)
+* โ ๏ธ **License compliance risks**:
+ * โ๏ธ **Legal liability**: using incompatible licenses can result in lawsuits
+ * ๐ค **Forced disclosure**: copyleft licenses may require sharing proprietary code
+ * ๐ฐ **Financial penalties**: violation of commercial license terms
+ * ๐ข **Reputation damage**: public license violations harm company credibility
+* ๐ ๏ธ **License scanning tools**:
+ * ๐ง **FOSSA**: comprehensive license compliance platform
+ * ๐ **Black Duck**: Synopsys license and security scanning
+ * ๐ **licensee**: GitHub's open-source license detection library
+ * โ๏ธ **scancode-toolkit**: open-source license and copyright scanner
+* ๐ **Compliance automation**:
+ * ๐ **Policy definition**: create organizational license policies
+ * ๐ **Automated scanning**: integrate license detection in CI/CD
+ * ๐จ **Violation alerts**: notify teams of license conflicts
+ * ๐ **Compliance reports**: generate legal documentation for audits
+* ๐ **Industry statistics**: **65% of codebases** contain license policy violations ([Synopsis OSSRA 2024](https://www.synopsys.com/software-integrity/resources/analyst-reports/open-source-security-risk-analysis-report.html))
+
+```mermaid
+flowchart LR
+ subgraph "๐ฆ Component Analysis"
+ Dependencies[๐ Project Dependencies]
+ LicenseDetection[๐ License Detection
Source Code, Metadata]
+ LicenseDB[๐๏ธ License Database
SPDX, OSI, Custom]
+ end
+
+ subgraph "๐ License Categories"
+ Permissive[๐ Permissive
MIT, Apache 2.0, BSD]
+ Copyleft[๐ Copyleft
GPL v2/v3, AGPL]
+ Commercial[๐ข Commercial
Proprietary, Paid]
+ Unknown[โ Unknown
Unidentified, Custom]
+ end
+
+ subgraph "โ๏ธ Policy Engine"
+ OrgPolicy[๐๏ธ Organizational Policy
Approved, Restricted, Banned]
+ RiskAssessment[๐ Risk Assessment
Legal, Commercial Impact]
+ ConflictDetection[โ ๏ธ Conflict Detection
License Incompatibilities]
+ end
+
+ subgraph "๐ Compliance Results"
+ Approved[โ
Approved
Policy Compliant]
+ Review[๐ฅ Manual Review
Requires Legal Input]
+ Violation[๐ซ Policy Violation
Must Remove/Replace]
+ Report[๐ Compliance Report
Legal Documentation]
+ end
+
+ Dependencies --> LicenseDetection
+ LicenseDetection --> LicenseDB
+
+ LicenseDB --> Permissive
+ LicenseDB --> Copyleft
+ LicenseDB --> Commercial
+ LicenseDB --> Unknown
+
+ Permissive --> OrgPolicy
+ Copyleft --> RiskAssessment
+ Commercial --> ConflictDetection
+ Unknown --> RiskAssessment
+
+ OrgPolicy --> Approved
+ RiskAssessment --> Review
+ ConflictDetection --> Violation
+ OrgPolicy --> Report
+
+ classDef analysis fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef categories fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+ classDef policy fill:#fff3e0,stroke:#f57c00,color:#2c3e50
+ classDef results fill:#e8f5e8,stroke:#388e3c,color:#2c3e50
+
+ class Dependencies,LicenseDetection,LicenseDB analysis
+ class Permissive,Copyleft,Commercial,Unknown categories
+ class OrgPolicy,RiskAssessment,ConflictDetection policy
+ class Approved,Review,Violation,Report results
+```
+
+---
+
+## ๐ Slide 39 โ ๐ Automated Dependency Updates & Patch Management
+
+* ๐ **Automated dependency updates** = systematic process of **keeping third-party components current** with latest security patches
+* ๐ฏ **Update automation benefits**:
+ * ๐ก๏ธ **Faster security patching**: reduce window of vulnerability exposure
+ * โฐ **Reduced manual effort**: eliminate time-consuming manual update processes
+ * ๐ฏ **Consistent updates**: ensure all projects follow same update patterns
+ * ๐ **Improved visibility**: track update status across entire organization
+* ๐ ๏ธ **Automated update tools**:
+ * ๐ค **Dependabot**: GitHub's automated dependency update service
+ * ๐ **Renovate**: comprehensive dependency update automation platform
+ * ๐ฆ **GitLab Dependency Updates**: integrated GitLab dependency management
+ * โ๏ธ **Snyk Open Source**: automated fix PRs with vulnerability context
+* โ๏ธ **Update strategies**:
+ * ๐ข **Patch updates**: automated security patches (1.2.3 โ 1.2.4)
+ * ๐ก **Minor updates**: feature updates with review (1.2.0 โ 1.3.0)
+ * ๐ด **Major updates**: breaking changes requiring manual intervention (1.x โ 2.0)
+* ๐ก๏ธ **Safety mechanisms**:
+ * ๐งช **Automated testing**: run full test suite before accepting updates
+ * ๐ฏ **Staged rollouts**: deploy to staging before production
+ * ๐ **Rollback procedures**: quick reversion if updates cause issues
+ * ๐ฅ **Review requirements**: human approval for high-risk updates
+* ๐ **Industry challenge**: **75% of vulnerabilities** remain unpatched 30 days after disclosure ([Veracode Fixing the Enterprise](https://www.veracode.com/resource/report/fixing-the-enterprise))
+
+```mermaid
+flowchart TD
+ subgraph "๐ Vulnerability Detection"
+ CVEMonitor[๐จ CVE Monitoring
New Vulnerabilities]
+ Scanner[๐ Dependency Scanner
Current Components]
+ RiskAssess[๐ Risk Assessment
CVSS + Context]
+ end
+
+ subgraph "๐ค Update Automation"
+ UpdateBot[๐ค Update Bot
Dependabot, Renovate]
+ VersionAnalysis[๐ Version Analysis
Patch, Minor, Major]
+ PRCreation[๐ Pull Request Creation
Automated Updates]
+ end
+
+ subgraph "๐ก๏ธ Safety Checks"
+ AutoTests[๐งช Automated Tests
Unit, Integration, Security]
+ PolicyCheck[๐ Policy Validation
License, Security Rules]
+ StagingDeploy[๐ญ Staging Deployment
Real-world Testing]
+ end
+
+ subgraph "๐ Deployment Decision"
+ LowRisk[๐ข Low Risk
Auto-merge Patches]
+ MediumRisk[๐ก Medium Risk
Review Required]
+ HighRisk[๐ด High Risk
Manual Testing]
+ Emergency[๐จ Emergency
Critical Security]
+ end
+
+ CVEMonitor --> Scanner
+ Scanner --> RiskAssess
+ RiskAssess --> UpdateBot
+
+ UpdateBot --> VersionAnalysis
+ VersionAnalysis --> PRCreation
+ PRCreation --> AutoTests
+
+ AutoTests --> PolicyCheck
+ PolicyCheck --> StagingDeploy
+
+ StagingDeploy --> LowRisk
+ StagingDeploy --> MediumRisk
+ StagingDeploy --> HighRisk
+ RiskAssess --> Emergency
+
+ classDef detection fill:#e3f2fd,stroke:#1976d2,color:#2c3e50
+ classDef automation fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+ classDef safety fill:#fff3e0,stroke:#f57c00,color:#2c3e50
+ classDef decision fill:#e8f5e8,stroke:#388e3c,color:#2c3e50
+
+ class CVEMonitor,Scanner,RiskAssess detection
+ class UpdateBot,VersionAnalysis,PRCreation automation
+ class AutoTests,PolicyCheck,StagingDeploy safety
+ class LowRisk,MediumRisk,HighRisk,Emergency decision
+```
+
+---
+
+## ๐ Slide 40 โ ๐ธ๏ธ Dependency Confusion & Typosquatting Prevention
+
+* ๐ธ๏ธ **Dependency confusion** = attack where malicious packages with **higher version numbers** are published to **public repositories** with same names as **internal packages**
+* ๐ฏ **Typosquatting** = creating malicious packages with **similar names** to popular legitimate packages (e.g., "reqeusts" instead of "requests")
+* โ ๏ธ **Attack mechanisms**:
+ * ๐ฆ **Public package priority**: package managers often prefer public repositories over private ones
+ * ๐ข **Version precedence**: higher version numbers automatically selected
+ * ๐ค **Name similarity**: developers mistype package names in dependencies
+ * ๐ค **Automated scanning**: attackers monitor internal package names from public repositories
+* ๐ก๏ธ **Prevention strategies**:
+ * ๐๏ธ **Package scoping**: use organizational scopes (@company/package-name)
+ * ๐ **Repository prioritization**: configure package managers to prefer private repositories
+ * ๐ซ **Public repository blocking**: prevent accidental public package installation
+ * ๐ **Dependency pinning**: lock specific versions and sources in lockfiles
+ * ๐ **Monitoring & alerting**: detect unauthorized package installations
+* ๐ ๏ธ **Technical mitigations**:
+ * ๐ฆ **npm**: use .npmrc with registry configuration and scoped packages
+ * ๐ **Python**: configure pip.conf with trusted hosts and index priorities
+ * โ **Maven**: settings.xml with repository mirroring and blocking
+ * ๐ท **NuGet**: NuGet.Config with package source mapping
+* ๐ **Real-world impact**: **130+ malicious packages** discovered in npm registry targeting dependency confusion in 2023 ([ReversingLabs Research](https://www.reversinglabs.com/blog))
+
+```mermaid
+flowchart TD
+ subgraph "๐ Attack Scenarios"
+ Confusion[๐ธ๏ธ Dependency Confusion
internal-pkg v1.0 โ malicious-pkg v2.0]
+ Typosquat[๐ค Typosquatting
lodash โ lodahs, reqeusts]
+ AutoScan[๐ค Automated Scanning
Monitor for internal names]
+ end
+
+ subgraph "๐ฆ Package Repositories"
+ Private[๐ Private Repository
internal-package v1.0]
+ Public[๐ Public Repository
npm, PyPI, Maven Central]
+ Malicious[โ ๏ธ Malicious Packages
Higher versions, Similar names]
+ end
+
+ subgraph "๐ก๏ธ Prevention Controls"
+ Scoping[๐๏ธ Package Scoping
@company/package-name]
+ RepoConfig[โ๏ธ Repository Configuration
Private first, blocked public]
+ Pinning[๐ Version Pinning
Exact versions, checksums]
+ Monitoring[๐ Package Monitoring
Unauthorized installation alerts]
+ end
+
+ subgraph "๐ง Technical Implementation"
+ NPM[๐ฆ npm: .npmrc config
Registry priority, scoping]
+ Python[๐ Python: pip.conf
Trusted hosts, index order]
+ Maven[โ Maven: settings.xml
Repository mirroring]
+ NuGet[๐ท NuGet: NuGet.Config
Package source mapping]
+ end
+
+ Confusion --> Public
+ Typosquat --> Malicious
+ AutoScan --> Malicious
+
+ Private --> Scoping
+ Public --> RepoConfig
+ Malicious --> Pinning
+
+ Scoping --> NPM
+ RepoConfig --> Python
+ Pinning --> Maven
+ Monitoring --> NuGet
+
+ classDef attack fill:#ffebee,stroke:#d32f2f,color:#2c3e50
+ classDef repository fill:#f3e5f5,stroke:#7b1fa2,color:#2c3e50
+ classDef prevention fill:#fff3e0,stroke:#f57c00,color:#2c3e50
+ classDef implementation fill:#e8f5e8,stroke:#388e3c,color:#2c3e50
+
+ class Confusion,Typosquat,AutoScan attack
+ class Private,Public,Malicious repository
+ class Scoping,RepoConfig,Pinning,Monitoring prevention
+ class NPM,Python,Maven,NuGet implementation
+```
+
+---
+
+---
diff --git a/lectures/lec5.md b/lectures/lec5.md
new file mode 100644
index 00000000..3c7e91c1
--- /dev/null
+++ b/lectures/lec5.md
@@ -0,0 +1,1713 @@
+# ๐Lecture 5 - Application Security Testing Basics: SAST, DAST, IAST & Pipeline Integration
+
+## ๐ Group 1: Application Security Testing Foundations
+
+## ๐ Slide 1 โ ๐ What is Application Security Testing? (AST Overview)
+
+* ๐ **Application Security Testing (AST)** = systematic evaluation of software applications to **identify security vulnerabilities** before they reach production.
+* ๐ฏ **Core purpose**: find and fix security flaws **early and automatically** in the development process.
+* ๐ **Three main approaches**:
+ * ๐ฌ **Testing**: examining code/application behavior for known vulnerability patterns
+ * ๐ก **Scanning**: automated tools checking for security misconfigurations
+ * ๐ง **Analysis**: deep inspection of code logic and data flows
+* ๐ **Industry adoption**: **91% of organizations** now use automated security testing tools in development ([DevSecOps Survey 2024](https://www.devsecops.org/))
+* ๐ฐ **Business impact**: fixing vulnerabilities in development costs **100x less** than fixing in production ([NIST Study](https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf))
+* ๐ **Learn more**: [OWASP Application Security Testing Guide](https://owasp.org/www-project-web-security-testing-guide/)
+
+```mermaid
+flowchart LR
+ Dev[๐จโ๐ป Developer Code] --> AST[๐ Application Security Testing]
+ AST --> SAST[๐ฌ Static Analysis]
+ AST --> DAST[๐ Dynamic Testing]
+ AST --> IAST[๐งฌ Interactive Testing]
+ SAST --> Results[๐ Security Findings]
+ DAST --> Results
+ IAST --> Results
+ Results --> Fix[๐ง Fix Vulnerabilities]
+
+ classDef default fill:#f9f9f9,stroke:#333,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+## ๐ Slide 2 โ ๐ Evolution of Application Security Testing
+
+* ๐
**1990s-2000s**: **Manual code reviews** by security experts โ slow, expensive, inconsistent coverage.
+* ๐
**2005-2010**: **First SAST tools** emerge โ Fortify (2003), Veracode (2006) โ automated source code analysis.
+* ๐
**2010-2015**: **DAST tools mature** โ OWASP ZAP (2010), commercial web app scanners proliferate.
+* ๐
**2015-2020**: **DevSecOps integration** โ CI/CD pipeline integration, shift-left movement accelerates.
+* ๐
**2020-Present**: **AI-powered analysis** โ machine learning reduces false positives, cloud-native testing emerges.
+* ๐ **Market growth**: AST market grew from **$2.1B in 2019** to **$8.2B in 2024** ([Gartner Security Report](https://www.gartner.com/en/information-technology/insights/application-security))
+* ๐ **Next frontier**: **Real-time security feedback** in IDEs, AI-assisted vulnerability remediation, quantum-safe crypto testing.
+
+```mermaid
+timeline
+ title ๐ Evolution of Application Security Testing
+ 1990s : ๐ Manual Code Reviews
+ : Security experts only
+ 2005 : ๐ฌ First SAST Tools
+ : Fortify, Veracode launch
+ 2010 : ๐ DAST Tools Mature
+ : OWASP ZAP, web scanners
+ 2015 : ๐ DevSecOps Integration
+ : CI/CD pipeline adoption
+ 2020 : ๐ค AI-Powered Analysis
+ : ML reduces false positives
+ 2025 : ๐ง Next-Gen Testing
+ : Real-time IDE integration
+```
+
+---
+
+## ๐ Slide 3 โ ๐ฏ Types of Security Vulnerabilities We're Testing For
+
+* ๐งฉ **OWASP Top 10 vulnerabilities** โ primary targets for AST tools:
+ * ๐ **Injection flaws**: SQL injection, command injection, LDAP injection
+ * ๐ **Broken authentication**: weak passwords, session hijacking, credential stuffing
+ * ๐ค **Sensitive data exposure**: unencrypted data, weak crypto, information leakage
+ * ๐ง **Security misconfigurations**: default credentials, unnecessary services, verbose errors
+* ๐๏ธ **Code-level vulnerabilities**: buffer overflows, race conditions, insecure randomness
+* โก **Runtime vulnerabilities**: memory corruption, privilege escalation, resource exhaustion
+* ๐ ๏ธ **Configuration issues**: cloud misconfigurations, container security, infrastructure-as-code flaws
+* ๐ **Business logic flaws**: authorization bypasses, workflow manipulation, price manipulation
+* ๐ **Vulnerability databases**: [CVE Details](https://www.cvedetails.com/), [CWE List](https://cwe.mitre.org/), [OWASP Top 10](https://owasp.org/www-project-top-ten/)
+
+```mermaid
+flowchart TD
+ subgraph "๐ฏ Vulnerability Categories"
+ OWASP[๐ OWASP Top 10
Web App Vulnerabilities]
+ Code[๐ฌ Code-Level Issues
Memory, Logic Flaws]
+ Runtime[โก Runtime Issues
Execution, Performance]
+ Config[๐ ๏ธ Configuration
Cloud, Container, IaC]
+ Business[๐ Business Logic
Workflow, Authorization]
+ end
+
+ subgraph "๐ Testing Approaches"
+ SAST[๐ฌ SAST
Finds Code Issues]
+ DAST[๐ DAST
Finds Runtime Issues]
+ IAST[๐งฌ IAST
Finds Both Types]
+ Manual[๐ค Manual Testing
Finds Business Logic]
+ end
+
+ Code --> SAST
+ Runtime --> DAST
+ OWASP --> DAST
+ Config --> SAST
+ Business --> Manual
+ OWASP --> IAST
+
+ classDef default fill:#f9f9f9,stroke:#333,stroke-width:2px,color:#2c3e50
+ classDef testing fill:#e8f5e8,stroke:#2e7d32,stroke-width:2px,color:#2c3e50
+ class SAST,DAST,IAST,Manual testing
+```
+
+---
+
+## ๐ Slide 4 โ โ๏ธ Static vs. Dynamic vs. Interactive Testing Comparison
+
+* ๐ฌ **SAST (Static Application Security Testing)**:
+ * โ
**Pros**: early detection, complete code coverage, fast feedback, no running app needed
+ * โ **Cons**: false positives, missing runtime context, configuration blind spots
+ * ๐ฏ **Best for**: injection flaws, hardcoded secrets, coding standard violations
+* ๐ **DAST (Dynamic Application Security Testing)**:
+ * โ
**Pros**: real runtime conditions, finds configuration issues, business logic testing
+ * โ **Cons**: late-stage detection, limited code coverage, requires running application
+ * ๐ฏ **Best for**: authentication bypasses, session management, server misconfigurations
+* ๐งฌ **IAST (Interactive Application Security Testing)**:
+ * โ
**Pros**: combines SAST + DAST benefits, low false positives, precise vulnerability location
+ * โ **Cons**: performance overhead, deployment complexity, limited language support
+ * ๐ฏ **Best for**: comprehensive analysis during QA testing, runtime vulnerability validation
+* ๐ **Industry usage**: **67% use SAST**, **52% use DAST**, **23% use IAST** ([Synopsys DevSecOps Report 2024](https://www.synopsys.com/software-integrity/resources/analyst-reports/devsecops-report.html))
+
+```mermaid
+flowchart TD
+ subgraph "๐ฌ SAST - White Box"
+ SASTTime[โฐ Development Phase]
+ SASTCode[๐ Source Code Analysis]
+ SASTCover[๐ 100% Code Coverage]
+ SASTFast[โก Fast Execution]
+ end
+
+ subgraph "๐ DAST - Black Box"
+ DASTTime[โฐ Testing/Production Phase]
+ DASTApp[๐ฅ๏ธ Running Application]
+ DASTReal[๐ Real Conditions]
+ DASTSlow[๐ Slower Execution]
+ end
+
+ subgraph "๐งฌ IAST - Gray Box"
+ IASTTime[โฐ QA Testing Phase]
+ IASTInstr[๐ง Instrumented Application]
+ IASTBoth[๐ฏ Code + Runtime Analysis]
+ IASTPerf[๐ Performance Impact]
+ end
+
+ classDef sast fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef dast fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ classDef iast fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+
+ class SASTTime,SASTCode,SASTCover,SASTFast sast
+ class DASTTime,DASTApp,DASTReal,DASTSlow dast
+ class IASTTime,IASTInstr,IASTBoth,IASTPerf iast
+```
+
+---
+
+## ๐ Slide 5 โ ๐งฉ The Testing Pyramid for Application Security
+
+* ๐บ **Security Testing Pyramid** โ layered approach to comprehensive application security validation:
+ * ๐๏ธ **Base Layer**: **Unit Security Tests** โ test individual functions for security flaws (80% of tests)
+ * ๐ **Middle Layer**: **Integration Security Tests** โ test API endpoints, service interactions (15% of tests)
+ * ๐ **Top Layer**: **End-to-End Security Tests** โ full application workflow testing (4% of tests)
+ * ๐ค **Apex**: **Manual Penetration Testing** โ expert human testing for complex business logic (1% of effort)
+* โก **Pyramid principle**: **more tests at the bottom** = faster feedback, lower cost, better coverage
+* ๐ ๏ธ **Tool mapping**:
+ * ๐๏ธ **Unit level**: SAST tools, secure coding linters, dependency scanners
+ * ๐ **Integration level**: API security testing, DAST for services, IAST during integration tests
+ * ๐ **E2E level**: Full DAST scans, automated penetration testing tools
+ * ๐ค **Manual level**: Expert penetration testing, business logic review
+* ๐ **Cost efficiency**: unit tests cost **$1 to fix**, production fixes cost **$100+** ([IBM Systems Sciences Institute](https://www.ibm.com/garage/method/practices/code/tool_continuous_integration/))
+
+```mermaid
+graph TD
+ subgraph "๐งฉ Application Security Testing Pyramid"
+ Manual[๐ค Manual Penetration Testing
๐ฏ Business Logic, Complex Scenarios
๐ฐ High Cost, 1% Effort]
+ E2E[๐ End-to-End Security Tests
๐ Full Application Workflows
๐ฐ Medium-High Cost, 4% Effort]
+ Integration[๐ Integration Security Tests
๐ API, Service Interactions
๐ฐ Medium Cost, 15% Effort]
+ Unit[๐๏ธ Unit Security Tests
๐ฌ Individual Functions, Components
๐ฐ Low Cost, 80% Effort]
+ end
+
+ subgraph "๐ ๏ธ Tool Mapping"
+ ManualTools[๐ต๏ธ Expert Testers
๐ง Human Intelligence]
+ E2ETools[๐ DAST Full Scans
๐ค Automated Pen Testing]
+ IntTools[๐ API Security Testing
๐งฌ IAST during Integration]
+ UnitTools[๐ฌ SAST, Linters
๐ฆ Dependency Scanning]
+ end
+
+ Manual --> ManualTools
+ E2E --> E2ETools
+ Integration --> IntTools
+ Unit --> UnitTools
+
+ classDef pyramid fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+ classDef tools fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ classDef unit fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+
+ class Manual,E2E,Integration,Unit pyramid
+ class ManualTools,E2ETools,IntTools,UnitTools tools
+ class Unit unit
+```
+
+* ๐ **Learn more**: [Google Testing Blog - Test Pyramid](https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html), [Martin Fowler - Test Pyramid](https://martinfowler.com/articles/practical-test-pyramid.html)
+
+---
+
+## ๐ **Fun Break: Security Testing Memes & Facts**
+
+### ๐ **"Why Security Testing is Like Going to the Dentist"**
+* ๐ฆท **Nobody wants to do it** โ but everyone knows they should
+* ๐ฌ **It hurts more when you wait** โ early testing = less painful fixes
+* ๐ **Prevention is better than cure** โ regular checkups prevent major issues
+* ๐ฐ **Ignoring it gets expensive fast** โ root canals are way more expensive than cleanings!
+
+### ๐คฏ **Mind-Blowing Security Testing Facts:**
+* ๐ **Speed demon**: Modern SAST tools can analyze **1 million lines of code in under 5 minutes**
+* ๐ **False alarm city**: Average SAST tool generates **30-40% false positives** (that's why we need humans!)
+* ๐ **Bug economics**: Average cost to fix a security bug jumps from **$80 in development** to **$7,600 in production**
+* ๐ค **AI revolution**: **GitHub Copilot** now suggests **secure code patterns** in real-time as you type!
+
+### ๐ญ **Interactive Question for Students:**
+**๐ค "If you could only choose ONE type of security testing (SAST, DAST, or IAST) for your startup's web application, which would you pick and why?"**
+
+*Think about: budget constraints, team size, application type, and risk tolerance...*
+
+---
+## ๐ Group 2: Static Application Security Testing (SAST)
+
+## ๐ Slide 6 โ ๐ฌ Deep Dive into SAST: Definition and Core Concepts
+
+* ๐ฌ **SAST = Static Application Security Testing** โ automated analysis of **source code** without executing the application.
+* ๐ง **Core principle**: examine code structure, data flows, and patterns to **identify potential vulnerabilities** before runtime.
+* ๐ณ **How SAST works**:
+ * ๐ **Lexical analysis**: breaks source code into tokens and symbols
+ * ๐ฒ **Abstract Syntax Tree (AST)**: creates hierarchical code structure representation
+ * ๐ **Data flow analysis**: tracks how data moves through the application
+ * ๐ฏ **Pattern matching**: compares code patterns against vulnerability databases
+* โก **Analysis types**:
+ * ๐ **Syntactic analysis**: looks for dangerous function calls, hardcoded secrets
+ * ๐งฎ **Semantic analysis**: understands code meaning and context
+ * ๐ **Taint analysis**: tracks untrusted data from input to dangerous operations
+* ๐ **Language support**: **Java, C#, JavaScript, Python, C/C++, PHP, Go, Swift** and 50+ languages
+* ๐ **Learn more**: [NIST SAST Guide](https://csrc.nist.gov/Projects/Static-Analysis-Tool-Exposition), [OWASP SAST Overview](https://owasp.org/www-community/Source_Code_Analysis_Tools)
+
+```mermaid
+flowchart TD
+ subgraph "๐ฌ SAST Analysis Process"
+ Source[๐ Source Code
Raw Application Code]
+ Lexer[๐ค Lexical Analysis
Tokenization]
+ Parser[๐ฒ Syntax Analysis
AST Generation]
+ DataFlow[๐ Data Flow Analysis
Variable Tracking]
+ PatternMatch[๐ฏ Pattern Matching
Vulnerability Detection]
+ Report[๐ Security Report
Findings & Recommendations]
+ end
+
+ Source --> Lexer
+ Lexer --> Parser
+ Parser --> DataFlow
+ DataFlow --> PatternMatch
+ PatternMatch --> Report
+
+ subgraph "๐ฏ What SAST Finds"
+ SQLi[๐ SQL Injection]
+ XSS[๐ Cross-Site Scripting]
+ Secrets[๐ Hardcoded Secrets]
+ BufferOverflow[๐ฅ Buffer Overflows]
+ RaceConditions[๐โโ๏ธ Race Conditions]
+ end
+
+ PatternMatch --> SQLi
+ PatternMatch --> XSS
+ PatternMatch --> Secrets
+ PatternMatch --> BufferOverflow
+ PatternMatch --> RaceConditions
+
+ classDef process fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef findings fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+
+ class Source,Lexer,Parser,DataFlow,PatternMatch,Report process
+ class SQLi,XSS,Secrets,BufferOverflow,RaceConditions findings
+```
+
+---
+
+## ๐ Slide 7 โ ๐ ๏ธ Popular SAST Tools and Platform Overview
+
+* ๐ข **Commercial Enterprise SAST Tools**:
+ * ๐ก๏ธ **Veracode Static Analysis**: cloud-native, **150+ languages**, IDE plugins, policy management
+ * โ
**Checkmarx SAST**: **31 languages**, incremental scanning, custom rules, **$50-200 per developer/year**
+ * ๐ **Synopsys Coverity**: **C/C++ excellence**, automotive compliance, **complex dataflow analysis**
+ * ๐ฐ **Micro Focus Fortify**: **enterprise-grade**, audit workbench, regulatory compliance
+* ๐ **Open Source SAST Tools**:
+ * ๐ **SonarQube**: **29 languages**, quality gates, technical debt tracking, **free community edition**
+ * โก **Semgrep**: **fast pattern-based**, custom rules, **30+ languages**, CLI and cloud versions
+ * ๐ **Bandit (Python)**: specialized Python security linter, PCI DSS compliance
+ * ๐ฑ **MobSF**: mobile application security testing for Android/iOS
+* โ๏ธ **Cloud-Native SAST Solutions**:
+ * ๐ **GitHub Advanced Security**: native GitHub integration, **CodeQL engine**, automatic PR scanning
+ * โก **AWS CodeGuru Reviewer**: machine learning-powered, Java/Python focus, pay-per-review model
+ * ๐ต **Azure Security Center**: integrated DevOps workflows, compliance dashboards
+* ๐ **Market leaders**: **Veracode (23% market share)**, **Checkmarx (19%)**, **Synopsys (16%)** ([Gartner Magic Quadrant 2024](https://www.gartner.com/en/documents/4018395))
+
+```mermaid
+flowchart TD
+ subgraph "๐ข Commercial Enterprise"
+ Veracode[๐ก๏ธ Veracode
๐ Cloud-native, 150+ languages]
+ Checkmarx[โ
Checkmarx
๐ฐ $50-200/dev/year]
+ Coverity[๐ Synopsys Coverity
๐ Automotive compliance]
+ Fortify[๐ฐ Micro Focus Fortify
๐ Enterprise audit]
+ end
+
+ subgraph "๐ Open Source"
+ SonarQube[๐ SonarQube
๐ Quality gates, 29 languages]
+ Semgrep[โก Semgrep
๐ฏ Pattern-based, custom rules]
+ Bandit[๐ Bandit
๐ Python security specialist]
+ MobSF[๐ฑ MobSF
๐ฒ Mobile app security]
+ end
+
+ subgraph "โ๏ธ Cloud-Native"
+ GitHub[๐ GitHub Advanced Security
๐ CodeQL engine]
+ CodeGuru[โก AWS CodeGuru
๐ค ML-powered analysis]
+ Azure[๐ต Azure Security Center
๐ DevOps integration]
+ end
+
+ subgraph "๐ฏ Selection Criteria"
+ Language[๐ป Language Support]
+ Integration[๐ CI/CD Integration]
+ Cost[๐ฐ Total Cost of Ownership]
+ Accuracy[๐ฏ False Positive Rate]
+ Scalability[๐ Enterprise Scalability]
+ end
+
+ Veracode -.-> Language
+ SonarQube -.-> Integration
+ GitHub -.-> Cost
+ Checkmarx -.-> Accuracy
+ Coverity -.-> Scalability
+
+ classDef commercial fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ classDef opensource fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ classDef cloud fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef criteria fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+
+ class Veracode,Checkmarx,Coverity,Fortify commercial
+ class SonarQube,Semgrep,Bandit,MobSF opensource
+ class GitHub,CodeGuru,Azure cloud
+ class Language,Integration,Cost,Accuracy,Scalability criteria
+```
+
+---
+
+## ๐ Slide 8 โ โก SAST Strengths and Limitations
+
+* โ
**SAST Superpowers**:
+ * ๐โโ๏ธ **Early detection**: finds vulnerabilities **during development** โ cheapest to fix
+ * ๐ **Complete coverage**: analyzes **100% of code paths** including rarely executed branches
+ * โก **Fast feedback**: results in **minutes to hours** vs. days for manual review
+ * ๐ซ **No runtime required**: works with **incomplete applications** and third-party libraries
+ * ๐ **Compliance friendly**: generates detailed reports for **audit trails** (SOX, PCI-DSS)
+ * ๐ฏ **Precise location**: points to **exact line of code** with vulnerability
+* โ **SAST Limitations**:
+ * ๐จ **False positive plague**: **30-40% false positive rate** โ developer fatigue and tool abandonment
+ * ๐ **Missing runtime context**: can't detect **configuration issues** or **environment-specific** problems
+ * ๐งฉ **Complex business logic**: struggles with **multi-step workflows** and **authorization logic**
+ * ๐ **Language constraints**: **compiled languages work better** than interpreted (JavaScript challenges)
+ * ๐ง **Integration complexity**: requires **build environment setup** and **dependency resolution**
+* ๐ **Industry reality**: **67% of developers** report SAST false positives as biggest adoption barrier ([DevSecOps Community Survey 2024](https://www.devsecops.org/))
+
+```mermaid
+graph TD
+ subgraph "โ
SAST Strengths"
+ Early[๐โโ๏ธ Early Detection
Development Phase]
+ Coverage[๐ Complete Coverage
100% Code Paths]
+ Fast[โก Fast Feedback
Minutes to Hours]
+ NoRuntime[๐ซ No Runtime Needed
Works on Incomplete Apps]
+ Compliance[๐ Compliance Reports
Audit Trails]
+ Precise[๐ฏ Precise Location
Exact Line Numbers]
+ end
+
+ subgraph "โ SAST Limitations"
+ FalsePos[๐จ False Positives
30-40% Rate]
+ NoContext[๐ No Runtime Context
Config Issues Missed]
+ BusinessLogic[๐งฉ Complex Logic
Workflow Blind Spots]
+ Language[๐ Language Issues
Interpreted Language Challenges]
+ Integration[๐ง Integration Complexity
Build Dependencies]
+ end
+
+ subgraph "๐ก Mitigation Strategies"
+ Tuning[๐๏ธ Rule Tuning
Reduce False Positives]
+ Training[๐ Developer Training
Understanding Results]
+ Gradual[๐ Gradual Rollout
Incremental Adoption]
+ Hybrid[๐ Hybrid Approach
SAST + DAST + IAST]
+ end
+
+ FalsePos --> Tuning
+ NoContext --> Hybrid
+ BusinessLogic --> Hybrid
+ Integration --> Training
+ Language --> Gradual
+
+ classDef strength fill:#e8f5e8,stroke:#2e7d32,stroke-width:2px,color:#2c3e50
+ classDef limitation fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ classDef mitigation fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+
+ class Early,Coverage,Fast,NoRuntime,Compliance,Precise strength
+ class FalsePos,NoContext,BusinessLogic,Language,Integration limitation
+ class Tuning,Training,Gradual,Hybrid mitigation
+```
+
+---
+
+## ๐ Slide 9 โ ๐ฏ SAST Implementation Best Practices
+
+* ๐ฏ **Successful SAST Deployment Strategy**:
+ * ๐ **Start small**: begin with **high-risk applications** and **critical security rules**
+ * ๐๏ธ **Tune relentlessly**: spend **first 30 days** reducing false positives to **<10%**
+ * ๐ฅ **Train developers**: provide **hands-on training** on interpreting and fixing findings
+ * ๐ **Measure everything**: track **time-to-fix**, **developer adoption**, **vulnerability trends**
+* ๐ **IDE Integration Best Practices**:
+ * ๐ป **Real-time feedback**: integrate with **VS Code**, **IntelliJ**, **Eclipse** for instant alerts
+ * ๐โโ๏ธ **Incremental scanning**: scan only **changed files** to maintain developer flow
+ * ๐จ **Custom highlighting**: use **different colors** for different severity levels
+ * ๐ **Noise reduction**: allow developers to **suppress false positives** with justification
+* ๐ **CI/CD Pipeline Integration**:
+ * โ๏ธ **Quality gates**: **fail builds** only on **high/critical** vulnerabilities initially
+ * ๐ **Trend analysis**: track vulnerability **introduction** and **fix rates** over time
+ * ๐ง **Smart notifications**: alert only **code authors** and **security champions**
+ * ๐ **Automated triage**: use **ML models** to **pre-classify** likely false positives
+* ๐ก **Developer Adoption Secrets**: **gamification** (vulnerability fix leaderboards), **positive reinforcement** (celebrate security improvements), **just-in-time training** (context-aware learning)
+
+```mermaid
+flowchart LR
+ subgraph "๐ฏ Implementation Journey"
+ Plan[๐ Planning Phase
Tool selection, pilot scope]
+ Deploy[๐ Deployment Phase
Integration, configuration]
+ Tune[๐๏ธ Tuning Phase
False positive reduction]
+ Scale[๐ Scaling Phase
Organization-wide rollout]
+ Optimize[โ๏ธ Optimization Phase
Continuous improvement]
+ end
+
+ subgraph "๐ Integration Points"
+ IDE[๐ป IDE Integration
Real-time feedback]
+ PreCommit[๐ Pre-commit Hooks
Local scanning]
+ CI[๐๏ธ CI/CD Pipeline
Automated scanning]
+ Dashboard[๐ Security Dashboard
Centralized reporting]
+ end
+
+ subgraph "๐ Success Metrics"
+ MTTR[โฑ๏ธ Mean Time to Remediate
Target: <7 days]
+ Adoption[๐ฅ Developer Adoption Rate
Target: >80%]
+ FalsePos[๐ฏ False Positive Rate
Target: <10%]
+ Coverage[๐ Code Coverage
Target: >90%]
+ end
+
+ Plan --> Deploy --> Tune --> Scale --> Optimize
+
+ Deploy --> IDE
+ Tune --> PreCommit
+ Scale --> CI
+ Optimize --> Dashboard
+
+ Tune --> FalsePos
+ Scale --> Adoption
+ Optimize --> MTTR
+ Deploy --> Coverage
+
+ classDef phase fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ classDef integration fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef metrics fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+
+ class Plan,Deploy,Tune,Scale,Optimize phase
+ class IDE,PreCommit,CI,Dashboard integration
+ class MTTR,Adoption,FalsePos,Coverage metrics
+```
+
+---
+
+## ๐ Slide 10 โ ๐ง Hands-on SAST: Tool Configuration and Output Analysis
+
+* ๐ง **SonarQube Setup Example** (Free Community Edition):
+ * ๐ณ **Docker deployment**: `docker run -d -p 9000:9000 sonarqube:lts-community`
+ * โ๏ธ **Project configuration**: create `sonar-project.properties` with language settings
+ * ๐ **Scan execution**: `sonar-scanner` analyzes code and uploads results
+ * ๐ **Quality gate**: define **pass/fail criteria** for builds
+* ๐ **Understanding SAST Output**:
+ * ๐ด **Blocker**: **security vulnerabilities** โ immediate fix required
+ * ๐ **Critical**: **major bugs** โ fix before release
+ * ๐ก **Major**: **maintainability issues** โ address in sprint
+ * ๐ต **Minor**: **code smells** โ technical debt cleanup
+ * โช **Info**: **suggestions** โ optional improvements
+* ๐ ๏ธ **Sample Vulnerability Fix Workflow**:
+ * ๐ **Identify**: SQL injection in user login function
+ * ๐ **Understand**: review SAST explanation and code context
+ * ๐ง **Fix**: replace string concatenation with parameterized query
+ * โ
**Verify**: re-run SAST scan to confirm resolution
+ * ๐ **Learn**: document pattern for team knowledge base
+
+```mermaid
+flowchart TD
+ subgraph "๐ง SonarQube Analysis Flow"
+ Code[๐ Source Code
Java/Python/JS Project]
+ Config[โ๏ธ sonar-project.properties
Language & Rule Configuration]
+ Scanner[๐ sonar-scanner
Static Analysis Execution]
+ Upload[๐ค Results Upload
SonarQube Server]
+ Dashboard[๐ SonarQube Dashboard
Vulnerability Report]
+ end
+
+ subgraph "๐ SAST Output Analysis"
+ Blocker[๐ด Blocker Issues
Security Vulnerabilities]
+ Critical[๐ Critical Issues
Major Bugs]
+ Major[๐ก Major Issues
Maintainability]
+ Minor[๐ต Minor Issues
Code Smells]
+ Info[โช Info
Suggestions]
+ end
+
+ subgraph "๐ ๏ธ Fix Workflow Example"
+ SQLInjection[๐ SQL Injection Found
Line 42: String concatenation]
+ Analysis[๐ Vulnerability Analysis
User input โ SQL query]
+ FixCode[๐ง Apply Fix
Parameterized query]
+ Verify[โ
Verification
Re-scan for confirmation]
+ Document[๐ Document Pattern
Team knowledge base]
+ end
+
+ Code --> Config --> Scanner --> Upload --> Dashboard
+
+ Dashboard --> Blocker
+ Dashboard --> Critical
+ Dashboard --> Major
+ Dashboard --> Minor
+ Dashboard --> Info
+
+ Blocker --> SQLInjection
+ SQLInjection --> Analysis --> FixCode --> Verify --> Document
+
+ classDef flow fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef severity fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ classDef fix fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+
+ class Code,Config,Scanner,Upload,Dashboard flow
+ class Blocker,Critical,Major,Minor,Info severity
+ class SQLInjection,Analysis,FixCode,Verify,Document fix
+```
+
+---
+
+## ๐ Group 3: Dynamic Application Security Testing (DAST)
+
+## ๐ Slide 11 โ ๐ Deep Dive into DAST: Black-box Runtime Testing
+
+* ๐ **DAST = Dynamic Application Security Testing** โ automated security testing of **running applications** without access to source code.
+* ๐ต๏ธ **Black-box approach**: tests application **from external perspective** like a real attacker would.
+* ๐ **How DAST works**:
+ * ๐ท๏ธ **Web crawling**: automatically discovers **application pages and endpoints**
+ * ๐ฏ **Attack simulation**: sends **malicious payloads** to input fields and parameters
+ * ๐ **Response analysis**: examines **HTTP responses** for vulnerability indicators
+ * ๐ **Vulnerability confirmation**: validates findings with **exploit proof-of-concept**
+* ๐งฉ **DAST Testing Types**:
+ * ๐ **Web application scanning**: traditional website and web app testing
+ * ๐ **API testing**: REST/GraphQL/SOAP endpoint security validation
+ * ๐ฑ **Mobile app testing**: iOS/Android application security assessment
+ * โ๏ธ **Cloud configuration**: serverless functions and cloud service testing
+* โฐ **Testing phases**: typically runs during **QA/staging** or **pre-production** phases
+* ๐ **Learn more**: [OWASP DAST Guide](https://owasp.org/www-community/Vulnerability_Scanning_Tools), [NIST Application Security Testing](https://csrc.nist.gov/projects/application-security)
+
+```mermaid
+flowchart LR
+ subgraph "๐ DAST Testing Process"
+ RunningApp[๐ฅ๏ธ Running Application
Web/API/Mobile]
+ Crawler[๐ท๏ธ Web Crawler
Endpoint Discovery]
+ AttackEngine[โ๏ธ Attack Engine
Payload Generation]
+ ResponseAnalysis[๐ Response Analysis
Vulnerability Detection]
+ Validation[โ
Exploit Validation
Proof-of-Concept]
+ Report[๐ DAST Report
Confirmed Vulnerabilities]
+ end
+
+ subgraph "๐ฏ DAST Targets"
+ WebApps[๐ Web Applications
HTML Forms, JavaScript]
+ APIs[๐ APIs
REST, GraphQL, SOAP]
+ MobileApps[๐ฑ Mobile Apps
iOS, Android]
+ CloudServices[โ๏ธ Cloud Services
Serverless, Containers]
+ end
+
+ subgraph "โ๏ธ Attack Categories"
+ Injection[๐ Injection Attacks
SQL, XSS, Command]
+ AuthBypass[๐ Auth Bypass
Session, Access Control]
+ ConfigIssues[๐ ๏ธ Configuration
Server, Security Headers]
+ BusinessLogic[๐งฉ Business Logic
Workflow Manipulation]
+ end
+
+ RunningApp --> Crawler --> AttackEngine --> ResponseAnalysis --> Validation --> Report
+
+ Crawler --> WebApps
+ Crawler --> APIs
+ AttackEngine --> MobileApps
+ ResponseAnalysis --> CloudServices
+
+ AttackEngine --> Injection
+ AttackEngine --> AuthBypass
+ ResponseAnalysis --> ConfigIssues
+ Validation --> BusinessLogic
+
+ classDef process fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef targets fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ classDef attacks fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+
+ class RunningApp,Crawler,AttackEngine,ResponseAnalysis,Validation,Report process
+ class WebApps,APIs,MobileApps,CloudServices targets
+ class Injection,AuthBypass,ConfigIssues,BusinessLogic attacks
+```
+
+---
+
+## ๐ Slide 12 โ ๐ ๏ธ Popular DAST Tools and Platform Overview
+
+* ๐ข **Commercial Enterprise DAST Tools**:
+ * ๐ก๏ธ **Veracode Dynamic Analysis**: **cloud-based scanning**, API testing, **authenticated scans**, compliance reporting
+ * ๐ **Rapid7 AppSpider**: **enterprise web app scanner**, **custom attack patterns**, detailed remediation guidance
+ * ๐ **Invicti (formerly Netsparker)**: **low false positive rate**, **proof-of-exploit**, WordPress/CMS specialization
+ * โก **HCL AppScan**: **IBM heritage**, **enterprise integration**, regulatory compliance focus
+* ๐ **Open Source DAST Tools**:
+ * โก **OWASP ZAP**: **most popular open-source** scanner, **active development**, **extensive plugin ecosystem**
+ * ๐ **Nikto**: **web server scanner**, **6000+ vulnerability tests**, lightweight and fast
+ * ๐ **w3af**: **Python-based framework**, **extensible architecture**, custom plugin development
+ * ๐ **SQLMap**: **specialized SQL injection** testing tool, **database takeover** capabilities
+* โ๏ธ **Cloud-Native DAST Solutions**:
+ * ๐ถ **AWS Inspector**: **application assessment**, **network reachability analysis**, **automated remediation**
+ * ๐ต **Azure Security Center**: **integrated DevOps**, **container scanning**, **threat intelligence**
+ * ๐ **Google Cloud Security Scanner**: **App Engine applications**, **automatic crawling**, **minimal false positives**
+* ๐ฏ **Specialized API Testing Tools**: **Postman Security**, **Insomnia**, **REST-Assured**, **Karate DSL**
+* ๐ **Market adoption**: **OWASP ZAP leads** with **45% open-source market share** ([DAST Tools Survey 2024](https://owasp.org/www-project-zap/))
+
+```mermaid
+flowchart TD
+ subgraph "๐ข Commercial Enterprise"
+ Veracode2[๐ก๏ธ Veracode Dynamic
โ๏ธ Cloud-based, API testing]
+ AppSpider[๐ Rapid7 AppSpider
๐ฏ Custom attack patterns]
+ Invicti[๐ Invicti Netsparker
๐ Low false positives]
+ AppScan[โก HCL AppScan
๐ข Enterprise integration]
+ end
+
+ subgraph "๐ Open Source Champions"
+ ZAP[โก OWASP ZAP
๐ Most popular, plugin ecosystem]
+ Nikto[๐ Nikto
โก 6000+ tests, lightweight]
+ w3af[๐ w3af
๐ง Python framework, extensible]
+ SQLMap[๐ SQLMap
๐ฏ SQL injection specialist]
+ end
+
+ subgraph "โ๏ธ Cloud-Native"
+ Inspector[๐ถ AWS Inspector
๐ Network + app assessment]
+ AzureSC[๐ต Azure Security Center
๐ณ Container scanning]
+ GoogleCS[๐ Google Cloud Scanner
๐ฑ App Engine focus]
+ end
+
+ subgraph "๐ API Specialists"
+ Postman[๐ฎ Postman Security
๐ API workflow testing]
+ Insomnia[๐ด Insomnia
๐ฏ GraphQL specialist]
+ RestAssured[๐ก๏ธ REST-Assured
โ Java API testing]
+ Karate[๐ฅ Karate DSL
๐ BDD API testing]
+ end
+
+ subgraph "๐ก Selection Criteria"
+ AppType[๐ Application Type
Web vs API vs Mobile]
+ Budget[๐ฐ Budget Constraints
Free vs Commercial]
+ Integration[๐ CI/CD Integration
Pipeline compatibility]
+ Expertise[๐ง Team Expertise
Tool complexity]
+ Compliance[๐ Compliance Needs
Regulatory requirements]
+ end
+
+ ZAP -.-> Budget
+ Veracode2 -.-> Compliance
+ AppSpider -.-> Integration
+ Postman -.-> AppType
+ Inspector -.-> Expertise
+
+ classDef commercial fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ classDef opensource fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ classDef cloud fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef api fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ classDef criteria fill:#fce4ec,stroke:#c2185b,stroke-width:2px,color:#2c3e50
+
+ class Veracode2,AppSpider,Invicti,AppScan commercial
+ class ZAP,Nikto,w3af,SQLMap opensource
+ class Inspector,AzureSC,GoogleCS cloud
+ class Postman,Insomnia,RestAssured,Karate api
+ class AppType,Budget,Integration,Expertise,Compliance criteria
+```
+
+---
+
+## ๐ Slide 13 โ โก DAST Strengths and Limitations
+
+* โ
**DAST Superpowers**:
+ * ๐ **Real-world conditions**: tests **actual running environment** with real configurations
+ * ๐ ๏ธ **Configuration testing**: detects **server misconfigurations**, missing security headers, SSL/TLS issues
+ * ๐งฉ **Business logic validation**: can identify **workflow manipulation** and **authorization bypasses**
+ * ๐ **Language agnostic**: works with **any technology stack** (Java, .NET, PHP, Node.js, Python)
+ * ๐ฏ **Production-like testing**: validates security in **staging/pre-production** environments
+ * ๐ **Low false positives**: **exploitable vulnerabilities** are confirmed through actual attacks
+* โ **DAST Limitations**:
+ * ๐ **Slow execution**: comprehensive scans can take **hours to days** for large applications
+ * ๐ **Limited code coverage**: only tests **accessible application paths** โ **~20-30% code coverage**
+ * ๐โโ๏ธ **Late-stage detection**: vulnerabilities found **after development** โ **expensive to fix**
+ * ๐ง **Complex setup**: requires **running application**, **test data**, **network access**
+ * ๐ **Authentication challenges**: difficulty testing **authenticated sections** and **complex workflows**
+ * ๐ฅ **Potentially disruptive**: aggressive testing may **crash applications** or **corrupt data**
+* ๐ **Industry insights**: **52% of organizations** use DAST but only **23% integrate it effectively** into CI/CD ([DevSecOps Maturity Report 2024](https://www.devsecops.org/))
+
+```mermaid
+graph TD
+ subgraph "โ
DAST Advantages"
+ RealWorld[๐ Real-World Testing
Actual runtime environment]
+ Config[๐ ๏ธ Configuration Issues
Server, SSL, headers]
+ BusinessLogic[๐งฉ Business Logic
Workflow validation]
+ TechAgnostic[๐ Technology Agnostic
Any language/platform]
+ ProdLike[๐ฏ Production-Like
Staging environment]
+ LowFP[๐ Low False Positives
Exploitable confirmed]
+ end
+
+ subgraph "โ DAST Challenges"
+ SlowExec[๐ Slow Execution
Hours to days]
+ LimitedCov[๐ Limited Coverage
20-30% code paths]
+ LateStage[๐โโ๏ธ Late Detection
Expensive fixes]
+ ComplexSetup[๐ง Complex Setup
Running app required]
+ AuthChall[๐ Auth Challenges
Complex workflows]
+ Disruptive[๐ฅ Potentially Disruptive
May crash/corrupt]
+ end
+
+ subgraph "๐ Mitigation Strategies"
+ Incremental[๐ Incremental Scanning
Focus on changes]
+ AuthConfig[๐ Auth Configuration
Session management]
+ TestEnv[๐งช Dedicated Test Env
Isolated from prod]
+ Scheduling[๐
Scheduled Scanning
Off-hours execution]
+ Hybrid[๐ค Hybrid Approach
SAST + DAST combination]
+ end
+
+ SlowExec --> Incremental
+ SlowExec --> Scheduling
+ AuthChall --> AuthConfig
+ ComplexSetup --> TestEnv
+ LimitedCov --> Hybrid
+ Disruptive --> TestEnv
+
+ classDef advantage fill:#e8f5e8,stroke:#2e7d32,stroke-width:2px,color:#2c3e50
+ classDef challenge fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ classDef mitigation fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+
+ class RealWorld,Config,BusinessLogic,TechAgnostic,ProdLike,LowFP advantage
+ class SlowExec,LimitedCov,LateStage,ComplexSetup,AuthChall,Disruptive challenge
+ class Incremental,AuthConfig,TestEnv,Scheduling,Hybrid mitigation
+```
+
+---
+
+## ๐ Slide 14 โ ๐ฏ DAST Implementation Best Practices
+
+* ๐ฏ **Successful DAST Deployment Strategy**:
+ * ๐งช **Dedicated test environment**: isolated staging environment with **production-like data**
+ * ๐
**Scheduling strategy**: run comprehensive scans **nightly** or **weekly** to avoid disruption
+ * ๐๏ธ **Incremental scanning**: focus on **changed components** for faster feedback in CI/CD
+ * ๐ **Risk-based prioritization**: fix **critical** and **high** vulnerabilities first
+* ๐ **Authentication and Session Management**:
+ * ๐ค **Test user accounts**: create dedicated **test accounts** with different **privilege levels**
+ * ๐ช **Session handling**: configure **automatic login** and **session maintenance**
+ * ๐ **Multi-step authentication**: handle **2FA**, **CAPTCHA**, and **complex login flows**
+ * ๐ **Role-based testing**: test with **admin**, **user**, and **anonymous** access levels
+* ๐ **CI/CD Pipeline Integration Patterns**:
+ * ๐ **Parallel execution**: run DAST **alongside** other testing phases
+ * ๐ **Quality gates**: **fail builds** only on **newly introduced** high-severity issues
+ * ๐ง **Smart notifications**: alert **relevant teams** based on vulnerability type
+ * ๐ **Trend analysis**: track vulnerability **introduction** and **resolution** rates
+* ๐ก **Performance Optimization Tips**: **crawler tuning** (limit scope), **payload optimization** (focus on likely vulnerabilities), **result caching** (avoid duplicate scans)
+
+```mermaid
+flowchart TD
+ subgraph "๐งช Test Environment Setup"
+ ProdLike[๐ฏ Production-Like
Same tech stack]
+ TestData[๐ Test Data
Realistic but safe]
+ Isolated[๐๏ธ Isolated Network
No production access]
+ Monitoring[๐ Performance Monitoring
Resource usage tracking]
+ end
+
+ subgraph "๐ Authentication Strategy"
+ TestUsers[๐ค Test User Accounts
Multiple privilege levels]
+ AutoLogin[๐ Automatic Login
Session maintenance]
+ MultiAuth[๐ก๏ธ Multi-factor Auth
2FA/CAPTCHA handling]
+ RoleTesting[๐ฅ Role-based Testing
Admin/User/Anonymous]
+ end
+
+ subgraph "๐ CI/CD Integration"
+ Parallel[โก Parallel Execution
Non-blocking scans]
+ QualityGate[๐ฆ Smart Quality Gates
New issues only]
+ Notifications[๐ง Targeted Alerts
Team-specific routing]
+ Trends[๐ Trend Analysis
Vulnerability metrics]
+ end
+
+ subgraph "โ๏ธ Performance Optimization"
+ ScopeLimit[๐ฏ Scope Limitation
Focus crawling]
+ PayloadOpt[๐ Payload Optimization
Smart attack selection]
+ ResultCache[๐พ Result Caching
Avoid duplicate work]
+ Incremental[๐ Incremental Scanning
Changed components only]
+ end
+
+ ProdLike --> TestUsers
+ TestData --> AutoLogin
+ Isolated --> Parallel
+ Monitoring --> QualityGate
+
+ MultiAuth --> ScopeLimit
+ RoleTesting --> PayloadOpt
+ Notifications --> ResultCache
+ Trends --> Incremental
+
+ classDef env fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ classDef auth fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef cicd fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ classDef perf fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+
+ class ProdLike,TestData,Isolated,Monitoring env
+ class TestUsers,AutoLogin,MultiAuth,RoleTesting auth
+ class Parallel,QualityGate,Notifications,Trends cicd
+ class ScopeLimit,PayloadOpt,ResultCache,Incremental perf
+```
+
+---
+
+## ๐ Slide 15 โ ๐ง Hands-on DAST: OWASP ZAP Configuration and Testing
+
+* ๐ง **OWASP ZAP Setup and Configuration**:
+ * ๐ณ **Docker deployment**: `docker run -t owasp/zap2docker-stable zap-baseline.py -t https://target-app.com`
+ * ๐ฅ๏ธ **Desktop GUI**: download from [zaproxy.org](https://www.zaproxy.org/) for interactive scanning
+ * ๐ค **CI/CD integration**: use **ZAP API** or **Jenkins plugin** for automated pipeline scanning
+ * โ๏ธ **Configuration files**: customize scan policies, authentication, and scope settings
+* ๐ท๏ธ **ZAP Spider and Active Scan Configuration**:
+ * ๐ **Spider configuration**: set **max crawl depth**, **exclude patterns**, **form handling**
+ * โ๏ธ **Active scan policies**: enable/disable **attack categories** based on application type
+ * ๐ฏ **Scope management**: define **in-scope URLs** and **exclude sensitive endpoints**
+ * ๐ **Scan tuning**: adjust **attack strength** and **timing** for different environments
+* ๐ **Authentication Configuration Examples**:
+ * ๐ **Form-based auth**: configure **login URL**, **username/password fields**, **success indicators**
+ * ๐ช **Session management**: handle **session cookies**, **CSRF tokens**, **logout detection**
+ * ๐ **API authentication**: configure **Bearer tokens**, **API keys**, **OAuth flows**
+* ๐ **Result Analysis and Reporting**: ZAP generates **HTML**, **XML**, and **JSON** reports with vulnerability details, remediation guidance, and **risk ratings**
+
+```mermaid
+flowchart TD
+ subgraph "๐ง ZAP Configuration Flow"
+ Target[๐ฏ Target Application
Define scope & URLs]
+ Spider[๐ท๏ธ Spider Configuration
Crawl settings & depth]
+ Auth[๐ Authentication Setup
Login & session handling]
+ Scan[โ๏ธ Active Scan Policy
Attack categories & strength]
+ Execute[โถ๏ธ Scan Execution
Spider โ Auth โ Attack]
+ Results[๐ Results Analysis
Vulnerability assessment]
+ end
+
+ subgraph "โ๏ธ ZAP Components"
+ Proxy[๐ Intercepting Proxy
HTTP/HTTPS traffic]
+ PassiveScan[๐๏ธ Passive Scanner
Traffic analysis]
+ ActiveScan[โ๏ธ Active Scanner
Attack simulation]
+ API[๐ค ZAP API
Automation interface]
+ end
+
+ subgraph "๐ Scan Results"
+ HighRisk[๐ด High Risk
SQL Injection, XSS]
+ MediumRisk[๐ก Medium Risk
Info disclosure]
+ LowRisk[๐ต Low Risk
Minor issues]
+ Info[โช Informational
Best practices]
+ end
+
+ Target --> Spider --> Auth --> Scan --> Execute --> Results
+
+ Spider --> Proxy
+ Auth --> PassiveScan
+ Scan --> ActiveScan
+ Execute --> API
+
+ Results --> HighRisk
+ Results --> MediumRisk
+ Results --> LowRisk
+ Results --> Info
+
+ classDef config fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef components fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ classDef results fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+
+ class Target,Spider,Auth,Scan,Execute,Results config
+ class Proxy,PassiveScan,ActiveScan,API components
+ class HighRisk,MediumRisk,LowRisk,Info results
+```
+
+---
+
+## ๐ **Fun Break: SAST vs DAST - The Eternal Debate!**
+
+### ๐ **"SAST vs DAST: The Developer Dating Game"**
+* ๐ **SAST is like dating someone's profile** โ you know everything about them on paper, but haven't met in person
+* ๐ **DAST is like meeting them in real life** โ you see how they actually behave, but don't know their deep thoughts
+* ๐ **IAST is like moving in together** โ you get the full picture, but it's a bigger commitment!
+* ๐ค **Smart couples use all three** โ because no single approach tells the whole story
+
+### ๐คฏ **Mind-Blowing Security Testing Facts:**
+* โก **Speed comparison**: SAST can scan **1 million lines in 5 minutes**, DAST takes **8 hours** for the same app
+* ๐ฏ **Coverage paradox**: SAST covers **100% of code** but finds **60% false positives**, DAST covers **30% of code** but has **95% accuracy**
+* ๐ฐ **ROI reality**: Companies using **both SAST and DAST** reduce security incidents by **73%** vs single-tool users
+* ๐ค **AI integration**: **GitHub Copilot** now suggests **ZAP scan configurations** when you mention security testing!
+
+### ๐ญ **Interactive Challenge for Students:**
+**๐ฎ "Build Your Security Testing Strategy Game!"**
+
+*Scenario: You're the security lead for a fintech startup. You have:*
+- ๐ฐ **Limited budget**: $50K/year for tools
+- โฐ **Tight deadlines**: 2-week sprints
+- ๐ฅ **Small team**: 5 developers, 2 QA engineers
+- ๐๏ธ **Compliance**: PCI-DSS requirements
+
+**Which combination would you choose and why?**
+1. ๐ฌ Premium SAST tool ($40K) + Open source DAST
+2. ๐ Open source everything (ZAP + SonarQube) + Security consultant
+3. โ๏ธ Cloud-native integrated suite (GitHub Advanced Security)
+
+*Discuss in groups and defend your choice!*
+
+---
+## ๐ Group 4: Interactive Application Security Testing (IAST)
+
+## ๐ Slide 16 โ ๐งฌ Deep Dive into IAST: Runtime Instrumentation Testing
+
+* ๐งฌ **IAST = Interactive Application Security Testing** โ **hybrid approach** combining benefits of **SAST and DAST** through **runtime instrumentation**.
+* ๐ง **How IAST works**:
+ * ๐ก **Agent instrumentation**: lightweight **monitoring agents** deployed within the application runtime
+ * ๐๏ธ **Runtime observation**: agents **monitor application behavior** during normal QA testing
+ * ๐ **Data flow tracking**: follows **untrusted data** from **input to dangerous operations**
+ * โก **Real-time analysis**: detects vulnerabilities **as they occur** during application execution
+* ๐ฏ **Gray-box testing approach**: has **access to source code** (like SAST) while testing **running application** (like DAST)
+* ๐งฉ **Key IAST capabilities**:
+ * ๐ **Precise vulnerability location**: pinpoints **exact line of code** with runtime context
+ * ๐ **Code coverage analysis**: shows **which code paths were tested** during QA execution
+ * ๐ซ **Low false positives**: validates vulnerabilities through **actual runtime conditions**
+ * ๐ **Incremental testing**: only tests **code paths that are actually executed**
+* โฑ๏ธ **Testing timing**: runs **during QA testing phase** when functional tests exercise application features
+* ๐ **Learn more**: [Gartner IAST Guide](https://www.gartner.com/en/information-technology/glossary/interactive-application-security-testing-iast), [OWASP IAST Overview](https://owasp.org/www-community/Vulnerability_Scanning_Tools)
+
+```mermaid
+flowchart TD
+ subgraph "๐งฌ IAST Architecture"
+ QATest[๐งช QA Testing
Functional test execution]
+ Agent[๐ค IAST Agent
Runtime instrumentation]
+ AppRuntime[๐ฅ๏ธ Application Runtime
Monitored execution]
+ Analysis[๐ง Real-time Analysis
Vulnerability detection]
+ Report[๐ IAST Report
Precise findings]
+ end
+
+ subgraph "๐ What IAST Monitors"
+ DataFlow[๐ Data Flow
Input to dangerous ops]
+ CodePaths[๐ Code Path Coverage
Execution tracking]
+ VulnContext[๐ฏ Vulnerability Context
Runtime conditions]
+ Performance[๐ Performance Impact
Resource monitoring]
+ end
+
+ subgraph "๐ฏ IAST Advantages"
+ Precise[๐ Precise Location
Exact line + context]
+ LowFP[๐ Low False Positives
Runtime validated]
+ Incremental[๐ Incremental Testing
Only executed paths]
+ Coverage[๐ Coverage Metrics
Testing effectiveness]
+ end
+
+ QATest --> Agent --> AppRuntime --> Analysis --> Report
+
+ Agent --> DataFlow
+ AppRuntime --> CodePaths
+ Analysis --> VulnContext
+ Agent --> Performance
+
+ Analysis --> Precise
+ VulnContext --> LowFP
+ CodePaths --> Incremental
+ Performance --> Coverage
+
+ classDef architecture fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef monitoring fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ classDef advantages fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+
+ class QATest,Agent,AppRuntime,Analysis,Report architecture
+ class DataFlow,CodePaths,VulnContext,Performance monitoring
+ class Precise,LowFP,Incremental,Coverage advantages
+```
+
+---
+
+## ๐ Slide 17 โ ๐ ๏ธ Popular IAST Tools and Platform Overview
+
+* ๐ข **Commercial Enterprise IAST Tools**:
+ * ๐ก๏ธ **Veracode Interactive Analysis**: **cloud-based IAST**, supports **Java, .NET, Node.js**, **DevOps integration**
+ * ๐ **Synopsys Seeker**: **comprehensive language support**, **custom policy creation**, **enterprise scalability**
+ * ๐ก๏ธ **Hdiv Security**: **specialized in business logic** vulnerabilities, **real-time protection**, **RASP capabilities**
+ * โก **Checkmarx Interactive**: **integrated with CxSAST**, **unified vulnerability management**, **correlation engine**
+* ๐ **Open Source & Community IAST**:
+ * ๐ฆ **OWASP Dependency-Check**: **limited IAST features**, focuses on **known vulnerable components**
+ * ๐ง **Custom instrumentation**: **AspectJ for Java**, **monkey patching for Python**, **middleware for Node.js**
+ * ๐ค **Research tools**: **JALANGI** (JavaScript), **PHOSPHOR** (Java taint tracking), academic projects
+* โ๏ธ **Cloud-Native IAST Limitations**:
+ * ๐ **Limited native offerings**: most cloud providers focus on **SAST and DAST**
+ * ๐ **RASP integration**: **Runtime Application Self-Protection** tools overlap with IAST functionality
+ * ๐ณ **Container challenges**: instrumentation complexity in **containerized environments**
+* ๐ **Market reality**: **IAST adoption is 23%** vs **67% SAST** and **52% DAST** ([Application Security Report 2024](https://www.synopsys.com/software-integrity.html))
+* ๐ก **Selection considerations**: **language support**, **performance overhead**, **DevOps integration**, **licensing costs**
+
+```mermaid
+flowchart TD
+ subgraph "๐ข Commercial IAST Leaders"
+ Veracode3[๐ก๏ธ Veracode Interactive
โ๏ธ Cloud-native, Java/.NET]
+ Seeker[๐ Synopsys Seeker
๐ Comprehensive languages]
+ Hdiv[๐ก๏ธ Hdiv Security
๐งฉ Business logic focus]
+ Checkmarx2[โก Checkmarx Interactive
๐ SAST integration]
+ end
+
+ subgraph "๐ Open Source Options"
+ DepCheck[๐ฆ OWASP Dependency-Check
๐ Component analysis]
+ Custom[๐ง Custom Instrumentation
๐ ๏ธ AspectJ, middleware]
+ Research[๐ค Research Tools
๐ JALANGI, PHOSPHOR]
+ end
+
+ subgraph "โ๏ธ Cloud & RASP Overlap"
+ Limited[๐ Limited Cloud Native
๐ง Few native IAST offerings]
+ RASP[๐ก๏ธ RASP Tools
๐ Runtime protection overlap]
+ Container[๐ณ Container Challenges
โ๏ธ Instrumentation complexity]
+ end
+
+ subgraph "๐ Adoption Barriers"
+ Performance[๐ Performance Overhead
5-15% typical impact]
+ Complexity[๐ง Implementation Complexity
Agent deployment & config]
+ Coverage[๐ Language Coverage
Limited framework support]
+ Cost[๐ฐ Licensing Costs
Per-application pricing]
+ end
+
+ Veracode3 --> Performance
+ Seeker --> Complexity
+ Hdiv --> Coverage
+ Custom --> Cost
+
+ classDef commercial fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ classDef opensource fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ classDef cloud fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef barriers fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+
+ class Veracode3,Seeker,Hdiv,Checkmarx2 commercial
+ class DepCheck,Custom,Research opensource
+ class Limited,RASP,Container cloud
+ class Performance,Complexity,Coverage,Cost barriers
+```
+
+---
+
+## ๐ Slide 18 โ โก IAST Strengths and Limitations
+
+* โ
**IAST Superpowers**:
+ * ๐ฏ **Extremely low false positives**: **<5% false positive rate** vs 30-40% for SAST
+ * ๐ **Precise vulnerability location**: exact **line of code + runtime context** for faster remediation
+ * ๐ **Code coverage insights**: shows **which parts of application were actually tested**
+ * โก **Real-time feedback**: detects vulnerabilities **during QA testing** when developers are most engaged
+ * ๐งฉ **Business logic testing**: can identify **complex multi-step vulnerabilities** that SAST/DAST miss
+ * ๐ **Incremental analysis**: only analyzes **executed code paths** โ more efficient than full SAST scans
+* โ **IAST Challenges**:
+ * ๐ **Performance overhead**: **5-15% performance impact** on application during testing
+ * ๐๏ธ **Deployment complexity**: requires **agent installation** and **runtime configuration**
+ * ๐ **Limited language support**: fewer supported **frameworks and languages** vs SAST/DAST
+ * ๐งช **Test-dependent coverage**: vulnerability detection limited to **QA test execution** scope
+ * ๐ฐ **Higher costs**: **per-application licensing** can be expensive for large portfolios
+ * ๐ณ **Container/cloud challenges**: **instrumentation complexity** in modern **containerized environments**
+* ๐ **Best use cases**: **critical applications** with **comprehensive QA testing**, **complex business logic**, **regulatory requirements**
+* ๐ **ROI sweet spot**: applications with **>10,000 lines of code** and **>50% test coverage** see best IAST value
+
+```mermaid
+graph TD
+ subgraph "โ
IAST Strengths"
+ LowFP[๐ฏ Ultra-Low False Positives
<5% vs 30-40% SAST]
+ Precise2[๐ Precise Location
Line + runtime context]
+ Coverage2[๐ Coverage Insights
Tested vs untested code]
+ RealTime[โก Real-time Feedback
During QA execution]
+ BusinessLogic2[๐งฉ Business Logic
Multi-step vulnerabilities]
+ Incremental2[๐ Incremental Analysis
Only executed paths]
+ end
+
+ subgraph "โ IAST Limitations"
+ PerfOverhead[๐ Performance Overhead
5-15% impact]
+ DeployComplex[๐๏ธ Deployment Complexity
Agent installation]
+ LangSupport[๐ Limited Language Support
Fewer frameworks]
+ TestDependent[๐งช Test-Dependent Coverage
QA execution scope]
+ HighCost[๐ฐ Higher Costs
Per-app licensing]
+ ContainerIssues[๐ณ Container Challenges
Instrumentation complexity]
+ end
+
+ subgraph "๐ฏ Ideal Use Cases"
+ CriticalApps[โญ Critical Applications
High security requirements]
+ ComprehensiveQA[๐งช Comprehensive QA
Good test coverage]
+ ComplexLogic[๐งฉ Complex Business Logic
Multi-tier workflows]
+ Compliance[๐ Regulatory Requirements
Financial, healthcare]
+ end
+
+ subgraph "๐ ROI Factors"
+ CodeSize[๐ Application Size
>10K lines optimal]
+ TestCoverage[๐ Test Coverage
>50% coverage needed]
+ VulnDensity[๐ Vulnerability Density
Historical incident rate]
+ TeamSize[๐ฅ Development Team
Dedicated QA resources]
+ end
+
+ LowFP --> CriticalApps
+ Precise2 --> ComprehensiveQA
+ BusinessLogic2 --> ComplexLogic
+ TestDependent --> Compliance
+
+ PerfOverhead --> CodeSize
+ DeployComplex --> TestCoverage
+ HighCost --> VulnDensity
+ ContainerIssues --> TeamSize
+
+ classDef strength fill:#e8f5e8,stroke:#2e7d32,stroke-width:2px,color:#2c3e50
+ classDef limitation fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ classDef usecase fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef roi fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+
+ class LowFP,Precise2,Coverage2,RealTime,BusinessLogic2,Incremental2 strength
+ class PerfOverhead,DeployComplex,LangSupport,TestDependent,HighCost,ContainerIssues limitation
+ class CriticalApps,ComprehensiveQA,ComplexLogic,Compliance usecase
+ class CodeSize,TestCoverage,VulnDensity,TeamSize roi
+```
+
+---
+
+## ๐ Slide 19 โ ๐ฏ IAST Implementation Best Practices
+
+* ๐ฏ **Strategic IAST Deployment Approach**:
+ * ๐ **Pilot program**: start with **1-2 critical applications** with **good QA coverage**
+ * ๐งช **Staging-first**: deploy agents in **staging environments** before considering production
+ * ๐ **Performance baseline**: establish **performance metrics** before agent deployment
+ * ๐ **Gradual rollout**: expand to additional applications based on **pilot success**
+* ๐ค **Agent Deployment Strategies**:
+ * ๐ณ **Containerized agents**: use **sidecar pattern** in Kubernetes environments
+ * ๐๏ธ **Build-time integration**: embed agents during **application build process**
+ * ๐ง **Runtime attachment**: dynamic agent attachment for **legacy applications**
+ * ๐ **Configuration management**: use **infrastructure-as-code** for agent configuration
+* ๐งช **QA Process Integration**:
+ * ๐ **Test coverage requirements**: ensure **>70% code coverage** for effective IAST results
+ * ๐ **Automated test execution**: integrate IAST with **automated regression testing**
+ * ๐ฅ **Manual testing protocols**: train QA teams on **security-focused testing scenarios**
+ * ๐ **Coverage gap analysis**: identify **untested code paths** for additional test creation
+* ๐ก **Performance Monitoring & Optimization**: **resource monitoring**, **agent tuning**, **selective instrumentation**, **result correlation**
+
+```mermaid
+flowchart TD
+ subgraph "๐ฏ Implementation Phases"
+ Plan[๐ Planning Phase
App selection, requirements]
+ Pilot[๐งช Pilot Deployment
1-2 critical applications]
+ Tune[๐๏ธ Performance Tuning
Agent optimization]
+ Scale[๐ Scaling Phase
Organization rollout]
+ Optimize[โ๏ธ Optimization
Continuous improvement]
+ end
+
+ subgraph "๐ค Agent Deployment Options"
+ Sidecar[๐ณ Sidecar Pattern
Kubernetes containers]
+ BuildTime[๐๏ธ Build Integration
Application packaging]
+ Runtime[๐ง Runtime Attachment
Dynamic instrumentation]
+ IaC[๐ Infrastructure-as-Code
Automated configuration]
+ end
+
+ subgraph "๐งช QA Integration"
+ Coverage[๐ Test Coverage
>70% requirement]
+ Automation[๐ค Automated Testing
Regression suite integration]
+ Manual[๐ฅ Manual Testing
Security scenario training]
+ GapAnalysis[๐ Coverage Analysis
Untested path identification]
+ end
+
+ subgraph "๐ Success Metrics"
+ VulnDetection[๐ Vulnerability Detection
New issues found]
+ FalsePositiveRate[๐ฏ False Positive Rate
<5% target]
+ PerfImpact[๐ Performance Impact
<10% overhead]
+ TimeToFix[โฑ๏ธ Time to Remediation
Reduced fix time]
+ end
+
+ Plan --> Pilot --> Tune --> Scale --> Optimize
+
+ Pilot --> Sidecar
+ Tune --> BuildTime
+ Scale --> Runtime
+ Optimize --> IaC
+
+ Coverage --> VulnDetection
+ Automation --> FalsePositiveRate
+ Manual --> PerfImpact
+ GapAnalysis --> TimeToFix
+
+ classDef phase fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef deployment fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ classDef qa fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ classDef metrics fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+
+ class Plan,Pilot,Tune,Scale,Optimize phase
+ class Sidecar,BuildTime,Runtime,IaC deployment
+ class Coverage,Automation,Manual,GapAnalysis qa
+ class VulnDetection,FalsePositiveRate,PerfImpact,TimeToFix metrics
+```
+
+---
+
+## ๐ Slide 20 โ ๐ง Hands-on IAST: Agent-based Testing Setup
+
+* ๐ง **IAST Agent Configuration Example** (Java Application):
+ * โ **JVM agent**: add `-javaagent:iast-agent.jar` to **application startup parameters**
+ * โ๏ธ **Configuration file**: specify **monitoring rules**, **reporting endpoints**, **performance settings**
+ * ๐ **Network connectivity**: ensure agent can **communicate with IAST server**
+ * ๐ **Logging configuration**: enable **agent debugging** during initial setup
+* ๐งช **QA Testing Integration Workflow**:
+ * ๐ **Application startup**: launch application with **IAST agent** attached
+ * ๐งช **Execute test suite**: run **functional**, **integration**, and **security tests**
+ * ๐๏ธ **Monitor agent activity**: watch **real-time vulnerability detection** in IAST dashboard
+ * ๐ **Review findings**: analyze **vulnerabilities** with **precise code location** and **runtime context**
+* ๐ **Performance Impact Assessment**:
+ * โฑ๏ธ **Response time monitoring**: measure **API response times** before/after agent
+ * ๐พ **Memory usage tracking**: monitor **heap utilization** and **garbage collection**
+ * ๐ **Throughput analysis**: assess **requests per second** impact
+ * ๐ **Resource optimization**: tune agent settings to **minimize overhead**
+* ๐ **Result Correlation and Analysis**: combine IAST findings with **SAST results**, identify **confirmed vulnerabilities**, prioritize based on **exploitability**
+
+```mermaid
+flowchart TD
+ subgraph "๐ง IAST Agent Setup"
+ JavaApp[โ Java Application
Target application]
+ AgentJAR[๐ฆ IAST Agent JAR
Instrumentation library]
+ Config[โ๏ธ Configuration File
Rules & settings]
+ Startup[๐ Application Startup
-javaagent parameter]
+ end
+
+ subgraph "๐งช QA Testing Execution"
+ TestSuite[๐งช Test Suite
Functional & security tests]
+ Monitoring[๐๏ธ Real-time Monitoring
Vulnerability detection]
+ Coverage[๐ Code Coverage
Execution path tracking]
+ Findings[๐ Vulnerability Findings
Precise location + context]
+ end
+
+ subgraph "๐ Performance Assessment"
+ ResponseTime[โฑ๏ธ Response Time
API latency measurement]
+ Memory[๐พ Memory Usage
Heap & GC monitoring]
+ Throughput[๐ Throughput
Requests per second]
+ Optimization[๐ Agent Tuning
Performance optimization]
+ end
+
+ subgraph "๐ Analysis & Correlation"
+ IASTResults[๐ IAST Results
Runtime vulnerabilities]
+ SASTCorrelation[๐ SAST Correlation
Static analysis comparison]
+ Prioritization[๐ Risk Prioritization
Exploitability assessment]
+ Remediation[๐ง Remediation Guidance
Fix recommendations]
+ end
+
+ JavaApp --> AgentJAR --> Config --> Startup
+
+ Startup --> TestSuite --> Monitoring --> Coverage --> Findings
+
+ Monitoring --> ResponseTime
+ Coverage --> Memory
+ Findings --> Throughput
+ TestSuite --> Optimization
+
+ Findings --> IASTResults --> SASTCorrelation --> Prioritization --> Remediation
+
+ classDef setup fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef testing fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ classDef performance fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ classDef analysis fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+
+ class JavaApp,AgentJAR,Config,Startup setup
+ class TestSuite,Monitoring,Coverage,Findings testing
+ class ResponseTime,Memory,Throughput,Optimization performance
+ class IASTResults,SASTCorrelation,Prioritization,Remediation analysis
+```
+
+---
+
+## ๐ Group 5: CI/CD Pipeline Integration and Automation
+
+## ๐ Slide 21 โ ๐ Integrating Security Testing into CI/CD Pipelines
+
+* ๐ **Security Testing Pipeline Strategy**:
+ * ๐๏ธ **Left-shift approach**: run **SAST** during **build phase** for immediate feedback
+ * ๐งช **Middle integration**: execute **IAST** during **QA testing phase** for runtime validation
+ * ๐ **Right-shift validation**: perform **DAST** in **staging/pre-production** for final verification
+ * ๐ **Continuous monitoring**: ongoing security assessment in **production** environments
+* โ๏ธ **Quality Gate Implementation**:
+ * ๐ฆ **Fail-fast strategy**: **block builds** on critical/high vulnerabilities in main branch
+ * ๐ **Risk-based gates**: different thresholds for **development**, **staging**, **production** pipelines
+ * ๐ **Progressive enforcement**: **gradual tightening** of security requirements over time
+ * ๐จ **Emergency bypasses**: controlled **override mechanisms** for critical business needs
+* โก **Parallel vs Sequential Execution**:
+ * โก **Parallel benefits**: **faster pipeline execution**, independent tool operation
+ * ๐ **Sequential advantages**: **result correlation**, dependency management, resource optimization
+ * ๐ฏ **Hybrid approach**: **SAST parallel** with build, **DAST sequential** after deployment
+* ๐ **Pipeline Performance Optimization**: **caching strategies**, **incremental scanning**, **result persistence**, **smart triggering**
+
+```mermaid
+flowchart LR
+ subgraph "๐๏ธ CI/CD Pipeline Stages"
+ Commit[๐ Code Commit
Developer push]
+ Build[โ๏ธ Build Stage
Compile & package]
+ Test[๐งช Test Stage
QA & Integration]
+ Deploy[๐ Deploy Stage
Staging deployment]
+ Prod[๐ Production
Live environment]
+ end
+
+ subgraph "๐ Security Testing Integration"
+ SAST2[๐ฌ SAST
Static analysis]
+ IAST2[๐งฌ IAST
Interactive testing]
+ DAST2[๐ DAST
Dynamic testing]
+ Monitor[๐ Runtime Monitoring
Continuous security]
+ end
+
+ subgraph "๐ฆ Quality Gates"
+ BuildGate[๐ฆ Build Gate
SAST results check]
+ TestGate[๐ฆ Test Gate
IAST findings review]
+ DeployGate[๐ฆ Deploy Gate
DAST validation]
+ ProdGate[๐ฆ Prod Gate
Monitoring alerts]
+ end
+
+ Commit --> Build
+ Build --> Test
+ Test --> Deploy
+ Deploy --> Prod
+
+ Build --> SAST2
+ Test --> IAST2
+ Deploy --> DAST2
+ Prod --> Monitor
+
+ SAST2 --> BuildGate
+ IAST2 --> TestGate
+ DAST2 --> DeployGate
+ Monitor --> ProdGate
+
+ BuildGate -->|โ Fail| Commit
+ TestGate -->|โ Fail| Build
+ DeployGate -->|โ Fail| Test
+ ProdGate -->|๐จ Alert| Deploy
+
+ classDef pipeline fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef security fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ classDef gates fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+
+ class Commit,Build,Test,Deploy,Prod pipeline
+ class SAST2,IAST2,DAST2,Monitor security
+ class BuildGate,TestGate,DeployGate,ProdGate gates
+```
+
+---
+
+## ๐ Slide 22 โ ๐ Tool Orchestration and Security Dashboard Creation
+
+* ๐ **Multi-Tool Result Aggregation**:
+ * ๐ **Data normalization**: convert **different tool formats** into **unified vulnerability model**
+ * ๐ฏ **Deduplication logic**: identify **same vulnerability** found by **multiple tools**
+ * ๐ **Risk scoring**: combine **CVSS scores**, **exploitability**, **business context**
+ * ๐ท๏ธ **Vulnerability lifecycle**: track findings from **detection** through **remediation**
+* ๐๏ธ **Security Orchestration Platforms**:
+ * ๐ก๏ธ **DefectDojo**: **open-source** vulnerability management with **140+ tool integrations**
+ * ๐ **ThreadFix**: **commercial platform** with **advanced correlation** and **application mapping**
+ * ๐ **Snyk**: **developer-first** platform with **IDE**, **SCM**, and **CI/CD** integrations
+ * โ๏ธ **Cloud-native**: **AWS Security Hub**, **Azure Security Center**, **Google Security Command Center**
+* ๐ **Dashboard Design Principles**:
+ * ๐ฅ **Role-based views**: **executives** see trends, **developers** see actionable items, **security** sees details
+ * ๐ฏ **Actionable insights**: focus on **"what to fix first"** rather than raw vulnerability counts
+ * ๐ **Trend analysis**: show **security posture** improvements over time
+ * ๐จ **Alert fatigue prevention**: intelligent notifications based on **priority** and **change**
+* ๐ค **Automation and Workflows**: **auto-assignment** to developers, **JIRA integration**, **SLA tracking**, **compliance reporting**
+
+```mermaid
+flowchart TD
+ subgraph "๐ ๏ธ Security Tools"
+ SAST3[๐ฌ SAST Tools
SonarQube, Checkmarx]
+ DAST3[๐ DAST Tools
ZAP, Veracode]
+ IAST3[๐งฌ IAST Tools
Seeker, Hdiv]
+ SCA[๐ฆ SCA Tools
Snyk, WhiteSource]
+ Secrets[๐ Secret Scanning
GitLeaks, TruffleHog]
+ end
+
+ subgraph "๐ Orchestration Layer"
+ Normalize[๐ Data Normalization
Unified vulnerability format]
+ Dedupe[๐ฏ Deduplication
Same vuln detection]
+ Score[๐ Risk Scoring
CVSS + context]
+ Workflow[๐ Workflow Engine
Assignment & tracking]
+ end
+
+ subgraph "๐ Security Dashboard"
+ Executive[๐ Executive View
Trends & KPIs]
+ Developer[๐จโ๐ป Developer View
Actionable items]
+ Security[๐ก๏ธ Security View
Detailed analysis]
+ Compliance[๐ Compliance View
Audit reports]
+ end
+
+ subgraph "๐ Integration Points"
+ JIRA[๐ซ JIRA Integration
Ticket management]
+ Slack[๐ฌ Slack Alerts
Team notifications]
+ Email[๐ง Email Reports
Scheduled summaries]
+ API[๐ REST APIs
Custom integrations]
+ end
+
+ SAST3 --> Normalize
+ DAST3 --> Normalize
+ IAST3 --> Dedupe
+ SCA --> Score
+ Secrets --> Workflow
+
+ Normalize --> Executive
+ Dedupe --> Developer
+ Score --> Security
+ Workflow --> Compliance
+
+ Executive --> JIRA
+ Developer --> Slack
+ Security --> Email
+ Compliance --> API
+
+ classDef tools fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef orchestration fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ classDef dashboard fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ classDef integration fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+
+ class SAST3,DAST3,IAST3,SCA,Secrets tools
+ class Normalize,Dedupe,Score,Workflow orchestration
+ class Executive,Developer,Security,Compliance dashboard
+ class JIRA,Slack,Email,API integration
+```
+
+---
+
+## ๐ Slide 23 โ โ๏ธ Balancing Security and Development Velocity
+
+* โ๏ธ **The Velocity vs Security Dilemma**:
+ * โก **Developer pressure**: **feature delivery deadlines** vs **security requirements**
+ * ๐ **False positive fatigue**: too many **non-actionable alerts** slow development
+ * ๐ฆ **Quality gate friction**: overly strict gates can **block legitimate releases**
+ * ๐ฐ **Business pressure**: **time-to-market** vs **risk tolerance**
+* ๐ฏ **Risk-Based Security Approach**:
+ * ๐ **Contextual risk scoring**: consider **data sensitivity**, **user exposure**, **attack surface**
+ * ๐ท๏ธ **Application classification**: **critical**, **high**, **medium**, **low** risk tiers
+ * ๐ **Progressive enforcement**: **stricter rules** for higher-risk applications
+ * โฐ **Time-based thresholds**: **immediate fixes** for critical, **30 days** for high, **next release** for medium
+* ๐ **Developer Experience Optimization**:
+ * ๐ป **IDE integration**: **real-time feedback** without breaking developer flow
+ * ๐ง **Smart notifications**: **context-aware alerts** with **clear remediation guidance**
+ * ๐ฏ **Just-in-time training**: **educational content** delivered when vulnerabilities found
+ * ๐ **Gamification**: **security achievement badges**, **vulnerability fix leaderboards**
+* ๐ **Emergency Response Procedures**: **bypass mechanisms**, **post-deployment fixes**, **incident response**, **lessons learned**
+
+```mermaid
+graph TD
+ subgraph "โ๏ธ Balancing Factors"
+ Velocity[โก Development Velocity
Feature delivery speed]
+ Security[๐ก๏ธ Security Requirements
Risk mitigation needs]
+ Business[๐ฐ Business Pressure
Time-to-market demands]
+ Compliance[๐ Compliance Needs
Regulatory requirements]
+ end
+
+ subgraph "๐ฏ Risk-Based Strategy"
+ Critical[๐ด Critical Apps
Strict security gates]
+ High[๐ก High Risk Apps
Moderate enforcement]
+ Medium[๐ต Medium Risk Apps
Standard controls]
+ Low[โช Low Risk Apps
Minimal gates]
+ end
+
+ subgraph "๐ Developer Experience"
+ IDE2[๐ป IDE Integration
Real-time feedback]
+ Smart[๐ง Smart Notifications
Context-aware alerts]
+ Training2[๐ฏ Just-in-time Learning
Educational content]
+ Gamify[๐ Gamification
Achievement system]
+ end
+
+ subgraph "๐ Success Metrics"
+ DeployFreq[๐ Deployment Frequency
Releases per week]
+ LeadTime[โฑ๏ธ Lead Time
Commit to production]
+ MTTR2[๐ง Mean Time to Recovery
Incident resolution]
+ VulnFix[๐ Vulnerability Fix Rate
Time to remediation]
+ end
+
+ Velocity --> Critical
+ Security --> High
+ Business --> Medium
+ Compliance --> Low
+
+ Critical --> IDE2
+ High --> Smart
+ Medium --> Training2
+ Low --> Gamify
+
+ IDE2 --> DeployFreq
+ Smart --> LeadTime
+ Training2 --> MTTR2
+ Gamify --> VulnFix
+
+ classDef factors fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ classDef strategy fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ classDef experience fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef metrics fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+
+ class Velocity,Security,Business,Compliance factors
+ class Critical,High,Medium,Low strategy
+ class IDE2,Smart,Training2,Gamify experience
+ class DeployFreq,LeadTime,MTTR2,VulnFix metrics
+```
+
+---
+
+## ๐ Slide 24 โ ๐ Advanced Integration Patterns and GitOps
+
+* ๐ **GitOps Security Integration**:
+ * ๐ **Security-as-Code**: store **security policies**, **scan configurations**, **quality gates** in Git
+ * ๐ค **Automated policy updates**: **GitOps operators** sync security configurations across environments
+ * ๐ **Immutable security**: **version-controlled** security settings prevent **configuration drift**
+ * ๐ **Rollback capabilities**: **revert security changes** using Git history
+* ๐๏ธ **Infrastructure-as-Code (IaC) Security Testing**:
+ * โ๏ธ **Cloud formation scanning**: **Terraform**, **ARM templates**, **CloudFormation** security validation
+ * ๐ณ **Container security**: **Dockerfile** scanning, **image vulnerability** assessment, **runtime protection**
+ * โธ๏ธ **Kubernetes security**: **YAML manifest** scanning, **RBAC validation**, **network policy** checking
+ * ๐ **Policy enforcement**: **Open Policy Agent (OPA)**, **Gatekeeper**, **Falco** integration
+* ๐ **Advanced Pipeline Patterns**:
+ * ๐ **Multi-stage pipelines**: **security testing** at **build**, **test**, **deploy**, **runtime** stages
+ * ๐ **Multi-environment validation**: **progressive deployment** with security validation at each stage
+ * ๐ **Branching strategies**: different **security requirements** for **feature**, **develop**, **main** branches
+ * ๐ **Compliance pipelines**: automated **audit trails**, **evidence collection**, **regulatory reporting**
+* ๐ค **AI and Automation**: **ML-powered** vulnerability prioritization, **automated** remediation suggestions, **intelligent** false positive reduction
+
+```mermaid
+flowchart TD
+ subgraph "๐ GitOps Security Model"
+ GitRepo[๐ Git Repository
Security policies & configs]
+ GitOpsOperator[๐ค GitOps Operator
Automated sync]
+ SecurityConfigs[โ๏ธ Security Configurations
Immutable settings]
+ PolicyEngine[๐ Policy Engine
OPA, Gatekeeper]
+ end
+
+ subgraph "๐๏ธ IaC Security Testing"
+ Terraform[โ๏ธ Terraform
Infrastructure code]
+ Dockerfile[๐ณ Dockerfile
Container definitions]
+ K8sManifests[โธ๏ธ K8s Manifests
Deployment configs]
+ IaCScanner[๐ IaC Scanner
Configuration validation]
+ end
+
+ subgraph "๐ Advanced Pipeline Patterns"
+ FeatureBranch[๐ฟ Feature Branch
Basic security checks]
+ DevelopBranch[๐ง Develop Branch
Comprehensive testing]
+ MainBranch[๐ฏ Main Branch
Full security validation]
+ MultiStage[๐ญ Multi-stage Deploy
Progressive validation]
+ end
+
+ subgraph "๐ค AI-Powered Automation"
+ MLPrioritization[๐ง ML Prioritization
Risk-based ranking]
+ AutoRemediation[๐ง Auto Remediation
Fix suggestions]
+ FalsePositiveML[๐ฏ FP Reduction
ML-powered filtering]
+ PredictiveAnalysis[๐ Predictive Analysis
Trend forecasting]
+ end
+
+ GitRepo --> GitOpsOperator --> SecurityConfigs --> PolicyEngine
+
+ Terraform --> IaCScanner
+ Dockerfile --> IaCScanner
+ K8sManifests --> IaCScanner
+
+ FeatureBranch --> DevelopBranch --> MainBranch --> MultiStage
+
+ PolicyEngine --> MLPrioritization
+ IaCScanner --> AutoRemediation
+ MultiStage --> FalsePositiveML
+ MLPrioritization --> PredictiveAnalysis
+
+ classDef gitops fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ classDef iac fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef patterns fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ classDef ai fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+
+ class GitRepo,GitOpsOperator,SecurityConfigs,PolicyEngine gitops
+ class Terraform,Dockerfile,K8sManifests,IaCScanner iac
+ class FeatureBranch,DevelopBranch,MainBranch,MultiStage patterns
+ class MLPrioritization,AutoRemediation,FalsePositiveML,PredictiveAnalysis ai
+```
+
+---
+
+## ๐ Slide 25 โ ๐ Modern Trends and Future of Application Security Testing
+
+* ๐ค **AI and Machine Learning Revolution**:
+ * ๐ง **Smart vulnerability detection**: **ML models** trained on **millions of code patterns** reduce false positives by **60%**
+ * ๐ฏ **Intelligent prioritization**: **AI-powered risk scoring** considers **exploit probability**, **business impact**, **environmental context**
+ * ๐ง **Automated remediation**: **AI-generated** fix suggestions with **code patches** for common vulnerability patterns
+ * ๐ **Predictive analysis**: **ML models** predict **future vulnerability hotspots** based on code changes and historical data
+* ๐ **Shift-Everywhere Security**:
+ * โฌ
๏ธ **Shift-left expansion**: security testing **in IDEs**, **pre-commit hooks**, **code review** integration
+ * โก๏ธ **Shift-right adoption**: **production security monitoring**, **runtime protection**, **continuous compliance**
+ * ๐ **Shift-everywhere**: security considerations **throughout entire** software lifecycle
+* โ๏ธ **Cloud-Native and Serverless Security**:
+ * ๐๏ธ **Serverless function scanning**: **AWS Lambda**, **Azure Functions**, **Google Cloud Functions** security testing
+ * ๐ณ **Container-native security**: **admission controllers**, **runtime monitoring**, **image signing** workflows
+ * โธ๏ธ **Kubernetes security**: **pod security standards**, **network policies**, **service mesh** security validation
+* ๐ฆ **Supply Chain Security Integration**: **SBOM generation**, **dependency signing**, **provenance tracking**, **vulnerability disclosure** automation
+* ๐ฎ **Emerging technologies**: **quantum-safe cryptography** testing, **WebAssembly security**, **edge computing** security validation
+
+```mermaid
+flowchart TD
+ subgraph "๐ค AI/ML Revolution"
+ SmartDetection[๐ง Smart Detection
60% FP reduction]
+ IntelligentPrio[๐ฏ Intelligent Prioritization
Context-aware scoring]
+ AutoRemediation2[๐ง Auto Remediation
AI-generated fixes]
+ Predictive[๐ Predictive Analysis
Future hotspot detection]
+ end
+
+ subgraph "๐ Shift-Everywhere"
+ ShiftLeft[โฌ
๏ธ Shift-Left++
IDE, pre-commit, review]
+ ShiftRight[โก๏ธ Shift-Right
Production monitoring]
+ ShiftEverywhere[๐ Shift-Everywhere
Full lifecycle security]
+ end
+
+ subgraph "โ๏ธ Cloud-Native Evolution"
+ Serverless[๐๏ธ Serverless Security
Function scanning]
+ Containers[๐ณ Container-Native
Runtime protection]
+ Kubernetes[โธ๏ธ K8s Security
Policy enforcement]
+ ServiceMesh[๐ธ๏ธ Service Mesh
Zero-trust networking]
+ end
+
+ subgraph "๐ฎ Future Technologies"
+ QuantumSafe[๐ Quantum-Safe Crypto
Post-quantum algorithms]
+ WebAssembly[โก WebAssembly Security
WASM runtime protection]
+ EdgeComputing[๐ Edge Security
Distributed validation]
+ SupplyChain[๐ฆ Supply Chain++
SBOM, provenance, signing]
+ end
+
+ subgraph "๐ 2025-2030 Predictions"
+ AIAdoption[๐ค 90% AI Integration
ML-powered testing]
+ RealTimeSec[โก Real-time Security
Instant vulnerability detection]
+ ZeroTouchSec[๐คฒ Zero-touch Security
Fully automated remediation]
+ QuantumReady[๐ฎ Quantum-ready
Post-quantum crypto standard]
+ end
+
+ SmartDetection --> AIAdoption
+ ShiftEverywhere --> RealTimeSec
+ ServiceMesh --> ZeroTouchSec
+ QuantumSafe --> QuantumReady
+
+ classDef ai fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ classDef shift fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef cloud fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ classDef future fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ classDef predictions fill:#fce4ec,stroke:#c2185b,stroke-width:2px,color:#2c3e50
+
+ class SmartDetection,IntelligentPrio,AutoRemediation2,Predictive ai
+ class ShiftLeft,ShiftRight,ShiftEverywhere shift
+ class Serverless,Containers,Kubernetes,ServiceMesh cloud
+ class QuantumSafe,WebAssembly,EdgeComputing,SupplyChain future
+ class AIAdoption,RealTimeSec,ZeroTouchSec,QuantumReady predictions
+```
+
+---
+
+## ๐ Slide 26 โ ๐ฏ Summary & Key Takeaways
+
+* ๐ฏ **The Three Pillars of Application Security Testing**:
+ * ๐ฌ **SAST**: Early detection, complete coverage, **integrate in build phase**
+ * ๐ **DAST**: Real-world validation, configuration testing, **run in staging**
+ * ๐งฌ **IAST**: Best of both worlds, low false positives, **deploy during QA**
+* ๐ **CI/CD Integration Success Formula**:
+ * โ๏ธ **Balance velocity with security**: risk-based approach, smart quality gates
+ * ๐ **Tool orchestration**: unified dashboards, deduplication, correlation
+ * ๐ฅ **Developer experience**: IDE integration, just-in-time training, gamification
+ * ๐ **Continuous improvement**: metrics-driven optimization, feedback loops
+* ๐ **Future-Ready Security Testing**:
+ * ๐ค **Embrace AI/ML**: intelligent prioritization, automated remediation
+ * ๐ **Shift-everywhere mindset**: security throughout entire lifecycle
+ * โ๏ธ **Cloud-native focus**: containers, serverless, Kubernetes security
+ * ๐ฆ **Supply chain protection**: SBOM, signing, provenance tracking
+* ๐ก **Remember**: **Perfect security is impossible**, but **continuous improvement** through **automated testing** makes applications **significantly more secure** while **maintaining development velocity**
+
+```mermaid
+graph TD
+ subgraph "๐ Key Success Factors"
+ Strategy[๐ Security Testing Strategy
SAST + DAST + IAST]
+ Integration[๐ CI/CD Integration
Seamless workflow]
+ Culture[๐ฅ Security Culture
Developer engagement]
+ Automation[๐ค Automation
Tool orchestration]
+ end
+
+ subgraph "๐ Success Metrics"
+ VelocityMetric[โก Development Velocity
Maintained or improved]
+ SecurityPosture[๐ก๏ธ Security Posture
Vulnerability reduction]
+ DeveloperSat[๐จโ๐ป Developer Satisfaction
Tool adoption rate]
+ BusinessValue[๐ฐ Business Value
Risk mitigation ROI]
+ end
+
+ subgraph "๐ Next Steps"
+ Assessment[๐ Current State Assessment
Gap analysis]
+ Pilot[๐งช Pilot Implementation
Start small, learn fast]
+ Scale[๐ Scaling Strategy
Organization-wide rollout]
+ Optimize[โ๏ธ Continuous Optimization
Metrics-driven improvement]
+ end
+
+ Strategy --> VelocityMetric
+ Integration --> SecurityPosture
+ Culture --> DeveloperSat
+ Automation --> BusinessValue
+
+ VelocityMetric --> Assessment
+ SecurityPosture --> Pilot
+ DeveloperSat --> Scale
+ BusinessValue --> Optimize
+
+ classDef success fill:#e8f5e8,stroke:#2e7d32,stroke-width:3px,color:#2c3e50
+ classDef metrics fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ classDef next fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+
+ class Strategy,Integration,Culture,Automation success
+ class VelocityMetric,SecurityPosture,DeveloperSat,BusinessValue metrics
+ class Assessment,Pilot,Scale,Optimize next
+```
diff --git a/lectures/lec6.md b/lectures/lec6.md
new file mode 100644
index 00000000..b4ba4ad7
--- /dev/null
+++ b/lectures/lec6.md
@@ -0,0 +1,2541 @@
+# ๐Lecture 6 - Infrastructure-as-Code Security: Terraform, Pulumi, Ansible & Policy-as-Code
+
+## ๐ Group 1: IaC Foundations
+
+## ๐ Slide 1 โ ๐ What is Infrastructure-as-Code (IaC)?
+
+* ๐งฉ **Infrastructure-as-Code (IaC)** = managing infrastructure through **machine-readable definition files** rather than manual configuration.
+* ๐ Key principle: **"Infrastructure should be versioned, tested, and deployed like application code."**
+* โก Core benefits:
+ * ๐ **Repeatability** โ deploy identical environments every time
+ * ๐ฆ **Version control** โ track changes, rollback, audit history
+ * ๐ **Automation** โ eliminate manual errors, increase speed
+ * ๐งช **Testing** โ validate infrastructure before deployment
+* ๐ **Industry adoption:** 76% of organizations use IaC in production (HashiCorp State of Cloud Strategy Survey 2024)
+* ๐ **Learn more:** [What is Infrastructure as Code? (HashiCorp)](https://www.hashicorp.com/resources/what-is-infrastructure-as-code), [IaC Best Practices (AWS)](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)
+
+```mermaid
+flowchart LR
+ Traditional[๐ฑ๏ธ Manual Configuration
ClickOps, Console] -->|Problems| Issues[โ Inconsistent
โ Untracked
โ Slow]
+ IaC[๐ Infrastructure-as-Code
Terraform, Pulumi, Ansible] -->|Benefits| Wins[โ
Repeatable
โ
Versioned
โ
Fast]
+
+ style Traditional fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style IaC fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Issues fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Wins fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Evolution Timeline
+
+```mermaid
+timeline
+ title ๐ฐ๏ธ Infrastructure Management Evolution
+ 1990s : ๐ง Manual Configuration
Physical servers, manual setup
+ 2000s : ๐ Shell Scripts
Bash automation, brittle
+ 2005 : โ๏ธ Configuration Management
Puppet, Chef
+ 2012 : ๐ฆ Ansible Released
Agentless, YAML-based
+ 2014 : ๐๏ธ Terraform Released
Declarative, multi-cloud
+ 2018 : ๐ Pulumi Released
Real programming languages
+ 2025 : ๐ค AI-Assisted IaC
Policy-as-code, GitOps
+```
+
+---
+
+### ๐งฉ Declarative vs Imperative
+
+* ๐ฏ **Declarative (What):**
+ * Define **desired end state**
+ * Tool figures out **how to get there**
+ * Examples: Terraform, CloudFormation, Kubernetes YAML
+ * ๐ "I want 3 servers with this config"
+* ๐ ๏ธ **Imperative (How):**
+ * Define **exact steps** to execute
+ * Explicit **command sequence**
+ * Examples: Bash scripts, Ansible playbooks (can be both)
+ * ๐ "Create server 1, then server 2, then server 3"
+
+```mermaid
+flowchart TD
+ subgraph Declarative
+ D1[๐ Desired State - 3 web servers] --> D2[๐ค Tool Calculates Diff]
+ D2 --> D3[โก Executes Changes]
+ end
+
+ subgraph Imperative
+ I1[๐ Step 1: Create server] --> I2[๐ Step 2: Install nginx]
+ I2 --> I3[๐ Step 3: Configure firewall]
+ end
+
+ style Declarative fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Imperative fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+```
+
+
+๐ญ Interactive Quiz: Is Ansible declarative or imperative?
+
+**Answer:** **Both!** ๐ฏ
+
+* Ansible playbooks use **declarative modules** (e.g., `state: present`)
+* But executed in **imperative order** (top to bottom)
+* This makes Ansible a **hybrid approach**
+* Often called **"procedural with declarative elements"**
+
+
+
+---
+
+## ๐ Slide 2 โ ๐จ Why IaC Security Matters
+
+* ๐ฅ **Infrastructure misconfigurations = #1 cloud security risk**
+ * 67% of cloud breaches stem from misconfigurations (IBM Cost of Data Breach Report 2024)
+ * Average breach cost: **$4.88M** (up 10% from 2023)
+* ๐ฅ **Major incidents caused by IaC failures:**
+ * ๐ฆ **Capital One (2019):** Misconfigured WAF โ 100M records exposed โ $190M fine
+ * โก **Tesla (2018):** Public Kubernetes dashboard โ crypto mining attack
+ * ๐ชฃ **Pentagon S3 buckets (2017):** 1.8B social media posts exposed publicly
+* โ ๏ธ **IaC amplifies both security AND insecurity:**
+ * โ
Good config โ deployed consistently everywhere
+ * โ Bad config โ replicated across all environments instantly
+* ๐ **Attack surface expansion:** IaC tools have access to **everything** (cloud credentials, secrets, production systems)
+
+```mermaid
+flowchart TD
+ subgraph "โ Traditional Manual Config"
+ M1[Manual Error] --> M2[Single Server Affected]
+ end
+
+ subgraph "๐ฅ IaC Without Security"
+ I1[Misconfigured Template] --> I2[Automated Deployment]
+ I2 --> I3[โ ๏ธ ALL Environments Affected]
+ I3 --> I4[๐ฅ Massive Blast Radius]
+ end
+
+ subgraph "โ
IaC With Security"
+ S1[Template with Security Checks] --> S2[Automated Scanning]
+ S2 --> S3[โ Blocks Bad Config]
+ S2 --> S4[โ
Deploys Secure Config]
+ end
+
+ style M1 fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style I1 fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style I4 fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style S1 fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style S4 fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ฏ Real-World Impact Statistics
+
+* ๐ **95% of cloud breaches** are due to customer misconfigurations, not cloud provider failures (Gartner)
+* โฐ **Average time to detect misconfiguration:** 279 days (IBM)
+* ๐ฐ **Cost of remediation:**
+ * Fix in development: **$100**
+ * Fix in production: **$10,000+**
+ * Fix after breach: **$1,000,000+**
+* ๐ **Most common IaC security issues:**
+ * 43% โ Hardcoded secrets
+ * 38% โ Overly permissive IAM roles
+ * 31% โ Unencrypted storage
+ * 29% โ Public resource exposure
+
+
+๐ญ Discussion Question: Why do you think misconfigurations happen so frequently?
+
+**Common Reasons:**
+
+1. ๐โโ๏ธ **Speed over security** โ "Move fast, secure later" mentality
+2. ๐ **Complexity** โ Cloud services have thousands of configuration options
+3. ๐ฅ **Lack of expertise** โ Developers learning infrastructure on the fly
+4. ๐ **Copy-paste culture** โ Reusing insecure examples from internet
+5. ๐ซ **No guardrails** โ Missing automated security checks in pipelines
+6. ๐๏ธ **Visibility gaps** โ Hard to audit infrastructure across multiple clouds
+
+**Solution:** Shift-left security + Policy-as-code + Automated scanning!
+
+
+
+---
+
+## ๐ Slide 3 โ ๐ IaC Tool Landscape Overview
+
+* ๐๏ธ **HashiCorp Terraform** (2014)
+ * ๐ Multi-cloud, declarative HCL (HashiCorp Configuration Language)
+ * ๐ฆ 40,000+ providers, massive ecosystem
+ * ๐ง State management with remote backends
+ * ๐ผ Market leader: 67% adoption (CNCF Survey 2024)
+* ๐ **Pulumi** (2018)
+ * ๐ป Real programming languages (TypeScript, Python, Go, C#, Java)
+ * ๐ Built-in secrets management
+ * ๐งช Full testing frameworks (unit, integration)
+ * ๐ Growing adoption: 18% (up from 9% in 2023)
+* โ๏ธ **Ansible** (2012, Red Hat)
+ * ๐ชถ Agentless SSH-based automation
+ * ๐ YAML playbooks, imperative + declarative
+ * ๐ Ansible Vault for secrets
+ * ๐ข Popular for config management: 52% adoption
+* โ๏ธ **Cloud-Native Tools**
+ * ๐ถ **AWS CloudFormation** (2011) โ JSON/YAML templates
+ * ๐ต **Azure Resource Manager (ARM)** (2014) โ JSON templates
+ * ๐ท **Google Cloud Deployment Manager** (2015) โ YAML/Jinja2
+
+```mermaid
+flowchart TD
+ subgraph "๐๏ธ Provisioning Tools"
+ TF[๐๏ธ Terraform
Multi-cloud, HCL]
+ PU[๐ Pulumi
Real code, TypeScript/Python]
+ CF[โ๏ธ CloudFormation
AWS-native]
+ end
+
+ subgraph "โ๏ธ Configuration Management"
+ AN[โ๏ธ Ansible
Agentless, YAML]
+ CH[๐จโ๐ณ Chef
Ruby DSL]
+ PU2[๐ถ Puppet
Declarative]
+ end
+
+ subgraph "โธ๏ธ Container/K8s"
+ K8[โธ๏ธ Kubernetes YAML
Declarative manifests]
+ HE[โ Helm
Templating engine]
+ KU[๐จ Kustomize
Overlay system]
+ end
+
+ Cloud[โ๏ธ Cloud Infrastructure] --> TF
+ Cloud --> PU
+ Cloud --> CF
+
+ Servers[๐ฅ๏ธ Servers/VMs] --> AN
+ Servers --> CH
+ Servers --> PU2
+
+ Containers[๐ณ Containers] --> K8[โธ๏ธ Kubernetes YAML]
+ Containers --> HE
+ Containers --> KU
+
+ style TF fill:#7B42BC,stroke:#5C2D91,stroke-width:2px,color:#fff
+ style PU fill:#8A3FFC,stroke:#6929C4,stroke-width:2px,color:#fff
+ style AN fill:#EE0000,stroke:#CC0000,stroke-width:2px,color:#fff
+```
+
+---
+
+### โ๏ธ Quick Comparison Matrix
+
+| Feature | Terraform | Pulumi | Ansible |
+|---------|-----------|--------|---------|
+| ๐ฃ๏ธ **Language** | HCL (custom DSL) | TypeScript, Python, Go, C#, Java | YAML |
+| ๐ฏ **Approach** | Declarative | Declarative (with code) | Imperative + Declarative |
+| โ๏ธ **Multi-cloud** | โ
Best-in-class | โ
Excellent | โ ๏ธ Limited |
+| ๐ง **Learning curve** | Medium | Medium-High (need programming) | Low-Medium |
+| ๐งช **Testing** | Limited (terratest) | โ
Full unit/integration tests | Medium (molecule) |
+| ๐ **Secrets** | Manual integration | โ
Built-in encryption | Ansible Vault |
+| ๐ **State mgmt** | Remote backends | Pulumi Cloud/self-hosted | No state (idempotent) |
+| ๐ฐ **Cost** | Open-source (Cloud paid) | Open-source (Cloud paid) | Open-source (Tower paid) |
+| ๐ข **Best for** | Infrastructure provisioning | Modern dev teams | Config management, VMs |
+
+
+๐ญ Interactive Question: Which tool would you choose for a greenfield cloud-native startup?
+
+**There's no single right answer!** But here's a thought framework:
+
+**Choose Terraform if:**
+* โ
Team is infrastructure-focused
+* โ
Need widest provider ecosystem
+* โ
Declarative mindset preferred
+* โ
Large community and examples available
+
+**Choose Pulumi if:**
+* โ
Team is developer-heavy
+* โ
Want full programming language power
+* โ
Need sophisticated testing
+* โ
Already using TypeScript/Python
+
+**Choose Ansible if:**
+* โ
Managing existing servers/VMs
+* โ
Configuration management is primary need
+* โ
Team prefers simple YAML
+* โ
Want agentless approach
+
+**Modern approach:** Many teams use **Terraform + Ansible** together:
+* Terraform provisions infrastructure
+* Ansible configures applications
+
+
+
+---
+
+## ๐ Slide 4 โ ๐ Common IaC Security Risks
+
+* ๐ **Hardcoded Secrets (43% of issues)**
+ * API keys, passwords, tokens in plain text
+ * Committed to version control โ permanent history
+ * Attackers scan GitHub for leaked credentials 24/7
+ * Example: `aws_access_key = "AKIAIOSFODNN7EXAMPLE"`
+* ๐ **Overly Permissive IAM/RBAC (38%)**
+ * `Action: "*"` โ grants ALL permissions
+ * `Resource: "*"` โ applies to ALL resources
+ * Service accounts with admin rights
+ * No least-privilege enforcement
+* ๐ **Public Exposure (31%)**
+ * S3 buckets with public read/write
+ * Databases accessible from `0.0.0.0/0`
+ * Security groups allowing all ports
+ * Load balancers exposing internal services
+* ๐ **Missing Encryption (29%)**
+ * Unencrypted storage (S3, EBS, databases)
+ * No encryption in transit (HTTP instead of HTTPS)
+ * Missing KMS key management
+ * Plaintext backups
+* ๐ **Compliance Violations (26%)**
+ * Missing required tags (cost center, environment)
+ * Resources in non-approved regions
+ * Violating data residency requirements
+ * No audit logging enabled
+
+```mermaid
+flowchart TD
+ subgraph "๐ฅ Top IaC Security Risks"
+ R1[๐ Hardcoded Secrets
43%]
+ R2[๐ Overly Permissive IAM
38%]
+ R3[๐ Public Exposure
31%]
+ R4[๐ Missing Encryption
29%]
+ R5[๐ Compliance Violations
26%]
+ end
+
+ R1 -->|Leads to| B1[๐ฅ Credential Theft]
+ R2 -->|Leads to| B2[๐ฅ Privilege Escalation]
+ R3 -->|Leads to| B3[๐ฅ Data Breach]
+ R4 -->|Leads to| B4[๐ฅ Data Exposure]
+ R5 -->|Leads to| B5[๐ฅ Regulatory Fines]
+
+ B1 --> Impact[๐ฅ Total Compromise]
+ B2 --> Impact
+ B3 --> Impact
+ B4 --> Impact
+ B5 --> Impact
+
+ style R1 fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style R2 fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style R3 fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style R4 fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style R5 fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Impact fill:#b71c1c,stroke:#d32f2f,stroke-width:3px,color:#fff
+```
+
+---
+
+### ๐ป Example: Vulnerable Terraform Code
+
+```hcl
+# โ INSECURE EXAMPLE - DO NOT USE IN PRODUCTION!
+
+# Risk 1: Hardcoded credentials
+provider "aws" {
+ region = "us-east-1"
+ access_key = "AKIAIOSFODNN7EXAMPLE" # ๐ฅ HARDCODED!
+ secret_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" # ๐ฅ LEAKED!
+}
+
+# Risk 2: Public S3 bucket
+resource "aws_s3_bucket" "data" {
+ bucket = "my-company-data"
+ acl = "public-read" # ๐ PUBLIC TO THE INTERNET!
+}
+
+# Risk 3: Overly permissive security group
+resource "aws_security_group" "web" {
+ ingress {
+ from_port = 0 # ๐ ALL PORTS!
+ to_port = 65535 # ๐ ALL PORTS!
+ protocol = "-1" # ๐ ALL PROTOCOLS!
+ cidr_blocks = ["0.0.0.0/0"] # ๐ FROM ANYWHERE!
+ }
+}
+
+# Risk 4: Unencrypted database
+resource "aws_db_instance" "main" {
+ engine = "postgres"
+ storage_encrypted = false # ๐ NO ENCRYPTION!
+ publicly_accessible = true # ๐ PUBLIC DATABASE!
+}
+
+# Risk 5: No encryption for EBS volume
+resource "aws_ebs_volume" "data" {
+ availability_zone = "us-east-1a"
+ size = 100
+ encrypted = false # ๐ PLAINTEXT DATA!
+}
+```
+
+
+๐ญ Challenge: How many security issues can you spot in the above code?
+
+**Found at least 8 critical issues:**
+
+1. โ Hardcoded AWS access key
+2. โ Hardcoded AWS secret key
+3. โ Public S3 bucket ACL
+4. โ Security group allows all ports from anywhere
+5. โ Database not encrypted
+6. โ Database publicly accessible
+7. โ EBS volume not encrypted
+8. โ No tags for compliance tracking
+9. โ No backup configuration
+10. โ No network segmentation
+
+**Real-world impact:** Code like this caused the Capital One breach!
+
+
+
+---
+
+## ๐ Slide 5 โ ๐งญ IaC in the DevSecOps Pipeline
+
+* ๐ **Shift-Left Security for Infrastructure**
+ * Catch issues **before deployment**, not after breach
+ * Test infrastructure code like application code
+ * Security as early feedback loop
+* ๐งช **IaC Testing Pyramid**
+ * ๐๏ธ **Unit tests** (80%) โ syntax, logic, basic checks
+ * ๐ **Integration tests** (15%) โ deploy to test env
+ * ๐ **Compliance tests** (5%) โ policy validation
+* ๐ **CI/CD Integration Points**
+ * ๐ **Pre-commit** โ local validation, secret scanning
+ * ๐ **Pull Request** โ automated security scans, policy checks
+ * ๐๏ธ **Build stage** โ terraform plan, cost estimation
+ * ๐งช **Test stage** โ deploy to staging, validate
+ * ๐ **Deploy stage** โ production deployment with approval
+ * ๐ **Runtime** โ drift detection, continuous monitoring
+
+```mermaid
+flowchart LR
+ subgraph "๐ Development"
+ Dev[๐จโ๐ป Write IaC] --> PreCommit[๐ Pre-commit Hooks]
+ PreCommit -->|Secret scan| LocalCheck{โ
Pass?}
+ LocalCheck -->|โ No| Fix[๐ง Fix Issues]
+ LocalCheck -->|โ
Yes| Commit[๐ค Git Commit]
+ end
+
+ subgraph "๐ CI/CD Pipeline"
+ Commit --> PR[๐ Pull Request]
+ PR --> Scan[๐ก๏ธ Security Scan
Checkov/tfsec]
+ Scan --> Policy[๐ Policy Check
OPA/Sentinel]
+ Policy --> Plan[๐ Terraform Plan]
+ Plan --> Review[๐ Manual Review]
+ Review -->|โ
Approve| Deploy[๐ Deploy to Staging]
+ Deploy --> Test[๐งช Integration Tests]
+ Test -->|โ
Pass| Prod[๐ Production Deploy]
+ end
+
+ subgraph "๐ Runtime"
+ Prod --> Monitor[๐ Drift Detection]
+ Monitor --> Alert[๐จ Security Alerts]
+ Alert -->|Issue found| Fix
+ end
+
+ style PreCommit fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Scan fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Policy fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ style Prod fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ GitOps Workflow for Infrastructure
+
+* ๐ฆ **Git as Single Source of Truth**
+ * All infrastructure code in version control
+ * Pull requests for any changes
+ * Automated testing on every commit
+* ๐ **Pull-Based Deployment**
+ * Agents watch Git repository
+ * Automatically apply approved changes
+ * Examples: Flux, ArgoCD (for Kubernetes), Terraform Cloud
+* ๐ก๏ธ **Security Benefits**
+ * ๐ Complete audit trail
+ * โฉ๏ธ Easy rollback to any previous state
+ * ๐ Drift detection (actual vs desired state)
+ * ๐ซ No direct production access needed
+
+```mermaid
+flowchart LR
+ subgraph "๐ Git Repository"
+ Code[๐ IaC Code
Terraform/Pulumi]
+ Policy[๐ Policies
OPA/Sentinel]
+ end
+
+ subgraph "๐ GitOps Operator"
+ Watch[๐๏ธ Watch for Changes]
+ Validate[โ
Validate & Test]
+ Apply[โก Auto-apply Changes]
+ end
+
+ subgraph "โ๏ธ Cloud Infrastructure"
+ Resources[๐๏ธ Infrastructure Resources]
+ State[๐ Actual State]
+ end
+
+ Code --> Watch
+ Policy --> Watch
+ Watch --> Validate
+ Validate --> Apply
+ Apply --> Resources
+ Resources --> State
+ State -.Drift Detection.-> Watch
+
+ style Code fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Validate fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Resources fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Security Testing Layers
+
+| Layer | Stage | Tools | Coverage | Speed |
+|-------|-------|-------|----------|-------|
+| ๐งช **Unit Tests** | Pre-commit | terraform validate, pulumi preview | Syntax, logic | โก Seconds |
+| ๐ **Security Scan** | PR/CI | Checkov, tfsec, Terrascan | Misconfigs, secrets | โก Seconds |
+| ๐ **Policy Check** | PR/CI | OPA, Sentinel, Conftest | Compliance rules | โก Seconds |
+| ๐ฐ **Cost Estimation** | PR/CI | Infracost, Terraform Cloud | Budget impact | โก Seconds |
+| ๐๏ธ **Integration Test** | Staging | Deploy + validate | Real environment | ๐ Minutes |
+| ๐ **Runtime Monitor** | Production | Drift detection, CSPM | Continuous | ๐ Ongoing |
+
+
+๐ญ Discussion: At which stage should security checks happen?
+
+**Answer: ALL OF THEM!** ๐ฏ
+
+**Defense in Depth approach:**
+
+1. **๐จโ๐ป Developer's machine (Pre-commit)**
+ * Fast feedback loop
+ * Catches obvious issues (syntax, secrets)
+ * No waiting for CI/CD
+
+2. **๐ Pull Request (CI/CD)**
+ * Automated security scans
+ * Policy enforcement
+ * Peer review
+ * Prevents bad code from merging
+
+3. **๐งช Staging Environment**
+ * Real-world testing
+ * Integration validation
+ * Final check before production
+
+4. **๐ Production (Runtime)**
+ * Continuous monitoring
+ * Drift detection
+ * Compliance audits
+ * Incident response
+
+**Remember:** Security is **not a checkpoint**, it's a **continuous process**!
+
+
+
+---
+
+## ๐ **Fun Break: Infrastructure Gone Wild!**
+
+### ๐ **"The $72,000 Cloud Bill Surprise"**
+
+A developer spun up "just a few instances" to test a machine learning model...
+
+* ๐ค Forgot to set instance size limits
+* โก Auto-scaling kicked in
+* ๐ Scaled to **500+ GPU instances**
+* ๐ธ Bill arrived: **$72,000** for the weekend
+* ๐ข Company lesson learned: **Always set budget alerts!**
+
+### ๐คฏ **IaC Horror Stories:**
+
+* ๐ชฃ **The S3 Bucket of Doom**: Company made bucket "temporarily public" for testing โ forgot to revert โ 10M customer records exposed
+* ๐ **The Terraform Destroy Disaster**: Junior dev ran `terraform destroy` thinking it was on testing environment โ **was production** โ entire infrastructure gone
+* ๐ **The GitHub Secret Leak**: Hardcoded AWS keys in Terraform โ pushed to public repo โ **$20K charged for crypto mining in 2 hours**
+* ๐ช **The Open Security Group**: Security group rule `0.0.0.0/0` โ **entire database cluster** accessible to internet โ ransomware attack
+
+### ๐ก **Key Lesson:**
+
+**"Automate security checks, because humans make mistakes... especially at 3 AM during deployments!"** โ๐ค
+
+---
+
+๐ **Resources for Group 1:**
+* [Infrastructure as Code Best Practices (AWS)](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)
+* [Terraform Security Best Practices (HashiCorp)](https://developer.hashicorp.com/terraform/tutorials/configuration-language/sensitive-variables)
+* [Cloud Security Misconfigurations (OWASP)](https://owasp.org/www-community/vulnerabilities/Cloud_Infrastructure_Misconfiguration)
+* [CIS Benchmarks for Cloud](https://www.cisecurity.org/benchmark/cloud_computing)
+
+---
+## ๐ Group 2: Terraform Security
+
+## ๐ Slide 6 โ ๐๏ธ Terraform Deep Dive & Security Concerns
+
+* ๐๏ธ **Terraform** = declarative IaC tool using HCL (HashiCorp Configuration Language)
+* ๐ **Workflow:** `init` โ `plan` โ `apply` โ `destroy`
+* ๐ **State file** = JSON file tracking all managed resources
+* โ ๏ธ **Critical security issue:** State files contain **secrets in plaintext!**
+ * Database passwords
+ * API keys
+ * Private keys
+ * Certificate data
+
+```mermaid
+flowchart LR
+ Write[๐ Write .tf files] --> Init[โ๏ธ terraform init]
+ Init --> Plan[๐ terraform plan]
+ Plan --> Apply[โก terraform apply]
+ Apply --> State[๐พ terraform.tfstate]
+ State -->|Contains| Secrets[๐ SECRETS IN PLAINTEXT!]
+
+ style State fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style Secrets fill:#b71c1c,stroke:#d32f2f,stroke-width:3px,color:#fff
+```
+
+### ๐ฅ State File Security Risks
+
+* ๐พ **Local state files:**
+ * โ Stored on developer's laptop (unencrypted)
+ * โ Can be committed to Git accidentally
+ * โ No access control
+ * โ No audit trail
+* โ๏ธ **Remote state backends (BETTER):**
+ * โ
S3 + DynamoDB (with encryption + locking)
+ * โ
Terraform Cloud (built-in security)
+ * โ
Azure Blob Storage (with encryption)
+ * โ
HashiCorp Consul (with ACLs)
+
+```hcl
+# โ LOCAL STATE (INSECURE)
+# terraform.tfstate stored locally - anyone with filesystem access can read secrets!
+
+# โ
REMOTE STATE WITH ENCRYPTION
+terraform {
+ backend "s3" {
+ bucket = "mycompany-terraform-state"
+ key = "prod/terraform.tfstate"
+ region = "us-east-1"
+ encrypt = true # โ
Encryption at rest
+ dynamodb_table = "terraform-lock" # โ
State locking
+ kms_key_id = "arn:aws:kms:..." # โ
KMS encryption
+ }
+}
+```
+
+---
+
+## ๐ Slide 7 โ ๐ Managing Secrets in Terraform
+
+### โ **Level 1: Hardcoded (NEVER DO THIS)**
+
+```hcl
+resource "aws_db_instance" "db" {
+ username = "admin"
+ password = "SuperSecret123!" # ๐ฅ IN VERSION CONTROL FOREVER!
+}
+```
+
+### โ ๏ธ **Level 2: Variables (BETTER, but not great)**
+
+```hcl
+# variables.tf
+variable "db_password" {
+ type = string
+ sensitive = true # Hides from logs
+}
+
+# main.tf
+resource "aws_db_instance" "db" {
+ password = var.db_password
+}
+
+# Run with: terraform apply -var="db_password=..."
+```
+
+### โ
**Level 3: Environment Variables (GOOD)**
+
+```hcl
+variable "db_password" {
+ type = string
+ sensitive = true
+}
+
+# Terminal:
+# export TF_VAR_db_password="secret"
+# terraform apply
+```
+
+### ๐ **Level 4: Secret Managers (BEST PRACTICE)**
+
+```hcl
+# Retrieve from AWS Secrets Manager
+data "aws_secretsmanager_secret_version" "db_password" {
+ secret_id = "prod/db/password"
+}
+
+resource "aws_db_instance" "db" {
+ password = data.aws_secretsmanager_secret_version.db_password.secret_string
+}
+```
+
+```hcl
+# Or HashiCorp Vault
+data "vault_generic_secret" "db_creds" {
+ path = "secret/database/prod"
+}
+
+resource "aws_db_instance" "db" {
+ username = data.vault_generic_secret.db_creds.data["username"]
+ password = data.vault_generic_secret.db_creds.data["password"]
+}
+```
+
+### ๐ **Dynamic Secrets (ENTERPRISE LEVEL)**
+
+```hcl
+# Vault generates temporary DB credentials
+resource "vault_database_secret_backend_role" "app" {
+ name = "app-role"
+ backend = vault_mount.db.path
+ db_name = "postgres"
+
+ creation_statements = [
+ "CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}'",
+ "GRANT SELECT ON mydb.* TO '{{name}}'@'%'"
+ ]
+
+ default_ttl = 3600 # 1 hour expiry
+ max_ttl = 7200
+}
+```
+
+
+๐ญ Challenge: Rank these from most to least secure
+
+**Ranking (Best to Worst):**
+
+1. ๐ฅ **Dynamic secrets from Vault** - Short-lived, auto-rotated, audited
+2. ๐ฅ **Secret Manager with rotation** - Centralized, encrypted, rotatable
+3. ๐ฅ **Environment variables** - Not in code, but still long-lived
+4. ๐ **Terraform variables with sensitive flag** - Better than nothing
+5. ๐ **Hardcoded in .tf files** - NEVER DO THIS!
+
+**Pro tip:** Combine approaches! Use Vault for app secrets, env vars for Terraform API tokens.
+
+
+---
+
+## ๐ Slide 8 โ ๐ก๏ธ Terraform Security Best Practices
+
+### ๐ **1. State File Security**
+
+```hcl
+terraform {
+ backend "s3" {
+ bucket = "terraform-state"
+ encrypt = true # โ
AES-256 encryption
+ kms_key_id = "arn:..." # โ
Customer managed key
+ dynamodb_table = "tf-lock" # โ
State locking
+
+ # โ
Bucket policy restricts access
+ # โ
Versioning enabled for rollback
+ # โ
MFA delete enabled
+ }
+}
+```
+
+### ๐ **2. Provider Version Pinning**
+
+```hcl
+# โ BAD: Unpinned versions
+terraform {
+ required_providers {
+ aws = {
+ source = "hashicorp/aws" # Any version! ๐ฅ
+ }
+ }
+}
+
+# โ
GOOD: Pinned versions
+terraform {
+ required_version = "~> 1.6.0" # Terraform version
+
+ required_providers {
+ aws = {
+ source = "hashicorp/aws"
+ version = "~> 5.0" # Provider version constraint
+ }
+ }
+}
+```
+
+### ๐ข **3. Module Security**
+
+```hcl
+# โ RISKY: Random internet module
+module "vpc" {
+ source = "github.com/random-user/terraform-vpc" # ๐ฅ Untrusted!
+}
+
+# โ
BETTER: Terraform Registry (verified)
+module "vpc" {
+ source = "terraform-aws-modules/vpc/aws"
+ version = "5.1.0" # Specific version
+}
+
+# ๐ BEST: Private registry or Git with commit hash
+module "vpc" {
+ source = "git::ssh://git@github.com/mycompany/terraform-modules.git//vpc?ref=v1.2.3"
+}
+```
+
+### ๐ **4. Environment Separation**
+
+```hcl
+# Use workspaces or separate state files
+terraform {
+ backend "s3" {
+ bucket = "terraform-state"
+ key = "${terraform.workspace}/terraform.tfstate" # dev/staging/prod
+ }
+}
+
+# Or separate directories with tfvars
+# /terraform/dev/terraform.tfvars
+# /terraform/staging/terraform.tfvars
+# /terraform/prod/terraform.tfvars
+```
+
+### ๐ **5. Pre-commit Hooks**
+
+```bash
+# .pre-commit-config.yaml
+repos:
+ - repo: https://github.com/antonbabenko/pre-commit-terraform
+ hooks:
+ - id: terraform_fmt # โ
Format code
+ - id: terraform_validate # โ
Validate syntax
+ - id: terraform_tfsec # โ
Security scan
+ - id: terraform_docs # โ
Generate docs
+
+ - repo: https://github.com/gitleaks/gitleaks
+ hooks:
+ - id: gitleaks # โ
Scan for secrets
+```
+
+### ๐ **Quick Checklist**
+
+| Practice | Priority | Effort | Impact |
+|----------|----------|--------|--------|
+| Remote encrypted state | ๐ด Critical | Low | High |
+| Secret manager integration | ๐ด Critical | Medium | High |
+| Version pinning | ๐ก High | Low | Medium |
+| Security scanning (tfsec) | ๐ก High | Low | High |
+| State locking | ๐ก High | Low | High |
+| Module vetting | ๐ข Medium | Medium | Medium |
+| Pre-commit hooks | ๐ข Medium | Low | Medium |
+
+
+๐ญ Discussion: Should you commit terraform.tfstate to Git?
+
+**ABSOLUTELY NOT! โโโ**
+
+**Why it's dangerous:**
+* Contains secrets in plaintext
+* Anyone with repo access sees credentials
+* Git history preserves old secrets forever
+* No access control or audit trail
+* Can't handle concurrent modifications
+
+**What to commit:**
+* โ
`.tf` files (infrastructure code)
+* โ
`.tfvars.example` (template, no real values)
+* โ
`README.md` (documentation)
+* โ `.tfstate` files (add to `.gitignore`)
+* โ `.tfvars` with real secrets (add to `.gitignore`)
+* โ `.terraform/` directory (add to `.gitignore`)
+
+**Always use remote state backends!**
+
+
+---
+
+## ๐ Slide 9 โ ๐ป Hands-On: Secure Terraform Workflow
+
+### ๐ **Step 1: Scan Vulnerable Code**
+
+```hcl
+# vulnerable.tf - Find the issues!
+resource "aws_s3_bucket" "data" {
+ bucket = "company-data"
+ acl = "public-read"
+}
+
+resource "aws_instance" "web" {
+ ami = "ami-12345"
+ instance_type = "t2.micro"
+
+ metadata_options {
+ http_tokens = "optional" # IMDSv1 enabled
+ }
+}
+
+resource "aws_security_group" "allow_all" {
+ ingress {
+ from_port = 0
+ to_port = 65535
+ protocol = "tcp"
+ cidr_blocks = ["0.0.0.0/0"]
+ }
+}
+```
+
+### ๐ ๏ธ **Step 2: Run Security Scanners**
+
+```bash
+# tfsec - Fast Terraform security scanner
+$ tfsec .
+
+Result #1 HIGH AWS S3 bucket is publicly accessible
+โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
+ vulnerable.tf:3
+โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
+ 3 acl = "public-read"
+โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
+
+Result #2 HIGH Instance Metadata Service v1 enabled
+โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
+ vulnerable.tf:11
+โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
+ 11 http_tokens = "optional"
+โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
+
+Result #3 CRITICAL Security group allows ingress from 0.0.0.0/0
+โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
+ vulnerable.tf:19
+โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
+ 19 cidr_blocks = ["0.0.0.0/0"]
+โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
+
+3 potential problems detected.
+```
+
+```bash
+# Checkov - Policy-as-code scanner
+$ checkov -f vulnerable.tf
+
+Check: CKV_AWS_20: "S3 Bucket has an ACL defined which allows public READ access"
+ FAILED for resource: aws_s3_bucket.data
+ File: /vulnerable.tf:1-4
+
+Check: CKV_AWS_79: "Ensure Instance Metadata Service Version 1 is not enabled"
+ FAILED for resource: aws_instance.web
+ File: /vulnerable.tf:6-14
+
+Check: CKV_AWS_24: "Ensure no security groups allow ingress from 0.0.0.0:0 to port 22"
+ FAILED for resource: aws_security_group.allow_all
+ File: /vulnerable.tf:16-23
+```
+
+### โ
**Step 3: Fix Security Issues**
+
+```hcl
+# secure.tf - Fixed version
+resource "aws_s3_bucket" "data" {
+ bucket = "company-data"
+}
+
+resource "aws_s3_bucket_public_access_block" "data" {
+ bucket = aws_s3_bucket.data.id
+
+ block_public_acls = true
+ block_public_policy = true
+ ignore_public_acls = true
+ restrict_public_buckets = true
+}
+
+resource "aws_s3_bucket_server_side_encryption_configuration" "data" {
+ bucket = aws_s3_bucket.data.id
+
+ rule {
+ apply_server_side_encryption_by_default {
+ sse_algorithm = "AES256"
+ }
+ }
+}
+
+resource "aws_instance" "web" {
+ ami = "ami-12345"
+ instance_type = "t2.micro"
+
+ metadata_options {
+ http_tokens = "required" # โ
IMDSv2 only
+ http_endpoint = "enabled"
+ }
+
+ root_block_device {
+ encrypted = true # โ
Encrypt root volume
+ }
+}
+
+resource "aws_security_group" "web" {
+ name = "web-sg"
+
+ ingress {
+ description = "HTTPS from VPC"
+ from_port = 443
+ to_port = 443
+ protocol = "tcp"
+ cidr_blocks = ["10.0.0.0/16"] # โ
VPC only
+ }
+
+ egress {
+ from_port = 0
+ to_port = 0
+ protocol = "-1"
+ cidr_blocks = ["0.0.0.0/0"]
+ }
+}
+```
+
+### ๐ **Step 4: CI/CD Integration**
+
+```yaml
+# .github/workflows/terraform.yml
+name: Terraform Security
+
+on: [pull_request]
+
+jobs:
+ security:
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/checkout@v3
+
+ - name: Setup Terraform
+ uses: hashicorp/setup-terraform@v2
+
+ - name: Terraform Format Check
+ run: terraform fmt -check -recursive
+
+ - name: Terraform Init
+ run: terraform init -backend=false
+
+ - name: Terraform Validate
+ run: terraform validate
+
+ - name: Run tfsec
+ uses: aquasecurity/tfsec-action@v1.0.0
+ with:
+ soft_fail: false # โ Fail on issues
+
+ - name: Run Checkov
+ uses: bridgecrewio/checkov-action@master
+ with:
+ framework: terraform
+ soft_fail: false # โ Fail on issues
+
+ - name: Terraform Plan
+ run: terraform plan
+ env:
+ AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
+ AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
+```
+
+### ๐ **Before vs After Comparison**
+
+| Metric | Before | After |
+|--------|--------|-------|
+| ๐ด Critical issues | 3 | 0 |
+| ๐ก High issues | 5 | 0 |
+| ๐ข Medium issues | 12 | 2 |
+| โก Scan time | - | 5 seconds |
+| โ
CI/CD pass | โ | โ
|
+
+
+๐ญ Exercise: What other tools would you add to this pipeline?
+
+**Additional tools to consider:**
+
+1. **Cost estimation:**
+ * ๐ฐ Infracost - Estimates cloud costs before deployment
+ * Shows cost impact in PR comments
+
+2. **Compliance checks:**
+ * ๐ Terraform Compliance - BDD-style policy testing
+ * Tests against regulatory requirements
+
+3. **Secrets scanning:**
+ * ๐ Gitleaks - Detect hardcoded secrets
+ * TruffleHog - Find secrets in Git history
+
+4. **Drift detection:**
+ * ๐ Driftctl - Compare actual vs Terraform state
+ * Terraform Cloud - Built-in drift detection
+
+5. **Documentation:**
+ * ๐ terraform-docs - Auto-generate README
+ * Keeps docs in sync with code
+
+6. **Policy-as-code:**
+ * ๐ฏ OPA/Conftest - Custom policy checks
+ * Sentinel - Terraform Cloud policies
+
+**Example enhanced workflow:**
+```yaml
+- name: Cost Estimation
+ run: infracost breakdown --path .
+
+- name: Compliance Testing
+ run: terraform-compliance -f compliance/ -p plan.json
+
+- name: Secrets Scan
+ run: gitleaks detect --source . --verbose
+```
+
+
+---
+
+๐ **Terraform Security Resources:**
+* [Terraform Security Best Practices (HashiCorp)](https://developer.hashicorp.com/terraform/tutorials/configuration-language/sensitive-variables)
+* [tfsec Documentation](https://aquasecurity.github.io/tfsec/)
+* [Checkov Policies](https://www.checkov.io/5.Policy%20Index/terraform.html)
+* [Terraform AWS Secure Baseline](https://github.com/nozaq/terraform-aws-secure-baseline)
+
+---
+## ๐ Group 3: Pulumi Security
+
+## ๐ Slide 10 โ ๐ Pulumi Overview & Security Model
+
+* ๐ **Pulumi** = IaC using real programming languages (TypeScript, Python, Go, C#, Java)
+* ๐ **vs Terraform:** Code instead of DSL, full programming features, built-in testing
+* ๐ **Built-in secrets encryption** (automatic, no extra config needed)
+
+```typescript
+// TypeScript example
+import * as aws from "@pulumi/aws";
+import * as pulumi from "@pulumi/pulumi";
+
+const bucket = new aws.s3.Bucket("secure-bucket", {
+ acl: "private",
+ serverSideEncryptionConfiguration: {
+ rule: {
+ applyServerSideEncryptionByDefault: {
+ sseAlgorithm: "AES256",
+ },
+ },
+ },
+});
+
+export const bucketName = bucket.id;
+```
+
+```python
+# Python example
+import pulumi
+import pulumi_aws as aws
+
+bucket = aws.s3.Bucket("secure-bucket",
+ acl="private",
+ server_side_encryption_configuration={
+ "rule": {
+ "apply_server_side_encryption_by_default": {
+ "sse_algorithm": "AES256",
+ },
+ },
+ })
+
+pulumi.export("bucket_name", bucket.id)
+```
+
+### ๐ Automatic Secrets Management
+
+```typescript
+// Secrets are automatically encrypted in state!
+const config = new pulumi.Config();
+const dbPassword = config.requireSecret("dbPassword"); // ๐ Auto-encrypted
+
+const db = new aws.rds.Instance("db", {
+ engine: "postgres",
+ password: dbPassword, // โ
Encrypted in state
+ storageEncrypted: true,
+});
+
+// Secret outputs are also encrypted
+export const connectionString = pulumi.secret(
+ pulumi.interpolate`postgres://admin:${dbPassword}@${db.endpoint}`
+);
+```
+
+### ๐ Encryption Options
+
+```bash
+# Default: Pulumi service (managed)
+$ pulumi stack init prod
+
+# Passphrase (self-managed)
+$ pulumi stack init prod --secrets-provider=passphrase
+$ export PULUMI_CONFIG_PASSPHRASE="strong-password"
+
+# AWS KMS
+$ pulumi stack init prod --secrets-provider="awskms://alias/pulumi-secrets?region=us-east-1"
+
+# Azure Key Vault
+$ pulumi stack init prod --secrets-provider="azurekeyvault://myvault.vault.azure.net/keys/pulumi"
+
+# GCP KMS
+$ pulumi stack init prod --secrets-provider="gcpkms://projects/my-project/locations/us/keyRings/my-keyring/cryptoKeys/my-key"
+```
+
+
+๐ญ Quiz: What happens if you print a secret in Pulumi?
+
+```typescript
+const secret = config.requireSecret("apiKey");
+console.log(secret); // What gets printed?
+```
+
+**Answer:** `[secret]` ๐
+
+Pulumi automatically redacts secrets in:
+* Console output
+* Logs
+* Stack exports (unless explicitly outputting as secret)
+* API responses
+
+**To actually use the value:**
+```typescript
+secret.apply(value => {
+ // value is the actual string here
+ // Use it carefully!
+});
+```
+
+**This prevents accidental leaks!**
+
+
+---
+
+## ๐ Slide 11 โ ๐งฉ Pulumi Policy-as-Code (CrossGuard)
+
+* ๐ **CrossGuard** = policy-as-code framework for Pulumi
+* ๐ฏ **Policies:** Mandatory (block) or Advisory (warn)
+* ๐ป Written in TypeScript or Python
+
+### ๐ Example Policy: Block Public S3 Buckets
+
+```typescript
+// policy.ts
+import * as aws from "@pulumi/aws";
+import { PolicyPack, validateResourceOfType } from "@pulumi/policy";
+
+new PolicyPack("aws-policies", {
+ policies: [{
+ name: "s3-no-public-read",
+ description: "S3 buckets must not be publicly readable",
+ enforcementLevel: "mandatory", // Blocks deployment!
+ validateResource: validateResourceOfType(aws.s3.Bucket, (bucket, args, reportViolation) => {
+ if (bucket.acl === "public-read" || bucket.acl === "public-read-write") {
+ reportViolation("S3 bucket must not have public ACL");
+ }
+ }),
+ }, {
+ name: "s3-encryption-required",
+ description: "S3 buckets must be encrypted",
+ enforcementLevel: "mandatory",
+ validateResource: validateResourceOfType(aws.s3.Bucket, (bucket, args, reportViolation) => {
+ if (!bucket.serverSideEncryptionConfiguration) {
+ reportViolation("S3 bucket must have encryption enabled");
+ }
+ }),
+ }, {
+ name: "required-tags",
+ description: "Resources must have required tags",
+ enforcementLevel: "advisory", // Just warns
+ validateResource: (args, reportViolation) => {
+ if (args.type.startsWith("aws:") && !args.props.tags) {
+ reportViolation("Resource should have tags");
+ }
+ },
+ }],
+});
+```
+
+```python
+# policy.py
+from pulumi_policy import (
+ EnforcementLevel,
+ PolicyPack,
+ ResourceValidationPolicy,
+)
+
+def s3_no_public_acl(args, report_violation):
+ if args.resource_type == "aws:s3/bucket:Bucket":
+ acl = args.props.get("acl")
+ if acl in ["public-read", "public-read-write"]:
+ report_violation("S3 bucket must not be public")
+
+PolicyPack(
+ name="aws-python-policies",
+ enforcement_level=EnforcementLevel.MANDATORY,
+ policies=[
+ ResourceValidationPolicy(
+ name="s3-no-public-acl",
+ description="S3 buckets cannot be public",
+ validate=s3_no_public_acl,
+ ),
+ ],
+)
+```
+
+### ๐ Using Policies
+
+```bash
+# Enable policy pack locally
+$ pulumi policy enable policy-pack/
+
+# Preview with policies
+$ pulumi preview
+Previewing update (dev)
+
+Policy Violations:
+ โ s3-no-public-read (mandatory)
+ S3 bucket must not have public ACL
+ aws:s3:Bucket (my-bucket)
+
+# Policy blocks deployment!
+error: preview failed
+
+# Fix the issue and try again
+$ pulumi up
+โ
All policies passed!
+```
+
+### ๐ฆ Policy Pack Management
+
+```bash
+# Publish policy pack to Pulumi Cloud
+$ pulumi policy publish org-name/aws-policies
+
+# Enforce organization-wide
+$ pulumi policy enable org-name/aws-policies --policy-group production
+
+# Different policies for different stacks
+$ pulumi policy enable dev-policies --policy-group development
+```
+
+---
+
+## ๐ Slide 12 โ ๐ป Hands-On: Secure Pulumi Deployment
+
+### ๐ Secure AWS S3 Bucket Example
+
+```typescript
+// index.ts - Secure S3 bucket with Pulumi
+import * as pulumi from "@pulumi/pulumi";
+import * as aws from "@pulumi/aws";
+
+// Get config
+const config = new pulumi.Config();
+const environment = config.require("environment");
+const kmsKeyId = config.requireSecret("kmsKeyId");
+
+// Create KMS-encrypted S3 bucket
+const bucket = new aws.s3.Bucket("app-data", {
+ acl: "private",
+
+ // โ
Block all public access
+ blockPublicAcls: true,
+ blockPublicPolicy: true,
+ ignorePublicAcls: true,
+ restrictPublicBuckets: true,
+
+ // โ
Enable versioning
+ versioning: {
+ enabled: true,
+ },
+
+ // โ
KMS encryption
+ serverSideEncryptionConfiguration: {
+ rule: {
+ applyServerSideEncryptionByDefault: {
+ sseAlgorithm: "aws:kms",
+ kmsMasterKeyId: kmsKeyId,
+ },
+ bucketKeyEnabled: true,
+ },
+ },
+
+ // โ
Lifecycle rules
+ lifecycleRules: [{
+ enabled: true,
+ transitions: [{
+ days: 30,
+ storageClass: "STANDARD_IA",
+ }, {
+ days: 90,
+ storageClass: "GLACIER",
+ }],
+ }],
+
+ // โ
Logging
+ loggings: [{
+ targetBucket: logBucket.id,
+ targetPrefix: "s3-access-logs/",
+ }],
+
+ // โ
Tags
+ tags: {
+ Environment: environment,
+ ManagedBy: "Pulumi",
+ Encrypted: "true",
+ },
+});
+
+// โ
Bucket policy - deny unencrypted uploads
+const bucketPolicy = new aws.s3.BucketPolicy("app-data-policy", {
+ bucket: bucket.id,
+ policy: bucket.arn.apply(arn => JSON.stringify({
+ Version: "2012-10-17",
+ Statement: [{
+ Sid: "DenyUnencryptedUploads",
+ Effect: "Deny",
+ Principal: "*",
+ Action: "s3:PutObject",
+ Resource: `${arn}/*`,
+ Condition: {
+ StringNotEquals: {
+ "s3:x-amz-server-side-encryption": "aws:kms"
+ }
+ }
+ }]
+ })),
+});
+
+// Export (bucketName is public, encryption key is secret)
+export const bucketName = bucket.id;
+export const bucketArn = bucket.arn;
+export const encryptionKey = pulumi.secret(kmsKeyId);
+```
+
+### ๐งช Testing Infrastructure Code
+
+```typescript
+// index.test.ts - Unit tests for Pulumi
+import * as pulumi from "@pulumi/pulumi";
+import * as aws from "@pulumi/aws";
+import "mocha";
+
+pulumi.runtime.setMocks({
+ newResource: function(args: pulumi.runtime.MockResourceArgs): {id: string, state: any} {
+ return {
+ id: args.inputs.name + "_id",
+ state: args.inputs,
+ };
+ },
+ call: function(args: pulumi.runtime.MockCallArgs) {
+ return args.inputs;
+ },
+});
+
+describe("S3 Bucket Security", function() {
+ let bucket: aws.s3.Bucket;
+
+ before(async function() {
+ const infra = await import("./index");
+ // Load the infrastructure
+ });
+
+ it("bucket must have private ACL", function(done) {
+ pulumi.all([bucket.acl]).apply(([acl]) => {
+ if (acl !== "private") {
+ done(new Error("Bucket must be private"));
+ } else {
+ done();
+ }
+ });
+ });
+
+ it("bucket must have encryption", function(done) {
+ pulumi.all([bucket.serverSideEncryptionConfiguration]).apply(([encryption]) => {
+ if (!encryption) {
+ done(new Error("Bucket must be encrypted"));
+ } else {
+ done();
+ }
+ });
+ });
+
+ it("bucket must block public access", function(done) {
+ pulumi.all([
+ bucket.blockPublicAcls,
+ bucket.blockPublicPolicy,
+ bucket.ignorePublicAcls,
+ bucket.restrictPublicBuckets
+ ]).apply(([acls, policy, ignore, restrict]) => {
+ if (!acls || !policy || !ignore || !restrict) {
+ done(new Error("Bucket must block all public access"));
+ } else {
+ done();
+ }
+ });
+ });
+});
+```
+
+### ๐ CI/CD Integration
+
+```yaml
+# .github/workflows/pulumi.yml
+name: Pulumi
+
+on:
+ pull_request:
+ branches: [main]
+
+jobs:
+ preview:
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/checkout@v3
+
+ - uses: actions/setup-node@v3
+ with:
+ node-version: 18
+
+ - name: Install dependencies
+ run: npm install
+
+ - name: Run tests
+ run: npm test
+
+ - name: Pulumi Preview
+ uses: pulumi/actions@v4
+ with:
+ command: preview
+ stack-name: dev
+ env:
+ PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
+ AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
+ AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
+
+ - name: Run Policy Check
+ run: pulumi policy enable aws-policies && pulumi preview
+```
+
+
+๐ญ Comparison: Pulumi vs Terraform - Which is more secure by default?
+
+**Pulumi advantages:**
+* โ
Secrets encrypted automatically (no config needed)
+* โ
Built-in testing frameworks (unit/integration)
+* โ
Type safety (compile-time checks)
+* โ
Secret outputs protected by default
+* โ
Programming language tooling (linters, IDEs)
+
+**Terraform advantages:**
+* โ
Declarative = easier to audit
+* โ
Larger ecosystem and examples
+* โ
More mature security tooling (tfsec, Checkov)
+* โ
HCL is simpler for infrastructure-only teams
+
+**Verdict:** Pulumi has **better security defaults**, but Terraform has **more security tooling**.
+
+**Best practice:** Choose based on team skills:
+- DevOps/Infra teams โ Terraform
+- Software dev teams โ Pulumi
+
+
+---
+
+## ๐ Group 4: Ansible Security
+
+## ๐ Slide 13 โ โ๏ธ Ansible Overview & Security Challenges
+
+* โ๏ธ **Ansible** = agentless automation via SSH (Python)
+* ๐ **Playbooks** = YAML files defining tasks
+* ๐ **Idempotent** = safe to run multiple times
+* โ ๏ธ **Security risks:** SSH keys, privileged operations, secrets in playbooks
+
+```yaml
+# Basic playbook structure
+---
+- name: Configure web servers
+ hosts: webservers
+ become: yes # Run as root/sudo
+
+ tasks:
+ - name: Install nginx
+ apt:
+ name: nginx
+ state: present
+
+ - name: Copy config
+ template:
+ src: nginx.conf.j2
+ dest: /etc/nginx/nginx.conf
+ notify: restart nginx
+
+ handlers:
+ - name: restart nginx
+ service:
+ name: nginx
+ state: restarted
+```
+
+### ๐ Ansible Vault - Encrypt Secrets
+
+```bash
+# Create encrypted file
+$ ansible-vault create secrets.yml
+New Vault password: ****
+Confirm: ****
+
+# Edit encrypted file
+$ ansible-vault edit secrets.yml
+
+# View encrypted file
+$ ansible-vault view secrets.yml
+
+# Encrypt existing file
+$ ansible-vault encrypt vars.yml
+
+# Decrypt file
+$ ansible-vault decrypt vars.yml
+```
+
+```yaml
+# secrets.yml (encrypted)
+---
+db_password: "SuperSecret123!"
+api_key: "sk-1234567890abcdef"
+ssl_private_key: |
+ -----BEGIN PRIVATE KEY-----
+ MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC...
+ -----END PRIVATE KEY-----
+```
+
+### ๐ Using Vault in Playbooks
+
+```yaml
+# playbook.yml
+---
+- name: Deploy application
+ hosts: app_servers
+ vars_files:
+ - secrets.yml # Encrypted with ansible-vault
+
+ tasks:
+ - name: Create database
+ postgresql_db:
+ name: myapp
+ login_password: "{{ db_password }}" # From vault
+
+ - name: Configure API
+ template:
+ src: config.j2
+ dest: /etc/app/config.yml
+ vars:
+ api_key: "{{ api_key }}" # From vault
+```
+
+```bash
+# Run with vault password
+$ ansible-playbook playbook.yml --ask-vault-pass
+
+# Or use password file
+$ ansible-playbook playbook.yml --vault-password-file ~/.vault_pass
+
+# Or environment variable
+$ export ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass
+$ ansible-playbook playbook.yml
+```
+
+
+๐ญ Quiz: What happens if you print a vaulted variable?
+
+```yaml
+- name: Debug secret
+ debug:
+ msg: "Password is {{ db_password }}"
+```
+
+**Answer:** It prints in plaintext! ๐ฅ
+
+**To prevent leaks, use `no_log`:**
+```yaml
+- name: Set password
+ shell: "mysql -p{{ db_password }} ..."
+ no_log: true # โ
Hides output from logs
+```
+
+**Best practice:** Always use `no_log: true` with secrets!
+
+
+---
+
+## ๐ Slide 14 โ ๐ก๏ธ Ansible Security Best Practices
+
+### ๐ 1. No Logs for Secrets
+
+```yaml
+# โ BAD: Secrets in logs
+- name: Configure database
+ postgresql_db:
+ login_password: "{{ db_password }}"
+ register: result
+
+- name: Show result
+ debug:
+ var: result # ๐ฅ Password visible in logs!
+
+# โ
GOOD: Hide sensitive output
+- name: Configure database
+ postgresql_db:
+ login_password: "{{ db_password }}"
+ no_log: true # โ
Redacts from logs
+
+- name: Execute command with secret
+ shell: "curl -H 'Authorization: Bearer {{ api_token }}' ..."
+ no_log: true
+ register: api_result
+```
+
+### ๐ 2. SSH Key Management
+
+```yaml
+# Use SSH keys, not passwords
+[webservers]
+server1 ansible_host=192.168.1.10 ansible_user=deploy
+
+# SSH config
+$ cat ~/.ssh/config
+Host server1
+ HostName 192.168.1.10
+ User deploy
+ IdentityFile ~/.ssh/deploy_key
+ StrictHostKeyChecking yes
+
+# Vault SSH keys if storing in repo
+$ ansible-vault encrypt files/deploy_key
+```
+
+### ๐ฎ 3. Least Privilege
+
+```yaml
+# โ BAD: Always run as root
+- name: Install package
+ become: yes
+ become_user: root
+ apt: name=nginx
+
+# โ
GOOD: Only escalate when needed
+- name: Install package
+ apt: name=nginx
+ become: yes # Only for this task
+
+- name: Copy user file
+ copy:
+ src: app.conf
+ dest: ~/app.conf
+ # No become - runs as regular user
+```
+
+### ๐งน 4. Ansible Lint
+
+```bash
+# Install
+$ pip install ansible-lint
+
+# Run
+$ ansible-lint playbook.yml
+
+# Example output
+playbook.yml:
+ [201] Trailing whitespace
+ [206] Variables should have spaces before and after: {{ var_name }}
+ [301] Commands should not change things if nothing needs doing
+ [305] Use shell only when shell functionality is required
+ [503] Tasks that run when changed should likely be handlers
+```
+
+```yaml
+# .ansible-lint config
+---
+skip_list:
+ - '301' # Sometimes we need non-idempotent tasks
+
+warn_list:
+ - experimental
+ - role-name
+
+exclude_paths:
+ - .github/
+ - test/
+```
+
+### ๐ข 5. Ansible Tower/AWX
+
+* ๐ Centralized credential management
+* ๐ฅ RBAC for playbook execution
+* ๐ Audit logs of all runs
+* ๐ Scheduled jobs with approval workflows
+* ๐ Self-service infrastructure for developers
+
+
+๐ญ Exercise: Secure this playbook
+
+```yaml
+# insecure.yml - Find the issues!
+---
+- hosts: all
+ become: yes
+ tasks:
+ - name: Set root password
+ shell: "echo 'root:{{ root_password }}' | chpasswd"
+
+ - name: Download script
+ get_url:
+ url: http://example.com/script.sh
+ dest: /tmp/script.sh
+ mode: 0777
+
+ - name: Run script
+ shell: bash /tmp/script.sh
+
+ - name: Show database connection
+ debug:
+ msg: "DB: postgresql://admin:{{ db_pass }}@localhost/app"
+```
+
+**Issues found:**
+1. โ No `no_log` on password change
+2. โ HTTP instead of HTTPS
+3. โ Overly permissive file mode (0777)
+4. โ Running untrusted script
+5. โ Database password in debug output
+6. โ Using shell instead of proper module
+
+**Fixed version:**
+```yaml
+---
+- hosts: all
+ become: yes
+ tasks:
+ - name: Set root password
+ user:
+ name: root
+ password: "{{ root_password | password_hash('sha512') }}"
+ no_log: true
+
+ - name: Download script
+ get_url:
+ url: https://example.com/script.sh
+ dest: /tmp/script.sh
+ mode: 0750
+ checksum: sha256:abc123...
+
+ - name: Run script
+ script: /tmp/script.sh
+ args:
+ creates: /var/app/installed
+ no_log: true
+
+ # Remove debug statement entirely!
+```
+
+
+---
+
+## ๐ Slide 15 โ ๐ป Hands-On: Secure Ansible Playbook
+
+### ๐ Secure Web Server Deployment
+
+```yaml
+# site.yml - Main playbook
+---
+- name: Deploy secure web application
+ hosts: webservers
+ become: yes
+ vars_files:
+ - vault.yml # Encrypted secrets
+
+ pre_tasks:
+ - name: Update apt cache
+ apt:
+ update_cache: yes
+ cache_valid_time: 3600
+
+ roles:
+ - common
+ - security
+ - nginx
+ - app
+
+ post_tasks:
+ - name: Verify deployment
+ uri:
+ url: "https://{{ inventory_hostname }}"
+ validate_certs: yes
+ delegate_to: localhost
+```
+
+```yaml
+# roles/security/tasks/main.yml - Security hardening
+---
+- name: Install security updates
+ apt:
+ upgrade: dist
+ update_cache: yes
+ register: updates
+
+- name: Configure firewall
+ ufw:
+ rule: allow
+ port: "{{ item }}"
+ proto: tcp
+ loop:
+ - 22 # SSH
+ - 443 # HTTPS
+ no_log: true
+
+- name: Enable firewall
+ ufw:
+ state: enabled
+ policy: deny
+
+- name: Disable root login
+ lineinfile:
+ path: /etc/ssh/sshd_config
+ regexp: '^PermitRootLogin'
+ line: 'PermitRootLogin no'
+ notify: restart sshd
+
+- name: Require SSH key auth
+ lineinfile:
+ path: /etc/ssh/sshd_config
+ regexp: '^PasswordAuthentication'
+ line: 'PasswordAuthentication no'
+ notify: restart sshd
+
+- name: Install fail2ban
+ apt:
+ name: fail2ban
+ state: present
+
+- name: Configure fail2ban
+ template:
+ src: jail.local.j2
+ dest: /etc/fail2ban/jail.local
+ notify: restart fail2ban
+
+handlers:
+ - name: restart sshd
+ service:
+ name: sshd
+ state: restarted
+
+ - name: restart fail2ban
+ service:
+ name: fail2ban
+ state: restarted
+```
+
+```yaml
+# vault.yml (encrypted)
+---
+ssl_cert: |
+ -----BEGIN CERTIFICATE-----
+ ...
+ssl_key: |
+ -----BEGIN PRIVATE KEY-----
+ ...
+db_password: "SuperSecure123!"
+app_secret_key: "random-secret-key"
+```
+
+### ๐งช Testing with Molecule
+
+```bash
+# Install molecule
+$ pip install molecule[docker]
+
+# Initialize molecule
+$ molecule init scenario
+
+# Run tests
+$ molecule test
+```
+
+```yaml
+# molecule/default/molecule.yml
+---
+dependency:
+ name: galaxy
+driver:
+ name: docker
+platforms:
+ - name: instance
+ image: ubuntu:22.04
+ pre_build_image: true
+provisioner:
+ name: ansible
+verifier:
+ name: ansible
+```
+
+```yaml
+# molecule/default/verify.yml - Test security
+---
+- name: Verify
+ hosts: all
+ tasks:
+ - name: Check firewall enabled
+ command: ufw status
+ register: ufw_status
+ changed_when: false
+
+ - name: Assert firewall is active
+ assert:
+ that:
+ - "'Status: active' in ufw_status.stdout"
+
+ - name: Check SSH config
+ shell: grep "^PermitRootLogin no" /etc/ssh/sshd_config
+ changed_when: false
+
+ - name: Check HTTPS accessible
+ uri:
+ url: https://localhost
+ validate_certs: no
+ delegate_to: localhost
+```
+
+### ๐ CI/CD Integration
+
+```yaml
+# .github/workflows/ansible.yml
+name: Ansible CI
+
+on: [push, pull_request]
+
+jobs:
+ lint:
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/checkout@v3
+ - uses: actions/setup-python@v4
+ with:
+ python-version: '3.10'
+ - name: Install dependencies
+ run: pip install ansible ansible-lint
+ - name: Run ansible-lint
+ run: ansible-lint site.yml
+
+ test:
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/checkout@v3
+ - name: Run molecule tests
+ run: |
+ pip install molecule[docker]
+ molecule test
+```
+
+
+๐ญ Pro Tip: Ansible Tower vs AWX vs Semaphore
+
+**Ansible Tower (Red Hat):**
+* ๐ฐ Commercial ($$$)
+* ๐ข Enterprise support
+* ๐ Advanced reporting
+* ๐ HA clustering built-in
+
+**AWX (Open Source):**
+* ๐ Free (upstream of Tower)
+* ๐ Frequent updates
+* ๐ณ Container-based
+* โ ๏ธ Less stable
+
+**Semaphore (Open Source):**
+* ๐ Free alternative
+* ๐ Modern UI
+* ๐ณ Lightweight
+* โก Fast and simple
+
+**Choose based on:**
+- Need support? โ Tower
+- Want latest features? โ AWX
+- Want simplicity? โ Semaphore
+- Small team? โ Just use Git + CLI
+
+
+---
+
+## ๐ Fun Break: "Ansible Disaster Stories"
+
+### ๐ฑ **"The Playbook That Deleted Production"**
+
+```yaml
+# Someone wrote this...
+- name: Clean old files
+ file:
+ path: "{{ cleanup_path }}"
+ state: absent
+
+# And ran it with...
+$ ansible-playbook cleanup.yml -e "cleanup_path=/"
+```
+**Result:** ๐ฅ Deleted the entire filesystem
+
+**Lesson:** Always use `--check` mode first!
+
+### ๐ฅ **"The Leaked Vault Password"**
+
+```bash
+# Developer committed this
+$ git add .vault_pass
+$ git commit -m "Add vault password for convenience"
+$ git push
+```
+**Result:** ๐ All secrets exposed in Git history
+
+**Lesson:** Add `.vault_pass` to `.gitignore`!
+
+### โก **"The Infinite Loop"**
+
+```yaml
+- name: Restart service until it works
+ service:
+ name: myapp
+ state: restarted
+ until: result.status == 0
+ # Forgot to add retries limit!
+```
+**Result:** ๐ Playbook ran for 48 hours straight
+
+**Lesson:** Always set `retries` and `delay`!
+
+---
+
+## ๐ Group 5: Misconfiguration Scanning & Policy-as-Code
+
+## ๐ Slide 16 โ ๐ IaC Security Scanning Tools Deep Dive
+
+### ๐ ๏ธ Tool Comparison
+
+| Tool | Speed | Coverage | False Positives | Cost | Best For |
+|------|-------|----------|-----------------|------|----------|
+| ๐ **Checkov** | Medium | 1000+ checks | Low | Free | Multi-cloud |
+| โก **tfsec** | โก Fast | 300+ checks | Very Low | Free | Terraform |
+| ๐ **Terrascan** | Slow | 500+ checks | Medium | Free | Compliance |
+| ๐ฆ
**Prowler** | Medium | 300+ checks | Low | Free | AWS |
+| ๐ **ScoutSuite** | Slow | All services | Medium | Free | Multi-cloud audit |
+
+
+๐ญ Interactive: Which tool should you choose?
+
+**Choose tfsec if:**
+* โ
You only use Terraform
+* โ
Speed is critical (CI/CD)
+* โ
Want minimal false positives
+* โ
Need IDE integration
+
+**Choose Checkov if:**
+* โ
Multi-cloud or multi-IaC tool
+* โ
Need custom Python policies
+* โ
Want largest policy library
+* โ
Need container/K8s scanning too
+
+**Choose Terrascan if:**
+* โ
Already using OPA/Rego
+* โ
Need custom compliance frameworks
+* โ
Want policy-as-code approach
+
+**Best practice:** Use multiple! They catch different issues.
+```bash
+tfsec . && checkov -d . && terraform plan
+```
+
+
+---
+
+## ๐ Slide 17 โ ๐ Policy-as-Code Frameworks
+
+### ๐ฏ Open Policy Agent (OPA)
+
+```bash
+# Install
+$ brew install opa
+
+# Run as server
+$ opa run --server
+
+# Test policy
+$ opa test policy/ -v
+```
+
+```rego
+# policy/s3_public.rego
+package terraform.s3
+
+deny[msg] {
+ resource := input.resource.aws_s3_bucket[name]
+ resource.acl == "public-read"
+ msg := sprintf("S3 bucket %v is publicly readable", [name])
+}
+
+deny[msg] {
+ resource := input.resource.aws_s3_bucket[name]
+ not resource.versioning
+ msg := sprintf("S3 bucket %v does not have versioning", [name])
+}
+```
+
+### ๐ Conftest - Test Configurations
+
+```bash
+# Install
+$ brew install conftest
+
+# Test Terraform plan
+$ terraform plan -out=plan.out
+$ terraform show -json plan.out > plan.json
+$ conftest test plan.json
+
+# Test Kubernetes
+$ conftest test deployment.yaml
+
+# Test Dockerfile
+$ conftest test Dockerfile
+```
+
+```rego
+# policy/kubernetes.rego
+package main
+
+deny[msg] {
+ input.kind == "Deployment"
+ not input.spec.template.spec.securityContext.runAsNonRoot
+ msg := "Containers must not run as root"
+}
+
+deny[msg] {
+ input.kind == "Service"
+ input.spec.type == "LoadBalancer"
+ msg := "LoadBalancer services are not allowed"
+}
+
+warn[msg] {
+ input.kind == "Pod"
+ not input.spec.containers[_].resources.limits
+ msg := "Container should have resource limits"
+}
+```
+
+### โ๏ธ HashiCorp Sentinel
+
+```hcl
+# sentinel.hcl
+policy "s3-bucket-encryption" {
+ enforcement_level = "hard-mandatory"
+}
+
+policy "required-tags" {
+ enforcement_level = "soft-mandatory"
+}
+```
+
+```python
+# s3-bucket-encryption.sentinel
+import "tfplan/v2" as tfplan
+
+s3_buckets = filter tfplan.resource_changes as _, rc {
+ rc.type is "aws_s3_bucket" and
+ rc.mode is "managed" and
+ rc.change.actions is not ["delete"]
+}
+
+require_encryption = rule {
+ all s3_buckets as _, bucket {
+ bucket.change.after.server_side_encryption_configuration is not null
+ }
+}
+
+main = rule {
+ require_encryption
+}
+```
+
+
+๐ญ Quiz: OPA vs Sentinel - What's the difference?
+
+**Open Policy Agent (OPA):**
+* ๐ Open source (CNCF)
+* ๐ Universal - works anywhere
+* ๐ Rego language (declarative)
+* ๐ง Requires integration work
+* โก Blazing fast
+
+**HashiCorp Sentinel:**
+* ๐ฐ Commercial (Terraform Cloud/Enterprise only)
+* ๐๏ธ Terraform-specific
+* ๐ Sentinel language (procedural)
+* โ
Built-in Terraform integration
+* ๐ฏ Terraform-aware (costs, resources, etc.)
+
+**When to use:**
+- Open source project? โ OPA
+- Need multi-tool support? โ OPA
+- Using Terraform Cloud? โ Sentinel
+- Need cost controls? โ Sentinel
+- Want flexibility? โ OPA
+
+**Pro tip:** You can use both! OPA for runtime, Sentinel for Terraform.
+
+
+---
+
+## ๐ Slide 18 โ โ๏ธ Compliance & Security Standards
+
+### ๐ CIS Benchmarks
+
+* ๐ **CIS = Center for Internet Security**
+* ๐ Industry consensus standards
+* โ๏ธ Benchmarks for AWS, Azure, GCP, Kubernetes
+
+### ๐ Compliance Frameworks
+
+| Framework | Industry | Key Requirements |
+|-----------|----------|------------------|
+| ๐ณ **PCI-DSS** | Payment cards | Encryption, network segmentation, logging |
+| ๐ฅ **HIPAA** | Healthcare | Data encryption, access controls, audit logs |
+| ๐ช๐บ **GDPR** | EU data | Data privacy, right to deletion, consent |
+| ๐ **SOC2** | SaaS/Cloud | Security controls, availability, confidentiality |
+| ๐ฆ **ISO 27001** | Global | Information security management |
+
+### ๐ Mapping IaC Checks to Compliance
+
+```yaml
+# compliance-mapping.yml
+checks:
+ - id: CKV_AWS_18
+ title: "Ensure S3 bucket has access logging enabled"
+ frameworks:
+ - PCI-DSS: "10.2.1"
+ - HIPAA: "164.312(b)"
+ - SOC2: "CC6.1"
+
+ - id: CKV_AWS_19
+ title: "Ensure S3 bucket is encrypted"
+ frameworks:
+ - PCI-DSS: "3.4"
+ - HIPAA: "164.312(a)(2)(iv)"
+ - GDPR: "Article 32"
+ - SOC2: "CC6.7"
+```
+
+### ๐ก๏ธ Cloud Security Posture Management (CSPM)
+
+```bash
+# Example: Using ScoutSuite for multi-cloud audit
+$ scout suite --provider aws --profile production
+
+# Or with Prowler for AWS
+$ prowler aws --profile prod --html-output
+
+# Output shows:
+# โ
Passed: 234 checks
+# โ ๏ธ Warning: 45 checks
+# โ Failed: 12 checks
+# ๐ Compliance Score: 87%
+```
+
+---
+
+## ๐ Group 6: Case Studies & Future Trends
+
+## ๐ Slide 19 โ ๐ฏ Case Studies, Future Trends & Summary
+
+### ๐จ Case Study 1: Capital One Breach (2019)
+
+* ๐ฆ **Target:** Capital One (major US bank)
+* ๐
**Date:** March 2019 (discovered July 2019)
+* ๐ฅ **Impact:** 100M customer records, 140K SSNs, 80K bank accounts
+* ๐ฐ **Cost:** $190M settlement + reputation damage
+
+**What happened:**
+```hcl
+# Misconfigured WAF (simplified example)
+resource "aws_waf_rule" "allow_all" {
+ name = "WAF-Rule"
+ metric_name = "WAFRule"
+
+ predicates {
+ data_id = aws_waf_ipset.allow_all.id
+ negated = false
+ type = "IPMatch"
+ }
+}
+
+# SSRF vulnerability + overly permissive IAM role
+resource "aws_iam_role_policy" "waf_role" {
+ policy = jsonencode({
+ Action = [
+ "s3:List*",
+ "s3:Get*" # ๐ฅ Too permissive!
+ ]
+ Resource = "*" # ๐ฅ All buckets!
+ })
+}
+```
+
+**How IaC security could have prevented it:**
+```bash
+$ checkov -f main.tf
+
+โ IAM policy should not allow * resource
+โ IAM policy is overly permissive
+โ WAF rule allows all IPs
+
+$ conftest test plan.json -p compliance/
+
+โ IAM role violates least privilege (PCI-DSS 7.1.2)
+```
+
+### ๐จ Case Study 2: Tesla Kubernetes Dashboard (2018)
+
+* โก **Target:** Tesla (electric vehicle company)
+* ๐
**Date:** February 2018
+* ๐ฅ **Impact:** Crypto mining attack, potential access to proprietary data
+* ๐ฐ **Cost:** Unknown (quickly remediated)
+
+**What happened:**
+```yaml
+# Exposed Kubernetes dashboard (no authentication!)
+apiVersion: v1
+kind: Service
+metadata:
+ name: kubernetes-dashboard
+spec:
+ type: LoadBalancer # ๐ฅ PUBLIC!
+ ports:
+ - port: 443
+ targetPort: 8443
+```
+
+**Fixed with policy-as-code:**
+```rego
+# Block public K8s services
+deny[msg] {
+ input.kind == "Service"
+ input.spec.type == "LoadBalancer"
+ not input.metadata.annotations["service.beta.kubernetes.io/aws-load-balancer-internal"]
+ msg := "LoadBalancer must be internal-only"
+}
+```
+
+### ๐ฎ Future of IaC Security (2025-2030)
+
+* ๐ค **AI-Powered Security:**
+ * ML models detect anomalous infrastructure patterns
+ * Auto-fix suggestions with context
+ * Predictive security (catch issues before they happen)
+
+* ๐ **GitOps Everywhere:**
+ * All infrastructure changes via Git
+ * Automated policy enforcement
+ * Complete audit trails
+
+* ๐ก๏ธ **Shift-Left Evolution:**
+ * IDE plugins catch issues while coding
+ * Real-time policy feedback
+ * Security as you type
+
+* ๐ **Zero-Trust Infrastructure:**
+ * Every resource requires explicit authorization
+ * Continuous verification
+ * Automated least-privilege
+
+* ๐ฆ **Policy Marketplaces:**
+ * Pre-built compliance frameworks
+ * Community-driven security rules
+ * Industry-specific policies
+
+### ๐ Best Practices Checklist
+
+```yaml
+โ
Security Fundamentals:
+ - [ ] Never hardcode secrets
+ - [ ] Use remote encrypted state
+ - [ ] Enable state locking
+ - [ ] Version pin all dependencies
+ - [ ] Use verified modules only
+
+โ
Scanning & Testing:
+ - [ ] Run security scans in CI/CD
+ - [ ] Implement policy-as-code
+ - [ ] Test policies before enforcement
+ - [ ] Scan for secrets (gitleaks)
+ - [ ] Multiple tools (defense in depth)
+
+โ
Access Control:
+ - [ ] RBAC for all operations
+ - [ ] MFA for production changes
+ - [ ] Separate accounts/workspaces
+ - [ ] Audit logs enabled
+ - [ ] Least privilege by default
+
+โ
Compliance:
+ - [ ] Map checks to frameworks
+ - [ ] Automated compliance reports
+ - [ ] Regular policy reviews
+ - [ ] Documentation up-to-date
+ - [ ] Continuous monitoring
+
+โ
Continuous Improvement:
+ - [ ] Track security metrics
+ - [ ] Regular security training
+ - [ ] Incident response plan
+ - [ ] Blameless post-mortems
+ - [ ] Share learnings across teams
+```
+
+### ๐ฏ Key Takeaways
+
+1. ๐๏ธ **IaC is powerful** - Automates infrastructure, but also automates vulnerabilities if not secured
+2. ๐ **Secrets management** - Use vaults, never hardcode, encrypt state
+3. ๐ **Scan everything** - tfsec, Checkov, Terrascan in every pipeline
+4. ๐ **Policy-as-code** - OPA/Conftest/Sentinel enforce standards automatically
+5. ๐ **Shift-left** - Catch issues in development, not production
+6. ๐ **Compliance** - Map IaC checks to regulatory requirements
+7. ๐ **GitOps** - Git as source of truth, automated deployments
+8. ๐ค **Future is AI** - ML will revolutionize IaC security detection
+
+### ๐ Essential Resources
+
+* **๐ Learning:**
+ * [Terraform Best Practices](https://www.terraform-best-practices.com/)
+ * [Pulumi Examples](https://github.com/pulumi/examples)
+ * [Ansible Documentation](https://docs.ansible.com/)
+ * [OPA Policy Library](https://github.com/open-policy-agent/library)
+
+* **๐ ๏ธ Tools:**
+ * [tfsec](https://aquasecurity.github.io/tfsec/)
+ * [Checkov](https://www.checkov.io/)
+ * [Conftest](https://www.conftest.dev/)
+ * [Prowler](https://github.com/prowler-cloud/prowler)
+
+* **๐ Standards:**
+ * [CIS Benchmarks](https://www.cisecurity.org/cis-benchmarks/)
+ * [NIST Cloud Computing](https://www.nist.gov/programs-projects/nist-cloud-computing-program-nccp)
+ * [OWASP Cloud Security](https://owasp.org/www-project-cloud-security/)
+
+* **๐ Certifications:**
+ * HashiCorp Certified: Terraform Associate
+ * Certified Kubernetes Security Specialist (CKS)
+ * AWS Certified Security - Specialty
+
+---
diff --git a/lectures/lec7.md b/lectures/lec7.md
new file mode 100644
index 00000000..2ef17eb1
--- /dev/null
+++ b/lectures/lec7.md
@@ -0,0 +1,1615 @@
+# ๐Lecture 7 - Container & Kubernetes Security: Docker/K8s Fundamentals, Image Scanning, RBAC & Runtime Protection
+
+## ๐ Group 1: Container Fundamentals & Security Basics
+
+## ๐ Slide 1 โ ๐ณ Container Technology Overview & Evolution
+
+* ๐ณ **Container** = lightweight, portable execution environment that packages application + dependencies
+* ๐ฐ๏ธ **Evolution timeline:**
+ * ๐
**1979**: Unix chroot โ first process isolation concept
+ * ๐
**2000**: FreeBSD Jails โ early container-like technology
+ * ๐
**2008**: LXC (Linux Containers) โ Linux namespace + cgroups integration
+ * ๐
**2013**: Docker released โ revolutionized container adoption
+ * ๐
**2014**: Kubernetes released by Google โ container orchestration at scale
+ * ๐
**2017**: containerd donated to CNCF (Cloud Native Computing Foundation)
+* ๐ **Adoption stats**: 87% of organizations use containers in production (Red Hat State of Enterprise Open Source 2024)
+* ๐ข **Industry impact**: Netflix runs 300,000+ containers, Uber deploys 1,000+ times per day
+* ๐ **Learn more:** [Docker Overview](https://docs.docker.com/get-started/overview/), [Container History](https://blog.aquasec.com/a-brief-history-of-containers-from-1970s-chroot-to-docker-2016)
+
+```mermaid
+flowchart LR
+ BM[๐ฅ๏ธ Bare Metal
1970s-1990s] --> VM[๐ Virtual Machines
2000s]
+ VM --> Container[๐ฆ Containers
2010s+]
+
+ subgraph "๐ VM Characteristics"
+ VM1[๐ง Full OS per VM]
+ VM2[๐พ High Resource Usage]
+ VM3[โฑ๏ธ Slow Boot Time]
+ end
+
+ subgraph "๐ฆ Container Benefits"
+ C1[โก Shared OS Kernel]
+ C2[๐จ Lightweight]
+ C3[๐ Fast Startup]
+ end
+
+ style BM fill:#fdf2e9,stroke:#e67e22,stroke-width:2px,color:#2c3e50
+ style VM fill:#eaf2f8,stroke:#3498db,stroke-width:2px,color:#2c3e50
+ style Container fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Container vs Virtual Machine Comparison
+
+| Aspect | ๐ Virtual Machines | ๐ฆ Containers |
+|--------|-------------------|---------------|
+| ๐ง **Architecture** | Full OS + Hypervisor | Shared OS kernel |
+| ๐พ **Resource Usage** | High (GB per VM) | Low (MB per container) |
+| โฑ๏ธ **Startup Time** | Minutes | Seconds |
+| ๐ **Isolation** | Hardware-level | Process-level |
+| ๐ฆ **Portability** | Limited | Excellent |
+| ๐ก๏ธ **Security** | Stronger isolation | Weaker isolation |
+| ๐ฐ **Cost** | Higher | Lower |
+
+### ๐ ๏ธ Container Runtime Ecosystem
+
+* ๐ณ **Docker** = most popular, full container platform (daemon + CLI + registry)
+* ๐๏ธ **containerd** = industry-standard container runtime (Docker's core engine)
+* ๐ง **CRI-O** = Kubernetes-focused, OCI (Open Container Initiative) compliant
+* ๐ **Podman** = daemonless, rootless containers by Red Hat
+* โก **runc** = low-level container runtime (spawns/runs containers)
+* ๐ **Market share**: Docker 83%, containerd 17% (Datadog Container Report 2024)
+
+```mermaid
+flowchart LR
+ App[๐ฑ Application] --> Engine[๐ Container Engine]
+ Engine --> Runtime[โ๏ธ Container Runtime]
+ Runtime --> Kernel[๐ง Linux Kernel]
+
+ subgraph "๐ Container Engines"
+ Docker[๐ณ Docker]
+ Podman[๐ Podman]
+ end
+
+ subgraph "โ๏ธ Container Runtimes"
+ containerd[๐๏ธ containerd]
+ CRIO[๐ง CRI-O]
+ runc[โก runc]
+ end
+
+ style App fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ style Kernel fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+```
+
+
+๐ญ Interactive Question: Why would you choose Podman over Docker?
+
+**Podman advantages:**
+* ๐ **Daemonless** โ no privileged daemon running
+* ๐ค **Rootless** โ runs containers without root privileges
+* ๐ **More secure** โ smaller attack surface
+* ๐ฆ **OCI compliant** โ better standards compliance
+* ๐ข **Enterprise focus** โ Red Hat/IBM enterprise support
+
+**Docker advantages:**
+* ๐ **Ecosystem** โ larger community, more tutorials
+* ๐ ๏ธ **Docker Compose** โ easier multi-container apps
+* ๐ **Documentation** โ more learning resources
+* ๐ **Docker Hub** โ largest container registry
+
+**Bottom line:** Podman for security-conscious enterprises, Docker for development ease
+
+
+---
+
+## ๐ Slide 2 โ ๐๏ธ Docker Architecture & Security Model
+
+* ๐๏ธ **Docker Architecture Components:**
+ * ๐ฅ๏ธ **Docker Daemon (dockerd)** = background service managing containers
+ * ๐ป **Docker CLI** = command-line interface for user interactions
+ * ๐ **Docker API** = RESTful API for programmatic control
+ * ๐ฆ **Docker Registry** = stores and distributes container images
+* ๐ **Container Isolation Mechanisms:**
+ * ๐ **Namespaces** = isolate process views (PID, network, filesystem, user)
+ * โ๏ธ **Control Groups (cgroups)** = limit resource usage (CPU, memory, I/O)
+ * ๐ก๏ธ **Seccomp** = restricts system calls available to processes
+ * ๐ **AppArmor/SELinux** = mandatory access control policies
+* โ ๏ธ **Critical security concern**: Docker daemon runs as root โ potential privilege escalation
+* ๐ **Default Docker setup** = containers can access host resources if misconfigured
+
+```mermaid
+flowchart LR
+ CLI[๐ป Docker CLI] --> Daemon[๐ฅ๏ธ Docker Daemon]
+ Daemon --> Images[๐ฆ Images]
+ Daemon --> Containers[๐โโ๏ธ Running Containers]
+ Daemon --> Registry[๐ Docker Registry]
+
+ subgraph "๐ Isolation Layers"
+ NS[๐ Namespaces]
+ CG[โ๏ธ cgroups]
+ SC[๐ก๏ธ seccomp]
+ MAC[๐ AppArmor/SELinux]
+ end
+
+ Containers --> NS
+ Containers --> CG
+ Containers --> SC
+ Containers --> MAC
+
+ style Daemon fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style NS fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Container Security Risks & Attack Vectors
+
+* ๐ช **Container Escape** = breaking out of container to access host system
+ * ๐ Common causes: privileged containers, mounted host directories, kernel vulnerabilities
+ * ๐ **CVE-2019-5736** (runc escape) affected millions of containers worldwide
+* โ ๏ธ **Docker Daemon Vulnerabilities:**
+ * ๐ Exposed Docker API (port 2375/2376) โ remote code execution
+ * ๐ Insecure Docker socket access (`/var/run/docker.sock`)
+ * ๐ Docker daemon runs as root โ full host compromise possible
+* ๐ฆ **Image-Based Attacks:**
+ * ๐ Vulnerable base images with known CVEs
+ * ๐ Secrets embedded in image layers
+ * ๐ฆ Malicious images from untrusted registries
+* ๐ **Network Security Issues:**
+ * ๐ก Default bridge network โ containers can communicate freely
+ * ๐ Exposed container ports โ unintended external access
+
+
+๐ญ Security Challenge: What makes the first command dangerous?
+
+**Multiple dangerous flags:**
+
+1. **`--privileged`** ๐
+ - Disables all security restrictions
+ - Gives container full access to host devices
+ - Can modify kernel parameters
+
+2. **`-v /:/host`** ๐
+ - Mounts entire host filesystem
+ - Container can read/write ANY host file
+ - Includes `/etc/passwd`, `/etc/shadow`, etc.
+
+3. **Running as root (default)** ๐
+ - Container processes run with root privileges
+ - No user namespace isolation
+
+**Result:** Complete host compromise in one command!
+
+**Real-world impact:** This exact pattern caused the 2018 Tesla Kubernetes compromise.
+
+
+---
+
+## ๐ Slide 3 โ ๐ฆ Container Images & Layered Filesystem
+
+* ๐ฆ **Container Image** = read-only template containing application code + runtime + libraries + dependencies
+* ๐ง
**Layered Architecture:**
+ * ๐๏ธ **Base layer** = operating system foundation (e.g., ubuntu:20.04)
+ * ๐ **Library layers** = runtime dependencies, frameworks
+ * ๐ฑ **Application layer** = your code and configurations
+ * ๐ **Writable layer** = created when container runs (ephemeral)
+* ๐ญ **Image Registries:**
+ * ๐ **Docker Hub** = public registry (10B+ image pulls monthly)
+ * โ๏ธ **Amazon ECR** = AWS-managed private registry
+ * โ๏ธ **Google GCR** = Google Cloud container registry
+ * ๐ข **Harbor** = open-source enterprise registry with security scanning
+* ๐ **Docker Content Trust (DCT)** = image signing and verification using Notary
+* ๐ **Security stats**: 51% of container images contain high-severity vulnerabilities (Snyk Container Security Report 2024)
+
+```mermaid
+flowchart TB
+ subgraph "๐ฆ Container Image Layers"
+ App[๐ฑ Application Layer
Your Code]
+ Deps[๐ Dependencies Layer
Libraries, Frameworks]
+ Runtime[โ๏ธ Runtime Layer
JVM, Node.js, Python]
+ Base[๐๏ธ Base OS Layer
Ubuntu, Alpine, Distroless]
+ end
+
+ subgraph "๐โโ๏ธ Running Container"
+ Writable[โ๏ธ Writable Layer
Temporary Changes]
+ App --> Writable
+ end
+
+ subgraph "๐ Registries"
+ Hub[๐ Docker Hub
Public Images]
+ ECR[โ๏ธ AWS ECR
Private Registry]
+ Harbor[๐ข Harbor
Enterprise Registry]
+ end
+
+ Base --> Runtime
+ Runtime --> Deps
+ Deps --> App
+
+ style App fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ style Base fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Writable fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Image Security Best Practices
+
+* ๐๏ธ **Use Minimal Base Images:**
+ * ๐ง **Alpine Linux** = 5MB base image vs Ubuntu's 64MB
+ * ๐ก๏ธ **Distroless** = no shell, package manager โ smaller attack surface
+ * ๐ฆ **Scratch** = empty base image for static binaries
+* ๐ซ **Avoid Root User:**
+ ```dockerfile
+ # โ BAD: Running as root (default)
+ FROM ubuntu:20.04
+ COPY app /app
+ CMD ["/app"]
+
+ # โ
GOOD: Create and use non-root user
+ FROM ubuntu:20.04
+ RUN groupadd -r appuser && useradd -r -g appuser appuser
+ COPY app /app
+ RUN chown -R appuser:appuser /app
+ USER appuser
+ CMD ["/app"]
+ ```
+* ๐ **Multi-stage Builds** = separate build and runtime environments
+
+### ๐ Base Image Comparison
+
+| Base Image | Size | Packages | Use Case | Security |
+|------------|------|----------|----------|----------|
+| ๐ง **ubuntu:20.04** | 64MB | ~100 | Development | โ ๏ธ Medium |
+| ๐๏ธ **alpine:latest** | 5MB | ~15 | Production | โ
Good |
+| ๐ก๏ธ **distroless** | 2-20MB | 0-5 | Production | ๐ Excellent |
+| ๐ฆ **scratch** | 0MB | 0 | Static binaries | ๐ Maximum |
+
+
+๐ญ Quick Poll: Which base image would you choose for a Python web app?
+
+**Options:**
+1. ๐ง `python:3.11` (900MB)
+2. ๐๏ธ `python:3.11-alpine` (50MB)
+3. ๐ก๏ธ `python:3.11-slim` (120MB)
+4. ๐ฆ Custom distroless + Python
+
+**Best practices:**
+- **Development:** python:3.11 (easier debugging)
+- **Production:** python:3.11-alpine or distroless (security + size)
+- **High security:** Custom distroless build
+- **CI/CD:** python:3.11-slim (balance of features + size)
+
+**Pro tip:** Start with slim, move to alpine/distroless as you mature your security practices!
+
+
+---
+
+## ๐ Slide 4 โ ๐ Container Image Security Scanning
+
+* ๐ **Vulnerability Scanning** = automated analysis of container images for known security vulnerabilities
+* ๐ฏ **What scanners detect:**
+ * ๐ **OS package vulnerabilities** = CVEs in base image packages (apt, yum packages)
+ * ๐ **Application dependencies** = vulnerable libraries (npm, pip, maven packages)
+ * ๐ **Embedded secrets** = API keys, passwords, certificates in image layers
+ * โ๏ธ **Misconfigurations** = running as root, exposed ports, insecure defaults
+* ๐ ๏ธ **Popular Scanning Tools:**
+ * โก **Trivy** = comprehensive, fast, supports multiple languages
+ * ๐ฆ
**Grype** = by Anchore, excellent vulnerability database
+ * ๐ **Snyk** = commercial, great developer experience
+ * ๐ **Clair** = open-source, API-first, used by Red Hat Quay
+* ๐ **Scanning integration**: 78% of organizations scan images in CI/CD pipelines (CNCF Survey 2024)
+
+```mermaid
+flowchart LR
+ Image[๐ฆ Container Image] --> Scanner[๐ Security Scanner]
+ Scanner --> DB[(๐๏ธ Vulnerability Database
NVD, GitHub, OS vendors)]
+ Scanner --> Results[๐ Scan Results]
+
+ subgraph "๐ Vulnerability Report"
+ Critical[๐ด Critical: 5]
+ High[๐ High: 12]
+ Medium[๐ก Medium: 23]
+ Low[๐ข Low: 8]
+ end
+
+ Results --> Critical
+ Results --> High
+ Results --> Medium
+ Results --> Low
+
+ subgraph "๐ ๏ธ Popular Tools"
+ Trivy[โก Trivy]
+ Grype[๐ฆ
Grype]
+ Snyk[๐ Snyk]
+ Clair[๐ Clair]
+ end
+
+ style Critical fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style High fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ง Scanner Comparison Matrix
+
+| Tool | ๐ฐ Cost | โก Speed | ๐ Accuracy | ๐ Languages | ๐ข Enterprise |
+|------|---------|----------|-------------|--------------|--------------|
+| โก **Trivy** | Free | Fast | High | 20+ | Good |
+| ๐ฆ
**Grype** | Free | Fast | High | 15+ | Good |
+| ๐ **Snyk** | Freemium | Fast | Very High | 25+ | Excellent |
+| ๐ **Clair** | Free | Medium | High | 10+ | Good |
+| ๐ **JFrog Xray** | Paid | Fast | Very High | 20+ | Excellent |
+
+### ๐ Vulnerability Severity Levels (CVSS)
+
+| Score | Severity | ๐ฏ Action Required | โฐ Timeline |
+|-------|----------|-------------------|------------|
+| **9.0-10.0** | ๐ด **Critical** | Immediate fix | < 24 hours |
+| **7.0-8.9** | ๐ **High** | Priority fix | < 7 days |
+| **4.0-6.9** | ๐ก **Medium** | Plan fix | < 30 days |
+| **0.1-3.9** | ๐ข **Low** | Consider fix | Next release |
+
+
+๐ญ Real-World Scenario: Your scan shows 50 vulnerabilities. What do you do?
+
+**Step-by-step vulnerability triage:**
+
+1. **๐ด Address Critical/High first**
+ - Focus on actively exploitable vulnerabilities
+ - Check if patches are available
+ - Prioritize by EPSS (Exploit Prediction Scoring System)
+
+2. **๐ Analyze false positives**
+ - Some vulnerabilities may not apply to your use case
+ - Use scanner suppression files for confirmed false positives
+ - Document reasoning for suppression
+
+3. **๐ Update strategy**
+ ```bash
+ # Update base image
+ FROM python:3.11-slim-bullseye # Instead of outdated version
+
+ # Update packages
+ RUN apt-get update && apt-get upgrade -y && \
+ apt-get clean && rm -rf /var/lib/apt/lists/*
+ ```
+
+4. **๐ Set policies**
+ - No Critical vulnerabilities in production
+ - High vulnerabilities fixed within 7 days
+ - Regular scanning schedule (weekly/monthly)
+
+**Pro tip:** Not all vulnerabilities are equal! A SQL injection in a web service vs a command injection in a CLI tool have different risk levels.
+
+
+---
+
+## ๐ Fun Break: "Container Horror Stories & Memes"
+
+### ๐ฑ **"The 2018 Tesla Cryptocurrency Mining Incident"**
+
+**What happened:**
+* ๐ Tesla left Kubernetes dashboard **publicly accessible** without authentication
+* ๐ Cryptominers discovered it and deployed mining containers
+* โ๏ธ Mined Monero cryptocurrency using Tesla's cloud resources
+* ๐ธ Generated **thousands of dollars** in cloud bills
+* ๐ Tesla discovered it when AWS sent an unusually high bill
+
+**The meme-worthy part:**
+* ๐ค Tesla, a company building **AI-powered cars**, got pwned by basic container misconfig
+* ๐ฐ Headlines: *"Tesla's AI cars are secure, but their containers aren't"*
+* ๐ฌ Security community: *"They can make cars drive themselves but can't secure a dashboard"*
+
+### ๐ณ **Classic Container Memes:**
+
+**"Docker vs VM Resource Usage"**
+```
+VM: I need 4GB RAM to run Hello World
+Container: Hold my beer... 4MB is enough
+```
+
+**"Container Debugging"**
+```
+Developer: "It works on my machine"
+DevOps: "It works in containers"
+Security: "Your container is pwned"
+```
+
+**"Container Escape Reality"**
+```
+Junior Dev: "Containers are totally isolated!"
+Security Engineer: "docker run --privileged has entered the chat"
+```
+
+### ๐ญ **Interactive Meme Creation Time!**
+
+**Fill in the blanks:**
+```
+Before containers: "It works on my _____"
+After containers: "It fails in _____"
+After security scanning: "It has _____ critical vulnerabilities"
+After hardening: "It _____ but it's secure!"
+```
+
+**Answers from the community:**
+- machine / production / 47 / runs slower ๐
+- laptop / staging / 1000 / doesn't run ๐
+- computer / k8s / zero / works perfectly ๐
+
+---
+
+๐ **Container Security Resources for Group 1:**
+* [Docker Security Best Practices](https://docs.docker.com/develop/security-best-practices/)
+* [Container Security by Liz Rice (Free eBook)](https://info.aquasec.com/container-security-book)
+* [NIST Container Security Guide](https://www.nist.gov/publications/application-container-security-guide)
+* [CIS Docker Benchmark](https://www.cisecurity.org/benchmark/docker)
+* [Trivy Documentation](https://aquasecurity.github.io/trivy/)
+* [OWASP Container Security Top 10](https://github.com/OWASP/www-project-container-top-10)
+
+## ๐ Group 2: Container Runtime Security
+
+## ๐ Slide 5 โ ๐ก๏ธ Container Runtime Security
+
+* ๐ก๏ธ **Runtime Security** = monitoring containers while they're running, not just during build
+* ๐จ **Runtime Threats:**
+ * ๐ **Malicious process execution** (reverse shells, crypto miners)
+ * ๐ **Unauthorized file access** (reading `/etc/passwd`, config files)
+ * ๐ **Suspicious network activity** (C2 communication, data exfiltration)
+ * ๐ **Privilege escalation** attempts
+* ๐ **Detection Tools:**
+ * ๐ฆ
**Falco** = CNCF project, runtime security monitoring
+ * ๐ **Sysdig** = commercial platform with Falco underneath
+ * โก **Aqua Security** = comprehensive runtime protection
+* ๐ **Stats**: 68% of organizations experienced runtime security incidents (Stackrox Report 2024)
+
+```mermaid
+flowchart LR
+ Container[๐ฆ Running Container] --> Monitor[๐๏ธ Runtime Monitor]
+ Monitor --> Rules[๐ Security Rules]
+ Rules --> Alert[๐จ Security Alert]
+
+ subgraph "๐จ Runtime Threats"
+ Shell[๐ Reverse Shell]
+ Crypto[โ๏ธ Crypto Mining]
+ Exfil[๐ค Data Exfiltration]
+ Escalate[๐ Privilege Escalation]
+ end
+
+ style Container fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Alert fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+```
+
+
+๐ญ Quick Question: How would you detect cryptocurrency mining?
+
+**Common indicators:**
+* ๐ High CPU usage (>80% sustained)
+* ๐ Process names: `xmrig`, `ethminer`, `cpuminer`
+* ๐ Network connections to mining pools
+* ๐ Files: `/tmp/.X11-unix/`, hidden directories
+
+**Falco rule example:**
+```yaml
+- rule: Detect Crypto Mining
+ condition: spawned_process and (proc.name contains "miner" or proc.name contains "xmrig")
+ output: Crypto mining detected (process=%proc.name)
+ priority: CRITICAL
+```
+
+
+---
+
+## ๐ Slide 6 โ ๐ Secrets Management in Containers
+
+* ๐ **Container Secrets Problem:**
+ * โ **In Dockerfile** = visible to anyone with image access
+ * โ **Environment variables** = visible in process list (`docker inspect`)
+ * โ **Config files** = persisted in image layers forever
+* โ
**Secure Solutions:**
+ * ๐ณ **Docker Secrets** = encrypted at rest, in-memory only in container
+ * โธ๏ธ **Kubernetes Secrets** = base64 encoded, etcd encryption
+ * ๐ฆ **External Vaults** = HashiCorp Vault, AWS Secrets Manager
+ * ๐ **CSI Drivers** = mount secrets as files from external systems
+
+```mermaid
+flowchart LR
+ subgraph "โ Insecure"
+ ENV[๐ Environment Variables]
+ FILE[๐ Config Files]
+ DOCKER[๐ณ Dockerfile Hardcoding]
+ end
+
+ subgraph "โ
Secure"
+ DSEC[๐ณ Docker Secrets]
+ KSEC[โธ๏ธ K8s Secrets]
+ VAULT[๐ฆ External Vault]
+ CSI[๐ CSI Secret Driver]
+ end
+
+ style ENV fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style VAULT fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+### ๐ Secret Rotation Best Practices
+
+* โฐ **Automatic rotation** every 30-90 days
+* ๐ **Zero-downtime rotation** using external secret operators
+* ๐ **Audit secret access** and usage patterns
+* ๐ซ **Revoke compromised secrets** immediately
+
+---
+
+## ๐ Slide 7 โ ๐ Container Compliance & Hardening
+
+* ๐ **CIS Docker Benchmark** = 100+ security recommendations for Docker
+* ๐ **Container Hardening Checklist:**
+ * ๐ค Run as non-root user (`USER 1001`)
+ * ๐ Read-only filesystem (`--read-only`)
+ * ๐ซ Drop capabilities (`--cap-drop=ALL`)
+ * ๐ Use specific user namespaces
+ * ๐ฆ Scan images before deployment
+* ๐ ๏ธ **Compliance Tools:**
+ * โ๏ธ **Docker Bench** = CIS benchmark automated checker
+ * โธ๏ธ **kube-bench** = CIS Kubernetes benchmark scanner
+ * ๐ **Falco** = runtime compliance monitoring
+
+```mermaid
+flowchart LR
+ Image[๐ฆ Container Image] --> Bench[โ๏ธ Docker Bench]
+ Runtime[๐โโ๏ธ Running Container] --> Monitor[๐ Runtime Monitor]
+ K8s[โธ๏ธ Kubernetes] --> KubeBench[โธ๏ธ kube-bench]
+
+ Bench --> Report[๐ Compliance Report]
+ Monitor --> Report
+ KubeBench --> Report
+
+ subgraph "๐ Hardening Checklist"
+ User[๐ค Non-root User]
+ RO[๐ Read-only FS]
+ Caps[๐ซ Drop Caps]
+ Scan[๐ Image Scanning]
+ end
+
+ style Report fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+### ๐ก๏ธ Hardened Container Example
+
+```dockerfile
+# โ
SECURE DOCKERFILE
+FROM alpine:3.18
+
+# Create non-root user
+RUN addgroup -g 1001 appgroup && \
+ adduser -u 1001 -G appgroup -s /bin/sh -D appuser
+
+# Install only required packages
+RUN apk add --no-cache python3 py3-pip && \
+ rm -rf /var/cache/apk/*
+
+# Copy application
+COPY --chown=appuser:appgroup app.py /app/
+COPY --chown=appuser:appgroup requirements.txt /app/
+
+# Switch to non-root
+USER appuser
+WORKDIR /app
+
+# Install dependencies
+RUN pip install --no-cache-dir -r requirements.txt
+
+# Health check
+HEALTHCHECK --interval=30s --timeout=3s \
+ CMD python3 -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/health')"
+
+EXPOSE 8000
+CMD ["python3", "app.py"]
+```
+
+### ๐ Running Hardened Containers
+
+```bash
+# โ
SECURE RUNTIME FLAGS
+docker run \
+ --read-only \ # Read-only filesystem
+ --tmpfs /tmp \ # Writable temp directory
+ --user 1001:1001 \ # Non-root user
+ --cap-drop=ALL \ # Drop all capabilities
+ --cap-add=NET_BIND_SERVICE \ # Only add required caps
+ --security-opt=no-new-privileges \ # Prevent privilege escalation
+ --memory=512m \ # Memory limit
+ --cpus=0.5 \ # CPU limit
+ myapp:latest
+```
+
+### ๐ Compliance Scanning
+
+```bash
+# Docker Bench Security
+git clone https://github.com/docker/docker-bench-security.git
+cd docker-bench-security
+sudo sh docker-bench-security.sh
+
+# Output example:
+# [WARN] 4.5 - Ensure Content trust for Docker is Enabled
+# [PASS] 4.6 - Ensure HEALTHCHECK is enabled
+# [FAIL] 5.1 - Ensure AppArmor Profile is Enabled
+```
+
+
+๐ญ Challenge: Your container needs to write logs. How do you handle read-only filesystem?
+
+**Solutions:**
+
+1. **tmpfs mount** (in-memory):
+```bash
+docker run --read-only --tmpfs /var/log myapp:latest
+```
+
+2. **Volume mount**:
+```bash
+docker run --read-only -v /host/logs:/var/log myapp:latest
+```
+
+3. **Log to stdout/stderr**:
+```python
+# Instead of writing files, log to stdout
+import logging
+logging.basicConfig(stream=sys.stdout, level=logging.INFO)
+```
+
+4. **External logging** (best):
+```bash
+# Use logging driver
+docker run --log-driver=fluentd myapp:latest
+```
+
+**Pro tip:** Cloud-native apps should log to stdout and let the orchestrator handle log collection!
+
+
+---
+
+## ๐ Fun Break: "Container Security Fails"
+
+### ๐
**"The Bitcoin Mining Dockerfile"**
+
+```dockerfile
+# Real Dockerfile found on Docker Hub (anonymized)
+FROM ubuntu:16.04
+RUN apt-get update && apt-get install -y wget
+RUN wget https://github.com/xmrig/xmrig/releases/download/v6.18.0/xmrig-6.18.0-linux-static-x64.tar.gz
+RUN tar -xf xmrig*.tar.gz
+RUN chmod +x xmrig-6.18.0/xmrig
+CMD ["./xmrig-6.18.0/xmrig", "--donate-level=1"]
+```
+
+**Community reactions:**
+* ๐ "Finally, a Dockerfile that mines its own hosting costs"
+* ๐คฆโโ๏ธ "Running this in production would be interesting"
+* ๐ "Security team's nightmare in 8 lines"
+
+### ๐ญ **Security Meme Generator:**
+
+```
+When junior dev runs:
+docker run --privileged -v /:/host ubuntu
+
+Senior dev: "Congratulations, you just _____ the host"
+Security team: "Time to _____ everything"
+Manager: "How much will this cost to _____?"
+
+Popular answers:
+- pwned / reinstall / fix ($50k)
+- nuked / rebuild / explain (my job)
+- rooted / audit / cover up (priceless)
+```
+
+---
+
+๐ **Runtime Security Resources:**
+* [Falco Rules](https://github.com/falcosecurity/rules)
+* [Docker Secrets Guide](https://docs.docker.com/engine/swarm/secrets/)
+* [CIS Docker Benchmark](https://www.cisecurity.org/benchmark/docker)
+* [Container Security Checklist](https://github.com/krol3/container-security-checklist)
+## ๐ Group 3: Kubernetes Fundamentals & Architecture
+
+## ๐ Slide 8 โ โธ๏ธ Kubernetes Architecture & Components
+
+* โธ๏ธ **Kubernetes** = container orchestration platform managing 1000s of containers across multiple nodes
+* ๐๏ธ **Control Plane Components:**
+ * ๐ **API Server** = all communication goes through here (kubectl, pods, everything)
+ * ๐ง **etcd** = distributed key-value store (cluster state, secrets, configs)
+ * ๐
**Scheduler** = decides which node runs each pod
+ * ๐๏ธ **Controller Manager** = maintains desired state (replication, endpoints, etc.)
+* ๐ท **Worker Node Components:**
+ * ๐ค **kubelet** = node agent, manages pods and containers
+ * ๐ **kube-proxy** = network proxy, handles service routing
+ * ๐โโ๏ธ **Container Runtime** = Docker, containerd, or CRI-O
+* ๐ **Scale**: Google runs 2B+ containers/week on Kubernetes (2024)
+
+```mermaid
+flowchart TB
+ subgraph "๐๏ธ Control Plane"
+ API[๐ API Server]
+ ETCD[(๐ง etcd)]
+ SCHED[๐
Scheduler]
+ CTRL[๐๏ธ Controller Manager]
+ end
+
+ subgraph "๐ท Worker Node 1"
+ KUBELET1[๐ค kubelet]
+ PROXY1[๐ kube-proxy]
+ RUNTIME1[๐โโ๏ธ Container Runtime]
+ POD1[๐ฆ Pods]
+ end
+
+ subgraph "๐ท Worker Node 2"
+ KUBELET2[๐ค kubelet]
+ PROXY2[๐ kube-proxy]
+ RUNTIME2[๐โโ๏ธ Container Runtime]
+ POD2[๐ฆ Pods]
+ end
+
+ API --> KUBELET1
+ API --> KUBELET2
+ ETCD --> API
+ SCHED --> API
+ CTRL --> API
+
+ style API fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style ETCD fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+```
+
+### ๐ Security Boundaries & Trust Zones
+
+| Component | Trust Level | Attack Surface | Impact if Compromised |
+|-----------|-------------|----------------|----------------------|
+| ๐ **API Server** | ๐ด Critical | High | Complete cluster control |
+| ๐ง **etcd** | ๐ด Critical | Medium | All secrets exposed |
+| ๐ค **kubelet** | ๐ High | Medium | Node compromise |
+| ๐ฆ **Pod** | ๐ข Low | High | Container breakout |
+
+### ๐ Kubernetes Networking Model
+
+* ๐ก **Every pod gets its own IP** (no NAT between pods)
+* ๐ **Pods can communicate** with all other pods by default
+* ๐ช **Services provide stable endpoints** for dynamic pods
+* ๐ก๏ธ **Network Policies** = firewall rules for pod-to-pod communication
+
+
+๐ญ Security Question: What happens if etcd gets compromised?
+
+**Complete disaster! ๐ฅ**
+
+**What's in etcd:**
+* ๐ All Kubernetes secrets (base64 encoded, not encrypted by default)
+* ๐ซ Service account tokens
+* โ๏ธ ConfigMaps with sensitive data
+* ๐ TLS certificates
+* ๐๏ธ All cluster configuration
+
+**Attack scenarios:**
+* ๐ค Extract all secrets and tokens
+* ๐ญ Impersonate any service account
+* ๐ง Modify cluster configuration
+* ๐ฃ Deploy malicious workloads
+
+**Protection:**
+* ๐ Enable etcd encryption at rest
+* ๐ Restrict etcd network access
+* ๐ก๏ธ Use strong authentication
+* ๐ Monitor etcd access logs
+
+
+---
+
+## ๐ Slide 9 โ ๐ Kubernetes Authentication & Authorization
+
+* ๐ **Authentication** = Who are you?
+ * ๐ **X.509 Certificates** = most common, used by kubectl
+ * ๐ซ **Service Account Tokens** = for pods to access API
+ * ๐ **OIDC/OAuth** = integration with external identity providers
+ * ๐ **Static tokens** = deprecated, avoid in production
+* ๐ก๏ธ **Authorization** = What can you do? (RBAC = Role-Based Access Control)
+ * ๐ค **Users** = humans with certificates
+ * ๐ค **Service Accounts** = pods/applications
+ * ๐ฅ **Groups** = collection of users
+ * ๐ญ **Roles** = set of permissions (verbs + resources)
+* ๐ **Default behavior**: Service accounts have minimal permissions (good!)
+
+```mermaid
+flowchart LR
+ User[๐ค User/Pod] --> Auth[๐ Authentication]
+ Auth --> AuthZ[๐ก๏ธ Authorization RBAC]
+ AuthZ --> API[๐ API Server]
+
+ subgraph "๐ Auth Methods"
+ Cert[๐ X.509 Certs]
+ Token[๐ซ SA Tokens]
+ OIDC[๐ OIDC/OAuth]
+ end
+
+ subgraph "๐ก๏ธ RBAC Components"
+ Role[๐ญ Roles]
+ Binding[๐ RoleBindings]
+ Subject[๐ค Subjects]
+ end
+
+ style Auth fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style AuthZ fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+
+๐ญ RBAC Challenge: How do you give a pod access to create other pods?
+
+**Careful! This is dangerous! ๐จ**
+
+```yaml
+# โ ๏ธ HIGH RISK ROLE
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+rules:
+- apiGroups: [""]
+ resources: ["pods"]
+ verbs: ["create", "get", "list"]
+
+# Better: Use Jobs or Deployments
+apiVersion: rbac.authorization.k8s.io/v1
+kind: Role
+rules:
+- apiGroups: ["batch"]
+ resources: ["jobs"]
+ verbs: ["create"]
+```
+
+**Why dangerous:**
+* ๐ฆ Can create privileged pods
+* ๐ Can mount service account tokens
+* ๐ Can access host network
+* ๐ฃ Essentially cluster-admin via pod creation
+
+**Better alternatives:**
+* ๐ฏ Use specific controllers (Jobs, CronJobs)
+* ๐ Admission controllers to prevent privilege escalation
+* ๐ก๏ธ Pod Security Standards
+
+
+---
+
+## ๐ Slide 10 โ ๐ช Kubernetes Admission Control & Policies
+
+* ๐ช **Admission Controllers** = gatekeepers that intercept requests before persistence
+* ๐ **Two Types:**
+ * ๐ง **Mutating** = modify requests (add labels, inject sidecars)
+ * โ
**Validating** = approve/reject requests (policy enforcement)
+* ๐ก๏ธ **Pod Security Standards** (replaces deprecated Pod Security Policies):
+ * ๐ **Privileged** = unrestricted (development only)
+ * โก **Baseline** = minimally restrictive (default production)
+ * ๐ **Restricted** = heavily restricted (high security)
+* ๐ฏ **Open Policy Agent (OPA) Gatekeeper** = policy-as-code for Kubernetes
+
+```mermaid
+flowchart LR
+ Request[๐ kubectl apply] --> Mutating[๐ง Mutating Admission]
+ Mutating --> Validating[โ
Validating Admission]
+ Validating --> Accept{โ
Accept?}
+ Accept -->|Yes| etcd[(๐ง etcd)]
+ Accept -->|No| Reject[โ Reject]
+
+ subgraph "๐ก๏ธ Policy Examples"
+ PSS[๐ Pod Security Standards]
+ OPA[๐ฏ OPA Gatekeeper]
+ Custom[โ๏ธ Custom Webhooks]
+ end
+
+ style Validating fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Reject fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+```
+
+### ๐ ๏ธ Common Admission Controller Use Cases
+
+| Use Case | Tool | Example |
+|----------|------|---------|
+| ๐ **Security Policies** | Pod Security Standards | Block privileged containers |
+| ๐ท๏ธ **Resource Quotas** | ResourceQuota controller | Limit CPU/memory per namespace |
+| ๐ฏ **Policy Enforcement** | OPA Gatekeeper | Require specific labels |
+| ๐ **Secret Injection** | Custom webhook | Inject certificates from Vault |
+| ๐ **Monitoring** | Mutating webhook | Add monitoring sidecars |
+
+
+๐ญ Policy Question: Should you block or warn for policy violations?
+
+**Three enforcement modes:**
+
+1. **๐ซ Enforce (Block)**
+ - Rejects violating resources
+ - Prevents deployment
+ - Use for critical security policies
+
+2. **โ ๏ธ Warn**
+ - Shows warning but allows deployment
+ - Good for gradual policy rollout
+ - Doesn't break existing workflows
+
+3. **๐ Audit (Log only)**
+ - Records violations for analysis
+ - No user impact
+ - Great for understanding current state
+
+**Best practice strategy:**
+```yaml
+# Start with audit, then warn, then enforce
+pod-security.kubernetes.io/audit: restricted # Log violations
+pod-security.kubernetes.io/warn: restricted # Show warnings
+pod-security.kubernetes.io/enforce: baseline # Block only worst violations
+```
+
+**Gradual rollout timeline:**
+- Week 1-2: Audit mode (gather data)
+- Week 3-4: Warn mode (educate teams)
+- Week 5+: Enforce mode (block violations)
+
+
+---
+
+## ๐ Fun Break: "Kubernetes RBAC Horror Stories"
+
+### ๐ฑ **"The cluster-admin Intern"**
+
+**What happened:**
+```bash
+# Intern's first day task: "Fix the broken deployment"
+kubectl create clusterrolebinding fix-it \
+ --clusterrole=cluster-admin \
+ --serviceaccount=default:my-app
+
+# Translation: "Give my app GOD MODE to the entire cluster"
+```
+
+**The aftermath:**
+* ๐ค App gained ability to delete entire cluster
+* ๐ฅ One typo away from production disaster
+* ๐ Security audit found 47 service accounts with cluster-admin
+* ๐ Emergency RBAC training for all developers
+
+---
+
+๐ **Kubernetes Security Resources:**
+* [Kubernetes Security Best Practices](https://kubernetes.io/docs/concepts/security/)
+* [RBAC Documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
+* [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/)
+* [OPA Gatekeeper](https://open-policy-agent.github.io/gatekeeper/)
+
+## ๐ Group 4: Kubernetes Security Features
+
+## ๐ Slide 11 โ ๐ก๏ธ Pod Security & Isolation
+
+* ๐ก๏ธ **Security Contexts** = pod/container-level security settings
+* ๐ง **Key Security Controls:**
+ * ๐ค **runAsUser/runAsGroup** = avoid root (UID 0)
+ * ๐ซ **allowPrivilegeEscalation: false** = block setuid binaries
+ * ๐ **readOnlyRootFilesystem: true** = immutable container filesystem
+ * ๐ช **capabilities** = fine-grained Linux permissions (drop ALL, add specific)
+* ๐ **Network Policies** = firewall rules for pod-to-pod communication
+* ๐ **Resource Limits** = prevent DoS attacks (CPU/memory bombs)
+* ๐ **Pod Security Standards** = enforce security baselines across namespaces
+
+```mermaid
+flowchart LR
+ subgraph "๐ก๏ธ Pod Security Context"
+ User[๐ค runAsNonRoot: true]
+ RO[๐ readOnlyRootFilesystem]
+ Caps[๐ช capabilities: drop ALL]
+ Priv[๐ซ allowPrivilegeEscalation: false]
+ end
+
+ subgraph "๐ Network Isolation"
+ NP[๐ฅ Network Policies]
+ Ingress[โฌ
๏ธ Ingress Rules]
+ Egress[โก๏ธ Egress Rules]
+ end
+
+ Pod[๐ฆ Secure Pod] --> User
+ Pod --> NP
+
+ style Pod fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style NP fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+```
+
+
+๐ญ Quick Challenge: Why does readOnlyRootFilesystem break many apps?
+
+**Common issues:**
+* ๐ Apps writing logs to `/var/log/`
+* ๐ฆ Package managers creating `/tmp/` files
+* ๐ง Apps modifying config files at runtime
+* ๐ Home directory writes (`~/.cache`, `~/.config`)
+
+**Solutions:**
+```yaml
+# Mount writable volumes for specific paths
+volumeMounts:
+- name: tmp
+ mountPath: /tmp
+- name: logs
+ mountPath: /var/log
+- name: cache
+ mountPath: /home/app/.cache
+
+volumes:
+- name: tmp
+ emptyDir: {}
+- name: logs
+ emptyDir: {}
+- name: cache
+ emptyDir: {}
+```
+
+**Pro tip:** Test with `readOnlyRootFilesystem: true` in dev first!
+
+
+---
+
+## ๐ Slide 12 โ ๐ Kubernetes Secrets & ConfigMaps
+
+* ๐ **Kubernetes Secrets** = base64 encoded, stored in etcd (โ ๏ธ NOT encrypted by default!)
+* ๐ **ConfigMaps** = non-sensitive configuration data
+* ๐จ **Secret Security Issues:**
+ * ๐ค Visible in `kubectl describe pod` output
+ * ๐พ Stored in etcd unencrypted (unless configured)
+ * ๐๏ธ Accessible to anyone with pod read permissions
+ * ๐ Logged in various places if not careful
+* โ
**Better Alternatives:**
+ * ๐ฆ **External Secret Operators** (ESO) = sync from Vault/AWS/Azure
+ * ๐ **CSI Secret Store Driver** = mount secrets as files
+ * ๐ **Sealed Secrets** = encrypted secrets safe for Git
+
+```mermaid
+flowchart LR
+ subgraph "โ K8s Secrets Issues"
+ B64[๐ Base64 Encoded
NOT Encrypted]
+ ETCD[(๐ง etcd
Plaintext)]
+ Logs[๐ Visible in Logs]
+ end
+
+ subgraph "โ
Secure Alternatives"
+ ESO[๐ฆ External Secret Operator]
+ CSI[๐ CSI Secret Driver]
+ Sealed[๐ Sealed Secrets]
+ end
+
+ Secret[๐ K8s Secret] --> B64
+ B64 --> ETCD
+
+ External[๐ฆ External Vault] --> ESO
+ External --> CSI
+
+ style ETCD fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style ESO fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+### ๐ Secret Management Comparison
+
+| Method | Security | Complexity | Git-Safe | Rotation |
+|--------|----------|------------|----------|----------|
+| ๐ **K8s Secrets** | โ ๏ธ Low | Low | โ No | Manual |
+| ๐ฆ **External Secret Operator** | โ
High | Medium | โ
Yes | Automatic |
+| ๐ **CSI Driver** | โ
High | Medium | โ
Yes | Automatic |
+| ๐ **Sealed Secrets** | โ
Medium | Low | โ
Yes | Manual |
+
+---
+
+## ๐ Slide 13 โ ๐ Kubernetes Auditing & Monitoring
+
+* ๐ **Audit Logging** = records all API server requests (who did what when)
+* ๐ฏ **Audit Levels:**
+ * ๐ **Metadata** = request metadata only
+ * ๐ **Request** = metadata + request body
+ * ๐ค **Response** = metadata + request + response bodies
+* ๐ **What to Monitor:**
+ * ๐จ Failed authentication attempts
+ * ๐ Secret/ConfigMap access
+ * ๐ Privileged pod creation
+ * ๐ Exec/portforward sessions
+* ๐ ๏ธ **Monitoring Stack**: Prometheus + Grafana + Falco + ELK
+
+```mermaid
+flowchart LR
+ API[๐ API Server] --> Audit[๐ Audit Logs]
+ Nodes[๐ท Worker Nodes] --> Metrics[๐ Node Metrics]
+ Pods[๐ฆ Pods] --> Logs[๐ Application Logs]
+
+ Audit --> SIEM[๐ SIEM/ELK]
+ Metrics --> Prometheus[๐ Prometheus]
+ Logs --> FluentD[๐ก FluentD]
+
+ Prometheus --> Grafana[๐ Grafana]
+ SIEM --> Alerts[๐จ Security Alerts]
+
+ style Audit fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Alerts fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+```
+
+### ๐ Security Metrics Dashboard
+
+| Metric | Normal | Suspicious |
+|--------|--------|------------|
+| ๐ **Secret Access/hour** | < 50 | > 200 |
+| ๐ **Exec Sessions/day** | < 10 | > 50 |
+| ๐ **Privileged Pods** | 0-2 | > 5 |
+| โ **Failed Auth/hour** | < 5 | > 20 |
+| ๐ฆ **Pod Creation Spikes** | Steady | 10x increase |
+
+
+๐ญ Monitoring Question: How do you detect a cryptocurrency mining attack?
+
+**Kubernetes-specific:**
+* ๐จ Unexpected pod creation in system namespaces
+* ๐ Sudden resource quota exhaustion
+* ๐ Pods restarting due to resource limits
+* ๐ Unknown container images from suspicious registries
+
+**Response:**
+1. ๐ `kubectl delete pod `
+2. ๐ Check audit logs for how pods were created
+3. ๐ Review RBAC permissions
+4. ๐ Implement resource quotas and limits
+
+
+---
+
+## ๐ Fun Break: "Kubernetes Secrets Exposed!"
+
+### ๐คฆโโ๏ธ **"The Base64 Confusion"**
+
+**Slack conversation:**
+```
+Junior Dev: "I encrypted our database password!"
+Senior Dev: "Great! How?"
+Junior Dev: "echo 'password123' | base64"
+Senior Dev: "That's... not encryption ๐
"
+Junior Dev: "But it's unreadable!"
+Senior Dev: "echo 'cGFzc3dvcmQxMjM=' | base64 -d"
+Junior Dev: "... oh"
+```
+
+### ๐ **"Secret Scanning Memes"**
+
+```
+Kubernetes Secrets be like:
+
+Developer: "Our secrets are secure in base64!"
+Security Scanner: "I can read that"
+Developer: "But it's encoded!"
+Security Scanner: "Here's your plaintext password"
+Developer: *surprised Pikachu face*
+```
+
+### ๐ญ **Interactive K8s Quiz:**
+
+```
+What's wrong with this Secret usage?
+
+apiVersion: v1
+kind: Pod
+spec:
+ containers:
+ - name: app
+ env:
+ - name: DB_PASS
+ valueFrom:
+ secretKeyRef:
+ name: db-secret
+ key: password
+ - name: DEBUG
+ value: "true" # Logs everything including env vars! ๐คฆโโ๏ธ
+
+Answer: Debug mode will log environment variables, exposing the secret!
+
+Better: Use mounted secret files instead of env vars when possible.
+```
+
+### ๐ก **Security Pro Tips:**
+
+```
+โ Don't: kubectl create secret generic mysecret --from-literal=password=123
+โ
Do: Use external secret management
+
+โ Don't: Store secrets in environment variables
+โ
Do: Mount secrets as files when possible
+
+โ Don't: Log request/response bodies in production
+โ
Do: Use metadata-level audit logging for secrets
+```
+
+---
+
+๐ **Kubernetes Security Features Resources:**
+* [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/)
+* [Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
+* [Kubernetes Secrets](https://kubernetes.io/docs/concepts/configuration/secret/)
+* [External Secrets Operator](https://external-secrets.io/)
+* [Kubernetes Auditing](https://kubernetes.io/docs/tasks/debug-application-cluster/audit/)
+
+## ๐ Group 5: Kubernetes Security Tools & Practices
+
+## ๐ Slide 14 โ ๐ Kubernetes Security Scanning
+
+* ๐ **Static Analysis Tools:**
+ * ๐ฏ **kube-score** = YAML analysis, best practices scoring
+ * ๐น **kube-hunter** = penetration testing from attacker perspective
+ * โญ **Polaris** = configuration validation, security recommendations
+ * ๐ **Checkov** = policy-as-code scanning for K8s manifests
+* ๐โโ๏ธ **Runtime Security:**
+ * ๐ฆ
**Falco** = runtime threat detection
+ * ๐ **Sysdig Secure** = comprehensive runtime protection
+ * โก **Aqua Security** = container runtime security platform
+* ๐ **Compliance Scanning:**
+ * โธ๏ธ **kube-bench** = CIS Kubernetes benchmark automation
+ * ๐ **Popeye** = cluster sanitizer, finds issues and recommendations
+
+```mermaid
+flowchart LR
+ Manifest[๐ K8s Manifest] --> Static[๐ Static Scan]
+ Cluster[โธ๏ธ Running Cluster] --> Runtime[๐โโ๏ธ Runtime Scan]
+ Config[โ๏ธ Cluster Config] --> Compliance[๐ Compliance Scan]
+
+ Static --> Issues[๐ Security Issues]
+ Runtime --> Threats[๐จ Live Threats]
+ Compliance --> Gaps[โ ๏ธ Compliance Gaps]
+
+ style Issues fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Threats fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+```
+
+### ๐ ๏ธ Quick Tool Comparison
+
+| Tool | Focus | Speed | Difficulty |
+|------|-------|-------|------------|
+| ๐ฏ **kube-score** | Best practices | โก Fast | Easy |
+| ๐น **kube-hunter** | Penetration testing | ๐ Slow | Medium |
+| โญ **Polaris** | Config validation | โก Fast | Easy |
+| โธ๏ธ **kube-bench** | CIS compliance | ๐ Medium | Easy |
+
+
+๐ญ Which tool first?
+
+**Recommended order:**
+1. ๐ฏ **kube-score** โ quick YAML validation
+2. โธ๏ธ **kube-bench** โ baseline security check
+3. โญ **Polaris** โ ongoing configuration monitoring
+4. ๐น **kube-hunter** โ penetration testing (advanced)
+
+**Start simple, add complexity gradually!**
+
+
+---
+
+## ๐ Slide 15 โ ๐ Kubernetes Network Security
+
+* ๐ฅ **Network Policies** = firewall rules for pods (deny-by-default recommended)
+* ๐ธ๏ธ **CNI Security Features:**
+ * ๐ **Calico** = advanced network policies, encryption
+ * ๐ **Cilium** = eBPF-based security, L7 policies
+ * ๐ **Istio** = service mesh with mTLS, traffic policies
+* ๐ **Security Patterns:**
+ * ๐ซ **Default deny-all** โ explicit allow only required traffic
+ * ๐ **Namespace isolation** โ prevent cross-namespace communication
+ * ๐ **mTLS everywhere** โ encrypted pod-to-pod communication
+ * ๐ก๏ธ **Ingress security** โ WAF, rate limiting, SSL termination
+
+```mermaid
+flowchart LR
+ Pod1[๐ฆ Pod A] -.-> Firewall[๐ฅ Network Policy]
+ Firewall --> Pod2[๐ฆ Pod B]
+
+ subgraph "๐ Security Features"
+ CNI[๐ธ๏ธ CNI Security]
+ mTLS[๐ mTLS]
+ WAF[๐ก๏ธ WAF/Ingress]
+ end
+
+ style Firewall fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style CNI fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+### ๐ CNI Comparison
+
+| CNI | Security Focus | Complexity | Performance |
+|-----|----------------|------------|-------------|
+| ๐ **Calico** | Network policies | Medium | High |
+| ๐ **Cilium** | eBPF L7 security | High | Very High |
+| ๐ **Istio** | Service mesh mTLS | Very High | Medium |
+
+---
+
+## ๐ Slide 16 โ ๐๏ธ Secure Kubernetes CI/CD Pipelines
+
+* ๐ **GitOps Security:**
+ * ๐ **ArgoCD** = declarative GitOps with RBAC
+ * ๐ **Flux** = GitOps toolkit with security controls
+ * ๐ **Sealed Secrets** = encrypted secrets in Git
+* ๐๏ธ **Pipeline Security:**
+ * ๐ฆ **Image signing** (Cosign, Notary v2)
+ * ๐ **Policy enforcement** at deployment time
+ * ๐ฏ **Supply chain attestation** (SLSA, in-toto)
+* ๐ก๏ธ **Deployment Patterns:**
+ * ๐ต **Blue-green** deployments for security updates
+ * ๐ฅ **Canary** releases with security monitoring
+ * ๐ **Progressive delivery** with automated rollback
+
+```mermaid
+flowchart LR
+ Git[๐ Git Repo] --> GitOps[๐ GitOps Controller]
+ GitOps --> Policy[๐ก๏ธ Policy Check]
+ Policy --> Deploy[๐ Deploy]
+
+ subgraph "๐ Security Gates"
+ Sign[โ๏ธ Image Signing]
+ Scan[๐ Security Scan]
+ Test[๐งช Security Tests]
+ end
+
+ Policy --> Sign
+ Policy --> Scan
+ Policy --> Test
+
+ style Policy fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+```
+
+### ๐ Security Metrics
+
+| Metric | Target | Alert |
+|--------|--------|-------|
+| ๐ **Images scanned** | 100% | < 95% |
+| โ๏ธ **Signed images** | 100% | < 100% |
+| ๐จ **Critical CVEs** | 0 | > 0 |
+| โฑ๏ธ **Deployment time** | < 10min | > 15min |
+
+---
+
+## ๐ Fun Break: "K8s Security Tool Chaos"
+
+### ๐
**"The Tool Overload Syndrome"**
+
+```
+Security Engineer's Desktop:
+- kube-score โ
+- kube-hunter โ
+- kube-bench โ
+- Polaris โ
+- Falco โ
+- Trivy โ
+- Snyk โ
+- Checkov โ
+
+Developer: "Which one do I use?"
+Security: "Yes."
+```
+
+### ๐ญ **Network Policy Memes:**
+
+```
+NetworkPolicy be like:
+
+Default: "Everyone can talk to everyone! ๐"
+Security team: "NOPE" *applies default-deny*
+Developers: "Nothing works! ๐ญ"
+Security team: "Working as intended โ
"
+```
+
+### ๐ง **Tool Selection Reality:**
+
+```
+Manager: "We need ALL the security tools!"
+Budget: "Pick one."
+Security team: "kube-bench + Falco"
+Manager: "But what about..."
+Security team: "KISS principle wins again"
+```
+
+---
+
+๐ **K8s Security Tools Resources:**
+* [kube-score](https://github.com/zegl/kube-score)
+* [kube-hunter](https://github.com/aquasecurity/kube-hunter)
+* [Polaris](https://github.com/FairwindsOps/polaris)
+* [Falco Rules](https://github.com/falcosecurity/rules)
+* [Cilium Network Policies](https://docs.cilium.io/en/stable/security/policy/)
+
+## ๐ Group 6: Advanced Topics & Case Studies
+
+## ๐ Slide 17 โ ๐จ Kubernetes Attack Scenarios & Defense
+
+* ๐ฏ **Common Attack Vectors:**
+ * ๐ **Privileged container breakout** โ host compromise
+ * ๐ **Service account token abuse** โ lateral movement
+ * ๐ **Exposed API server** โ cluster takeover
+ * ๐ฆ **Malicious images** โ supply chain compromise
+ * โ๏ธ **Cloud metadata access** โ credential theft
+* ๐ก๏ธ **MITRE ATT&CK for Containers:**
+ * ๐ฏ **Initial Access** โ exposed services, supply chain
+ * ๐ **Privilege Escalation** โ privileged containers, hostPath mounts
+ * ๐ก **Lateral Movement** โ service account tokens, network access
+
+```mermaid
+flowchart LR
+ subgraph "๐ฏ Attack Chain"
+ Initial[๐ช Initial Access] --> Escalate[๐ Privilege Escalation]
+ Escalate --> Lateral[๐ก Lateral Movement]
+ Lateral --> Persist[๐ Persistence]
+ Persist --> Exfil[๐ค Exfiltration]
+ end
+
+ subgraph "๐ก๏ธ Defense Layers"
+ Prevent[๐ซ Prevent]
+ Detect[๐๏ธ Detect]
+ Respond[๐จ Respond]
+ end
+
+ style Initial fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Prevent fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+### ๐ก๏ธ Defense Matrix
+
+| Attack Vector | Detection | Prevention |
+|---------------|-----------|------------|
+| ๐ **Privileged pods** | Falco rules | Pod Security Standards |
+| ๐ **Token abuse** | Audit logs | RBAC least privilege |
+| ๐ **API exposure** | Network monitoring | Network policies |
+| ๐ฆ **Malicious images** | Image scanning | Admission controllers |
+
+
+๐ญ Attack Scenario: How would you detect crypto mining?
+
+**Detection signals:**
+* ๐ High CPU usage (>90% sustained)
+* ๐ Connections to mining pools (port 4444, 3333)
+* ๐ Process names: `xmrig`, `ethminer`, `cpuminer`
+* ๐ Unusual network traffic patterns
+
+**Falco rule:**
+```yaml
+- rule: Cryptocurrency Mining
+ condition: spawned_process and proc.name in (xmrig, cpuminer, ethminer)
+ output: Crypto mining detected (proc=%proc.name)
+ priority: CRITICAL
+```
+
+
+---
+
+## ๐ Slide 18 โ ๐ฎ Future Trends & Security Checklist
+
+* ๐ฎ **Emerging Trends:**
+ * ๐ค **AI-powered threat detection** โ behavioral analysis, anomaly detection
+ * ๐ก๏ธ **Zero-trust containers** โ verify everything, trust nothing
+ * ๐ **SBOM for containers** โ software bill of materials tracking
+ * ๐ **Workload identity** โ SPIFFE/SPIRE adoption
+ * โ๏ธ **Confidential computing** โ encrypted container workloads
+* ๐ **Next-Gen Security:**
+ * ๐ฆ **WebAssembly (WASM)** โ lightweight, secure container alternative
+ * ๐ **Supply chain attestation** โ provenance verification
+ * ๐ **Policy-as-code evolution** โ Git-native security policies
+
+```mermaid
+flowchart LR
+ subgraph "๐ฎ Future Security Stack"
+ AI[๐ค AI Detection]
+ ZeroTrust[๐ก๏ธ Zero Trust]
+ SBOM[๐ SBOM Tracking]
+ Workload[๐ Workload Identity]
+ end
+
+ Current[๐ฆ Today's Containers] --> Future[๐ Next-Gen Security]
+
+ style Future fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+```
+
+### ๐ก๏ธ Container Security Checklist
+
+#### ๐ฆ **Container Images**
+- [ ] ๐ Scan all images for vulnerabilities
+- [ ] ๐๏ธ Use minimal base images (Alpine/Distroless)
+- [ ] ๐ค Run as non-root user
+- [ ] ๐ Sign images with Cosign
+- [ ] ๐ Generate SBOM for tracking
+
+#### โธ๏ธ **Kubernetes Security**
+- [ ] ๐ Enable RBAC with least privilege
+- [ ] ๐ก๏ธ Apply Pod Security Standards
+- [ ] ๐ Implement network policies (default-deny)
+- [ ] ๐ Enable audit logging
+- [ ] ๐ Encrypt etcd at rest
+
+#### ๐โโ๏ธ **Runtime Security**
+- [ ] ๐ฆ
Deploy Falco for threat detection
+- [ ] ๐ Monitor resource usage anomalies
+- [ ] ๐ซ Block privileged containers
+- [ ] ๐ Enable read-only filesystems
+- [ ] ๐ Use seccomp/AppArmor profiles
+
+#### ๐ **CI/CD Pipeline**
+- [ ] ๐ Scan images in pipeline
+- [ ] ๐ซ Fail builds on critical CVEs
+- [ ] โ๏ธ Require signed commits/images
+- [ ] ๐ก๏ธ Validate security policies
+- [ ] ๐ Track security metrics
+
+### ๐ Security Maturity Levels
+
+| Level | Description | Focus |
+|-------|-------------|-------|
+| ๐ **Level 1** | Basic security | Image scanning, RBAC |
+| ๐ก๏ธ **Level 2** | Defense in depth | Network policies, admission control |
+| ๐ **Level 3** | Advanced security | Runtime protection, zero-trust |
+| ๐ฎ **Level 4** | Future-ready | AI detection, confidential computing |
+
+### ๐ฏ Key Takeaways
+
+1. **๐ Scan everything** โ images, configs, runtime behavior
+2. **๐ซ Default deny** โ network policies, RBAC, admission control
+3. **๐ค Least privilege** โ non-root users, minimal permissions
+4. **๐ Monitor continuously** โ logs, metrics, anomalies
+5. **๐ Automate security** โ policy-as-code, CI/CD integration
+6. **๐ Stay updated** โ patches, CVEs, security practices
+7. **๐ฏ Plan for incidents** โ detection, response, recovery
+8. **๐ก๏ธ Defense in depth** โ multiple security layers
+
+---
+
+## ๐ Fun Break: "Container Security Evolution"
+
+### ๐
**"The Security Maturity Journey"**
+
+```
+2015: "Containers are secure by default!" ๐
+2016: "Wait, they share the kernel..." ๐ฐ
+2017: "Maybe we need some scanning..." ๐
+2018: "Tesla got crypto-mined via K8s!" ๐ฑ
+2019: "RBAC ALL THE THINGS!" ๐
+2020: "Supply chain is the new attack vector" ๐ฆ
+2024: "AI will solve container security" ๐ค
+2025: "AI is the new attack vector" ๐ค๐
+```
+
+### ๐ญ **Security Reality Check:**
+
+```
+Security team: "We've implemented 47 security tools!"
+Developer: "My pod won't start..."
+Security team: "Working as intended!"
+Manager: "Why is our security budget so high?"
+Everyone: "..."
+
+The eternal struggle continues... ๐
+```
+
+### ๐ก **Container Security Wisdom:**
+
+```
+โ "Security is someone else's job"
+โ
"Security is everyone's responsibility"
+
+โ "We'll add security later"
+โ
"Security is built-in from day one"
+
+โ "Scanning once is enough"
+โ
"Continuous monitoring is essential"
+
+โ "Default configs are fine"
+โ
"Harden everything by default"
+```
+
+---
+
+๐ **Advanced Security Resources:**
+* [MITRE ATT&CK Containers](https://attack.mitre.org/matrices/enterprise/containers/)
+* [Kubernetes Security Checklist](https://kubernetes.io/docs/concepts/security/security-checklist/)
+* [CNCF Cloud Native Security Map](https://github.com/cncf/tag-security/blob/main/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf)
+* [Container Security Best Practices](https://kubernetes.io/docs/concepts/security/)
+* [Falco Community Rules](https://github.com/falcosecurity/rules)
+
+---
diff --git a/lectures/lec8.md b/lectures/lec8.md
new file mode 100644
index 00000000..9c433389
--- /dev/null
+++ b/lectures/lec8.md
@@ -0,0 +1,2414 @@
+# ๐ Lecture 8 - Software Supply Chain Security: SBOM, Signing & Provenance
+
+## ๐ Group 1: Supply Chain Foundations
+
+## ๐ Slide 1 โ ๐ What is Software Supply Chain Security?
+
+* ๐ **Software Supply Chain** = everything from source code to production deployment
+* ๐ฆ **Not just dependencies** โ code, build tools, CI/CD, artifacts, infrastructure
+* ๐ฏ **Core principle:** "Trust but verify every step of the software delivery process"
+* ๐ฅ **Modern reality:** Average application has **200+ dependencies** (direct + transitive)
+* ๐ **Statistics (2024):**
+ * 88% of organizations experienced supply chain attack attempts
+ * 66% of breaches involved third-party software
+ * $4.5M average cost of supply chain breach
+* ๐ **Learn more:** [CISA Supply Chain Security](https://www.cisa.gov/supply-chain), [OWASP SCVS](https://scvs.owasp.org/)
+
+```mermaid
+flowchart LR
+ subgraph "๐ Software Supply Chain"
+ Code[๐ Source Code] --> Build[๐๏ธ Build System]
+ Build --> Deps[๐ฆ Dependencies]
+ Deps --> Artifact[๐ฆ Artifacts]
+ Artifact --> Registry[๐๏ธ Registry]
+ Registry --> Deploy[๐ Deployment]
+ Deploy --> Runtime[โก Runtime]
+ end
+
+ Attack1[๐ฅ Compromised
Dependency] -.->|Attack| Deps
+ Attack2[๐ฅ Build System
Compromise] -.->|Attack| Build
+ Attack3[๐ฅ Registry
Poisoning] -.->|Attack| Registry
+
+ style Code fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Build fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Deps fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Artifact fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ style Registry fill:#e1f5fe,stroke:#0288d1,stroke-width:2px,color:#2c3e50
+ style Deploy fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Runtime fill:#fce4ec,stroke:#c2185b,stroke-width:2px,color:#2c3e50
+ style Attack1 fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style Attack2 fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style Attack3 fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ Supply Chain Security Scope
+
+* ๐ **Source integrity:** Code repositories, commits, developers
+* ๐๏ธ **Build integrity:** Build systems, tools, environment
+* ๐ฆ **Dependency integrity:** Third-party libraries, transitive dependencies
+* ๐ **Artifact integrity:** Compiled binaries, container images, packages
+* ๐ **Deployment integrity:** Infrastructure, configuration, secrets
+* โก **Runtime integrity:** Actual running code matches expected
+
+```mermaid
+flowchart LR
+ Threat[๐ฏ Why Attackers
Target Supply Chains] --> Impact1[๐ฅ Maximum Impact
One compromise = thousands affected]
+ Threat --> Impact2[๐ต๏ธ Stealth
Hidden in trusted code]
+ Threat --> Impact3[โฐ Persistence
Harder to detect and remove]
+ Threat --> Impact4[๐ Trusted Path
Bypasses security controls]
+
+ style Threat fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style Impact1 fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Impact2 fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Impact3 fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Impact4 fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+```
+
+
+๐ญ Discussion: Why is supply chain security harder than traditional security?
+
+**Key challenges:**
+
+1. ๐ **Scale:** Hundreds of dependencies, thousands of transitive dependencies
+2. ๐ฅ **Trust boundaries:** You trust code written by strangers
+3. โฐ **Time dimension:** Vulnerabilities discovered after deployment
+4. ๐ **Constant change:** New versions, new maintainers, new risks
+5. ๐๏ธ **Visibility gaps:** Hard to know what's actually running
+6. ๐ **Transitive trust:** Dependency of dependency of dependency...
+
+**Traditional security:** Protect your code
+**Supply chain security:** Protect everyone else's code that you use
+
+
+---
+
+## ๐ Slide 2 โ ๐ฅ Famous Supply Chain Breaches & Incidents
+
+### ๐ฅ Timeline of Major Attacks
+
+```mermaid
+timeline
+ title ๐ฐ๏ธ Supply Chain Attack Timeline
+ 2017 : ๐ฆ Equifax
Unpatched Apache Struts
147M records
+ 2018 : ๐ฆ Event-Stream
npm package hijacked
Bitcoin wallet theft
+ 2020 : โ๏ธ SolarWinds
Build system compromise
18,000+ organizations
+ 2021 : ๐ชต Log4Shell
Zero-day in Log4j
Billions of devices
+ : ๐ฅ Codecov
Bash uploader modified
Hundreds of companies
+ : ๐จ UA-Parser.js
Supply chain attack
Crypto miner injected
+ 2022 : ๐ฅ PyTorch
Dependency confusion
torchtriton malicious package
+ 2024 : ๐ XZ Utils
Multi-year backdoor
Almost compromised Linux
+```
+
+---
+
+### ๐ฅ SolarWinds (2020)
+
+* โ๏ธ **Target:** SolarWinds Orion platform (IT management software)
+* ๐
**Date:** March-December 2020 (9 months undetected)
+* ๐ฏ **Attack method:** Compromised build system, injected SUNBURST backdoor
+* ๐ฅ **Impact:**
+ * 18,000+ organizations downloaded trojanized update
+ * 100+ US companies compromised
+ * Multiple US government agencies breached
+ * Estimated $100M+ damage
+* ๐ **Key lesson:** **Build systems are critical infrastructure**
+
+```mermaid
+flowchart LR
+ Attacker[๐ต๏ธ APT29
Russian State Actors] -->|1. Compromise| Build[๐๏ธ SolarWinds
Build System]
+ Build -->|2. Inject| Backdoor[๐ SUNBURST
Backdoor]
+ Backdoor -->|3. Sign with| Cert[โ
Valid Certificate]
+ Cert -->|4. Distribute| Update[๐ฆ Orion Update]
+ Update -->|5. Install| Victims[๐ฏ 18,000+
Organizations]
+
+ style Attacker fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style Build fill:#ffcdd2,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Backdoor fill:#b71c1c,stroke:#d32f2f,stroke-width:3px,color:#fff
+ style Victims fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ชต Log4Shell (2021)
+
+* ๐ฆ **Target:** Apache Log4j (ubiquitous Java logging library)
+* ๐
**Date:** December 2021 (disclosed)
+* ๐ฏ **Vulnerability:** CVE-2021-44228 (CVSS 10.0 - Critical)
+* ๐ฅ **Impact:**
+ * Billions of devices affected
+ * Used in: Minecraft, iCloud, Steam, Twitter, Amazon, Tesla
+ * Exploited within hours of disclosure
+ * Still being exploited in 2024
+* ๐ **Key lesson:** **One dependency can break the internet**
+
+```mermaid
+flowchart LR
+ Log4j[๐ชต Log4j
Everywhere] --> App1[๐ฑ Mobile Apps]
+ Log4j --> App2[โ๏ธ Cloud Services]
+ Log4j --> App3[๐ฎ Games]
+ Log4j --> App4[๐ข Enterprise Software]
+ Log4j --> App5[๐ Web Applications]
+
+ Attack[๐ JNDI Exploit] -.->|RCE| Log4j
+
+ style Log4j fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style Attack fill:#b71c1c,stroke:#d32f2f,stroke-width:3px,color:#fff
+```
+
+---
+
+### ๐ฅ Codecov Bash Uploader (2021)
+
+* ๐ ๏ธ **Target:** Codecov (code coverage tool used in CI/CD)
+* ๐
**Date:** January-April 2021 (compromised for 3 months)
+* ๐ฏ **Attack method:** Modified Bash uploader script to exfiltrate secrets
+* ๐ฅ **Impact:**
+ * Hundreds of companies affected
+ * CI/CD environment variables stolen (AWS keys, tokens)
+ * Undetected for months
+* ๐ **Key lesson:** **Security tools can become attack vectors**
+
+---
+
+### ๐ฆ Event-Stream npm (2018)
+
+* ๐ฆ **Target:** event-stream (popular npm package, 2M+ downloads/week)
+* ๐
**Date:** September-November 2018
+* ๐ฏ **Attack method:**
+ * Original maintainer handed off to attacker
+ * Malicious dependency (flatmap-stream) added
+ * Targeted Bitcoin wallets
+* ๐ฅ **Impact:** Cryptocurrency theft from Copay wallet users
+* ๐ **Key lesson:** **Maintainer trust is critical**
+
+```mermaid
+flowchart LR
+ Original[๐จโ๐ป Original
Maintainer] -->|Transfer ownership| Attacker[๐ต๏ธ Attacker]
+ Attacker -->|Add dependency| Malicious[๐ flatmap-stream
Malicious Package]
+ Malicious -->|Included in| EventStream[๐ฆ event-stream
v3.3.6]
+ EventStream -->|Installed by| Victims[๐ฏ 2M+ weekly
downloads]
+ Victims -->|Steal| Crypto[๐ฐ Bitcoin Wallets]
+
+ style Attacker fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style Malicious fill:#b71c1c,stroke:#d32f2f,stroke-width:3px,color:#fff
+```
+
+---
+
+### ๐ XZ Utils Backdoor (2024)
+
+* ๐ ๏ธ **Target:** xz/liblzma (compression library in most Linux distros)
+* ๐
**Date:** 2021-2024 (multi-year social engineering campaign)
+* ๐ฏ **Attack method:**
+ * Attacker spent 2+ years building trust
+ * Became co-maintainer through social engineering
+ * Injected sophisticated backdoor into build system
+ * Targeted SSH authentication in systemd
+* ๐ฅ **Impact:** Nearly compromised all major Linux distributions
+* ๐ **Discovery:** Microsoft engineer noticed 500ms SSH slowdown
+* ๐ **Key lesson:** **Long-term social engineering is the new attack vector**
+
+
+๐ญ Interactive: What do these incidents have in common?
+
+**Common patterns:**
+
+1. โ
**Trusted software** was weaponized (all were legitimate, popular projects)
+2. โฐ **Long dwell time** (weeks or months before detection)
+3. ๐ฏ **High-value targets** (broad impact, critical infrastructure)
+4. ๐ต๏ธ **Sophisticated attackers** (nation-states or organized crime)
+5. ๐ **Exploited trust** (signed certificates, trusted maintainers)
+6. ๐ **Massive scale** (thousands to millions affected)
+
+**Prevention requires:**
+* ๐ Transparency (SBOMs, provenance)
+* โ๏ธ Signing (Sigstore)
+* ๐ก๏ธ Monitoring (continuous scanning)
+* ๐ Policies (only deploy verified artifacts)
+
+
+---
+
+## ๐ Slide 3 โ ๐ฏ Supply Chain Attack Vectors
+
+### ๐ฅ Attack Vector Categories
+
+```mermaid
+flowchart LR
+ subgraph "๐ฏ Supply Chain Attack Vectors"
+ V1[๐ Dependency
Confusion]
+ V2[โจ๏ธ Typosquatting]
+ V3[๐ Account
Takeover]
+ V4[๐๏ธ Build System
Compromise]
+ V5[๐ฆ Malicious
Updates]
+ V6[๐ Transitive
Poisoning]
+ end
+
+ V1 --> Impact[๐ฅ Code Execution
Data Theft
Backdoors]
+ V2 --> Impact
+ V3 --> Impact
+ V4 --> Impact
+ V5 --> Impact
+ V6 --> Impact
+
+ style V1 fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style V2 fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style V3 fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style V4 fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style V5 fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style V6 fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Impact fill:#b71c1c,stroke:#d32f2f,stroke-width:3px,color:#fff
+```
+
+---
+
+### ๐ Dependency Confusion / Substitution
+
+* ๐ฏ **Attack:** Trick package manager into installing malicious public package instead of internal one
+* ๐ **How it works:**
+ * Company uses internal package: `@company/auth-lib`
+ * Attacker publishes public package: `auth-lib` with higher version
+ * Package manager prefers public over internal (misconfiguration)
+* ๐ฐ **Real case:** Security researcher Alex Birsan earned **$130k in bug bounties** (2021)
+* ๐ฏ **Victims:** Apple, Microsoft, Tesla, Uber, PayPal, and 30+ others
+
+```mermaid
+flowchart LR
+ Internal[๐ข Internal Registry
mycompany-auth v1.0.0]
+ Public[๐ Public Registry
mycompany-auth v99.0.0]
+
+ Developer[๐จโ๐ป Developer] -->|Expects| Internal
+ Developer -->|Gets| Public
+ Public -.->|Malicious| Exfil[๐ Credential Theft]
+
+ style Internal fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Public fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style Exfil fill:#b71c1c,stroke:#d32f2f,stroke-width:3px,color:#fff
+```
+
+---
+
+### โจ๏ธ Typosquatting
+
+* ๐ฏ **Attack:** Register package names similar to popular packages
+* ๐ **Examples:**
+ * `reqests` instead of `requests` (Python)
+ * `cross-env` vs `crossenv` (npm)
+ * `electorn` vs `electron`
+ * `lodas` vs `lodash`
+* ๐ **Scale:** Over **10,000 typosquatting packages** detected on npm/PyPI
+* ๐ฅ **Impact:** Steals credentials, crypto wallets, environment variables
+
+---
+
+### ๐ Account Takeover
+
+* ๐ฏ **Attack:** Compromise maintainer accounts, push malicious updates
+* ๐ **Methods:**
+ * Stolen credentials (phishing, credential stuffing)
+ * No 2FA on maintainer accounts
+ * Social engineering
+ * Insider threats
+* ๐ฆ **Examples:**
+ * **Event-Stream:** Maintainer transferred ownership
+ * **UA-Parser.js:** Maintainer account compromised, malicious v0.8.0 published
+ * **coa/rc packages (npm):** Password theft from maintainer
+
+---
+
+### ๐๏ธ Build System Compromise
+
+* ๐ฏ **Attack:** Compromise the build/CI system itself
+* ๐ **SolarWinds method:**
+ * Attackers gained access to build environment
+ * Injected malicious code during compilation
+ * Signed with legitimate certificate
+ * Distributed through official update channel
+* ๐ฅ **Why devastating:** Bypasses all code review, every build is poisoned
+* ๐ก๏ธ **Defense:** Hermetic builds, provenance, SLSA framework
+
+```mermaid
+flowchart LR
+ Source[๐ Clean
Source Code] --> Build[๐๏ธ Compromised
Build System]
+ Build -->|Inject| Backdoor[๐ Malicious Code]
+ Backdoor --> Sign[โ
Sign with
Valid Cert]
+ Sign --> Artifact[๐ฆ Trojanized
Artifact]
+ Artifact --> Users[๐ฏ All Users
Affected]
+
+ style Source fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Build fill:#ffcdd2,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style Backdoor fill:#b71c1c,stroke:#d32f2f,stroke-width:3px,color:#fff
+ style Users fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ฆ Malicious Updates to Legitimate Packages
+
+* ๐ฏ **Attack:** Inject malicious code into new version of trusted package
+* ๐ **After compromise:**
+ * Package has legitimate history
+ * Developers trust and auto-update
+ * Malicious version gets installed automatically
+* ๐ฆ **Examples:**
+ * **Event-Stream v3.3.6:** Added malicious dependency
+ * **Colors.js & faker.js (2022):** Maintainer intentionally broke packages (protest)
+
+---
+
+### ๐ Transitive Dependency Poisoning
+
+* ๐ฏ **Attack:** Compromise dependency several levels deep
+* ๐ **Why effective:**
+ * Developers only vet direct dependencies
+ * Transitive dependencies invisible
+ * Average package has 70+ transitive dependencies
+* ๐ **Example chain:**
+ ```
+ Your App
+ โโโ express (direct)
+ โโโ body-parser
+ โโโ qs
+ โโโ side-channel
+ โโโ ๐ MALICIOUS PACKAGE
+ ```
+
+
+๐ญ Challenge: How many dependencies does your project REALLY have?
+
+**Try this:**
+
+```bash
+# Node.js
+npm ls --all | wc -l
+
+# Python
+pip list | wc -l
+
+# Go
+go list -m all | wc -l
+```
+
+**You might be shocked!** Most projects have:
+* ๐ฆ **10-50 direct dependencies**
+* ๐ **200-1000+ transitive dependencies**
+* โ **Unknown risk** from dependencies you never heard of
+
+**This is why SBOM and continuous scanning are critical!**
+
+
+---
+
+## ๐ Slide 4 โ ๐ก๏ธ Supply Chain Security Frameworks
+
+### ๐ Major Frameworks Overview
+
+| Framework | Owner | Focus | Maturity |
+|-----------|-------|-------|----------|
+| ๐ฏ **SLSA** | Google / OpenSSF | Build integrity, provenance | โ
Mature |
+| ๐ **NIST SSDF** | US NIST | Secure development practices | โ
Mature |
+| ๐ **SBOM** | CISA / NTIA | Software transparency | โ
Mandatory (US) |
+| ๐ **SCVS** | OWASP | Component verification | ๐ง Emerging |
+| ๐ช๐บ **CRA** | EU | Product security requirements | ๐ Coming 2024 |
+
+---
+
+### ๐ฏ SLSA (Supply Chain Levels for Software Artifacts)
+
+* ๐๏ธ **Created by:** Google (2021), now part of OpenSSF
+* ๐ฏ **Goal:** Framework for software supply chain integrity
+* ๐ **4 levels** (0-4) with increasing security guarantees
+* ๐ **Core concepts:**
+ * Build integrity (no tampering)
+ * Provenance (who/what/when/how)
+ * Non-falsifiable evidence
+
+```mermaid
+flowchart LR
+ L0[๐ Level 0
No guarantees] --> L1[๐ Level 1
Build process exists]
+ L1 --> L2[โ
Level 2
Provenance generated]
+ L2 --> L3[๐ Level 3
Hardened builds]
+ L3 --> L4[๐ Level 4
Highest assurance]
+
+ style L0 fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style L1 fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style L2 fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,color:#2c3e50
+ style L3 fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style L4 fill:#1b5e20,stroke:#388e3c,stroke-width:3px,color:#fff
+```
+
+**SLSA Levels:**
+* **Level 0:** No requirements (most software today)
+* **Level 1:** Build process documented
+* **Level 2:** Build service generates signed provenance
+* **Level 3:** Build platform is hardened, provenance non-falsifiable
+* **Level 4:** Two-party review + hermetic builds
+
+๐ **Learn more:** [slsa.dev](https://slsa.dev/)
+
+---
+
+### ๐ NIST SSDF (Secure Software Development Framework)
+
+* ๐๏ธ **Created by:** US National Institute of Standards and Technology
+* ๐ฏ **Goal:** High-level practices for secure software development
+* ๐ **4 practice groups:**
+ * **PO:** Prepare the Organization
+ * **PS:** Protect the Software
+ * **PW:** Produce Well-Secured Software
+ * **RV:** Respond to Vulnerabilities
+* ๐ **Government mandate:** Required for US federal software procurement
+* ๐ **Reference:** [NIST SP 800-218](https://csrc.nist.gov/Projects/ssdf)
+
+---
+
+### ๐ SBOM (Software Bill of Materials)
+
+* ๐๏ธ **Mandated by:** US Executive Order 14028 (May 2021), CISA
+* ๐ฏ **Goal:** Transparency - know what's in your software
+* ๐ **Two main standards:**
+ * **SPDX** (Linux Foundation) - ISO/IEC 5962:2021 standard
+ * **CycloneDX** (OWASP) - Security-focused format
+* ๐ **Minimum elements (NTIA):**
+ * Supplier name
+ * Component name
+ * Version
+ * Unique identifier
+ * Dependency relationships
+ * Author of SBOM data
+ * Timestamp
+* ๐ **Covered in Lab 4**, will analyze in depth in Lab 8
+
+---
+
+### ๐ SCVS (Software Component Verification Standard)
+
+* ๐๏ธ **Created by:** OWASP (2020)
+* ๐ฏ **Goal:** Verification requirements for software components
+* ๐ **Three levels:**
+ * **Level 1:** Basic verification (inventory, known vulnerabilities)
+ * **Level 2:** Intermediate (pedigree, provenance, signing)
+ * **Level 3:** Advanced (reproducible builds, continuous monitoring)
+* ๐ **Learn more:** [scvs.owasp.org](https://scvs.owasp.org/)
+
+---
+
+### ๐ช๐บ EU Cyber Resilience Act (CRA)
+
+* ๐๏ธ **Enacted by:** European Union (2024)
+* ๐ฏ **Goal:** Mandatory cybersecurity requirements for products with digital elements
+* ๐ **Key requirements:**
+ * Security by design
+ * Vulnerability disclosure
+ * Security updates for product lifetime
+ * **SBOM transparency**
+* ๐ฐ **Penalties:** Up to โฌ15M or 2.5% of global revenue
+* ๐ **Impact:** Global (any product sold in EU)
+
+
+๐ญ Discussion: Which framework should you adopt?
+
+**Short answer: ALL OF THEM!** They're complementary, not competing.
+
+**Practical approach:**
+
+1. **Start with SBOM** (required by law, easiest to implement)
+ * Generate SBOMs in CI/CD (Lab 4)
+ * Use for vulnerability tracking
+
+2. **Adopt SLSA gradually** (incremental security improvements)
+ * Start at Level 1 (document your build)
+ * Aim for Level 3 (GitHub Actions can achieve this)
+
+3. **Use NIST SSDF as checklist** (comprehensive best practices)
+ * Map your processes to NIST practices
+ * Identify gaps
+
+4. **Reference SCVS for verification** (what to check)
+ * Verify dependencies meet minimum standards
+ * Implement continuous monitoring
+
+**They all work together to create defense in depth!**
+
+
+---
+
+## ๐ Slide 5 โ ๐ Supply Chain Security in DevSecOps Pipeline
+
+### ๐ Integration Points in SDLC
+
+```mermaid
+flowchart LR
+ IDE[๐ป IDE
Local Dev] -->|Secret scan
Dependency check| Git[๐ Git
Source Control]
+ Git -->|Pre-commit hooks
Signed commits| CI[๐ CI/CD
Build Pipeline]
+ CI -->|SCA scan
SBOM generation
Signing| Registry[๐๏ธ Artifact
Registry]
+ Registry -->|Signature verify
Policy check| Deploy[๐ Deployment]
+ Deploy -->|Provenance verify
Admission control| Runtime[โก Runtime
Production]
+ Runtime -->|Continuous scan
Drift detection| Monitor[๐ Monitoring]
+ Monitor -.->|Feedback| IDE
+
+ style IDE fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Git fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style CI fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Registry fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ style Deploy fill:#e1f5fe,stroke:#0288d1,stroke-width:2px,color:#2c3e50
+ style Runtime fill:#fce4ec,stroke:#c2185b,stroke-width:2px,color:#2c3e50
+ style Monitor fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Security Controls by Stage
+
+| Stage | Security Controls | Tools |
+|-------|------------------|-------|
+| ๐ป **IDE** | Dependency vulnerability hints | Snyk, Dependabot alerts |
+| ๐ **Git** | Secret scanning, commit signing | Gitleaks, GPG, Sigstore |
+| ๐ **CI/CD** | SCA scan, SBOM generation, signing | Syft, Grype, Cosign |
+| ๐๏ธ **Registry** | Image scanning, policy enforcement | Harbor, Artifactory, Nexus |
+| ๐ **Deploy** | Signature verification, provenance check | Cosign verify, Kyverno |
+| โก **Runtime** | Continuous monitoring, drift detection | Falco, Tetragon, Tracee |
+
+---
+
+### ๐ Shift-Left for Dependencies
+
+* โฌ
๏ธ **Shift-left principle:** Catch issues as early as possible
+* ๐ฐ **Cost of fix increases with time:**
+ * **IDE:** Free (instant feedback)
+ * **PR:** $10 (code review)
+ * **CI/CD:** $100 (build failure)
+ * **Staging:** $1,000 (deployment delay)
+ * **Production:** $100,000+ (breach, downtime)
+
+```mermaid
+flowchart LR
+ Early[โฌ
๏ธ Earlier Detection] -->|Lower cost| IDE[๐ป IDE
$0]
+ IDE --> PR[๐ Pull Request
$10]
+ PR --> CI[๐ CI/CD
$100]
+ CI --> Stage[๐งช Staging
$1,000]
+ Stage --> Prod[๐ Production
$100,000+]
+
+ style Early fill:#e8f5e8,stroke:#388e3c,stroke-width:3px,color:#2c3e50
+ style IDE fill:#c8e6c9,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style PR fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,color:#2c3e50
+ style CI fill:#ffe0b2,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Stage fill:#ffccbc,stroke:#ff5722,stroke-width:2px,color:#2c3e50
+ style Prod fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ก๏ธ Defense in Depth Strategy
+
+* ๐ **Multiple layers:** No single tool catches everything
+* ๐งช **Continuous testing:** Scan at every stage
+* ๐ **Different perspectives:**
+ * **SAST:** Analyze source code (covered Lab 5)
+ * **SCA:** Analyze dependencies (**this lab**)
+ * **Container scan:** Analyze OS packages (covered Lab 7)
+ * **DAST:** Test running application (covered Lab 5)
+* ๐ **Feedback loops:** Results inform earlier stages
+
+```mermaid
+flowchart LR
+ subgraph "๐ก๏ธ Defense in Depth"
+ Layer1[๐ IDE Plugins]
+ Layer2[๐ Pre-commit Hooks]
+ Layer3[๐ CI/CD Scanning]
+ Layer4[๐๏ธ Registry Policies]
+ Layer5[๐ Admission Control]
+ Layer6[๐ Runtime Monitoring]
+ end
+
+ Threat[๐ Supply Chain
Attack] -.->|Blocked| Layer1
+ Threat -.->|Blocked| Layer2
+ Threat -.->|Blocked| Layer3
+ Threat -.->|Blocked| Layer4
+ Threat -.->|Blocked| Layer5
+ Threat -.->|Detected| Layer6
+
+ style Threat fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style Layer1 fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Layer2 fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Layer3 fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Layer4 fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Layer5 fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Layer6 fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ฏ Key Takeaways: Integration
+
+* โ
**Automate everything:** Manual processes don't scale
+* โฌ
๏ธ **Shift-left aggressively:** Fail fast, fail cheap
+* ๐ **Continuous monitoring:** New vulnerabilities discovered daily
+* ๐ก๏ธ **Multiple layers:** No single point of failure
+* ๐ **Visibility:** SBOM + provenance = transparency
+* ๐จ **Policy enforcement:** Automated gates prevent risky deployments
+
+
+๐ญ Poll: What's your biggest supply chain security challenge?
+
+**Common challenges (audience participation):**
+
+A. ๐ **Visibility** - Don't know what dependencies we have
+B. ๐ **Scale** - Too many dependencies to track manually
+C. โฐ **Speed** - Security slows down development
+D. ๐งช **False positives** - Too many irrelevant alerts
+E. ๐ **Compliance** - Meeting regulatory requirements
+F. ๐ง **Tooling** - Don't know which tools to use
+G. ๐ฅ **Culture** - Developers resist security checks
+
+**The good news:** This lab addresses all of these! ๐ฏ
+
+
+---
+
+## ๐ Fun Break: "The Leftpad Incident (2016)"
+
+### ๐ฑ How 11 Lines of Code Broke the Internet
+
+**The Setup:**
+* ๐ฆ **leftpad** = tiny npm package (11 lines)
+* ๐ฏ **Purpose:** Pad strings with spaces on the left
+* ๐ **Usage:** Dependency of Babel, React, thousands of projects
+
+**What Happened:**
+1. ๐จโ๐ป Developer Azer Koรงulu had naming dispute with npm and a company
+2. ๐ค Got angry and **unpublished ALL his packages** (273 packages)
+3. ๐ฅ **leftpad disappeared from npm registry**
+4. ๐ฅ **Thousands of projects broke instantly** worldwide
+5. ๐ Continuous integration systems **failed globally**
+6. โฐ Incident duration: **~3 hours of internet chaos**
+
+```mermaid
+flowchart LR
+ Leftpad[๐ฆ leftpad
11 lines] --> Babel[โ๏ธ Babel]
+ Leftpad --> React[โ๏ธ React]
+ Babel --> Thousands[๐ Thousands
of Projects]
+ React --> Thousands
+
+ Delete[๐๏ธ npm unpublish] -.->|๐ฅ| Leftpad
+ Leftpad -.->|โ BROKEN| Thousands
+
+ style Leftpad fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style Delete fill:#b71c1c,stroke:#d32f2f,stroke-width:3px,color:#fff
+ style Thousands fill:#ffccbc,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+```
+
+**The Fix:**
+* npm **changed their policy** - can't unpublish packages after 24 hours if other packages depend on it
+* npm **restored leftpad** manually
+* The incident lasted only **2.5 hours** but taught the world about dependency hell
+
+**Memes Born:**
+* "How to break the internet with 11 lines"
+* "Is your startup based on leftpad?"
+* "The butterfly effect is real in software"
+
+**Lessons Learned:**
+* ๐ **Transitive dependencies are risky** (dependencies you don't know about)
+* ๐ฆ **Package registries are single points of failure**
+* ๐ก๏ธ **Dependency pinning is critical** (lockfiles!)
+* ๐ข **Consider vendoring** critical dependencies
+* ๐ฏ **SBOM would have helped** - at least you'd know leftpad existed!
+
+**Fun Facts:**
+* ๐ leftpad had **millions of downloads per day**
+* ๐ป The actual code can be **replaced with a one-liner:** `str.padStart()`
+* ๐ญ npm even created a **leftpad-memorial** page
+* ๐ This incident **directly influenced** modern supply chain security thinking
+
+**The Code That Broke the Internet:**
+```javascript
+module.exports = leftpad;
+function leftpad (str, len, ch) {
+ str = String(str);
+ ch = ch || ' ';
+ var pad = len - str.length;
+ return pad > 0 ? new Array(pad + 1).join(ch) + str : str;
+}
+```
+
+**Modern equivalent (2024):**
+```javascript
+str.padStart(len, ch); // Built into JavaScript now!
+```
+
+**The tweet that started it all:**
+> "I've just unpublished all my modules. kik, npm and bob are shit and I don't want to work with any of them." - @azerbike
+
+**And the world learned:** Even 11 lines of code can be critical infrastructure. ๐ฏ
+
+---
+
+๐ **Resources for Group 1:**
+* [SolarWinds Report (CISA)](https://www.cisa.gov/uscert/ncas/alerts/aa20-352a)
+* [Log4Shell Explained](https://www.lunasec.io/docs/blog/log4j-zero-day/)
+* [SLSA Framework](https://slsa.dev/)
+* [NIST SSDF](https://csrc.nist.gov/Projects/ssdf)
+* [CISA SBOM Resources](https://www.cisa.gov/sbom)
+* [Leftpad Incident Timeline](https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code)
+
+---
+## ๐ Group 2: Advanced Dependency Analysis
+
+## ๐ Slide 6 โ ๐ Software Composition Analysis (SCA) Deep Dive
+
+* ๐ **SCA (Software Composition Analysis)** = automated scanning of third-party components
+* ๐ **Reality:** 80-90% of your code is from dependencies (not written by you)
+* ๐ฏ **Purpose:** Identify vulnerabilities, licenses, and risks in dependencies
+* ๐ **Three analysis methods:**
+ * ๐ **Manifest parsing** โ reads package.json, requirements.txt, pom.xml
+ * ๐ **Lockfile analysis** โ most accurate, includes transitive dependencies
+ * ๐ข **Binary fingerprinting** โ hash-based matching for compiled artifacts
+* โก **Modern feature:** Reachability analysis (is vulnerable code actually used?)
+* ๐ **Learn more:** [OWASP Dependency-Check](https://owasp.org/www-project-dependency-check/), [Snyk SCA](https://snyk.io/product/open-source-security-management/)
+
+```mermaid
+flowchart LR
+ App[๐ฆ Your Application] --> SCA[๐ SCA Tool]
+ SCA --> Direct[๐ Direct
Dependencies]
+ SCA --> Transitive[๐ Transitive
Dependencies]
+
+ Direct --> Results[๐ Analysis Results]
+ Transitive --> Results
+
+ Results --> Vulns[๐จ Vulnerabilities]
+ Results --> Licenses[โ๏ธ License Risks]
+ Results --> Outdated[โฐ Outdated Packages]
+
+ style SCA fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+ style Vulns fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Direct vs Transitive Dependencies
+
+* ๐ฆ **Direct:** Dependencies you explicitly declare in manifest
+* ๐ **Transitive:** Dependencies of your dependencies (hidden from you)
+* ๐ **Reality check:** 1 direct dependency = 7-10 transitive dependencies on average
+* ๐ฏ **Problem:** Most vulnerabilities hide in transitive dependencies
+* โ ๏ธ **Risk:** You didn't choose them, review them, or know they exist
+
+```mermaid
+flowchart LR
+ You[๐จโ๐ป Your Code] --> Express[๐ฆ express
Direct]
+ Express --> BodyParser[๐ฆ body-parser
Transitive]
+ Express --> Cookie[๐ฆ cookie
Transitive]
+ BodyParser --> QS[๐ฆ qs
Transitive]
+ QS --> SafeBuffer[๐ฆ safe-buffer
Transitive]
+
+ Vuln[๐จ Vulnerability] -.->|Hidden in| SafeBuffer
+
+ style You fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Vuln fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### โก Reachability Analysis (Advanced)
+
+* ๐ฏ **Problem:** Not all vulnerabilities are exploitable in your code
+* ๐ **Question:** Does your code actually call the vulnerable function?
+* ๐ **Impact:** Reduces false positives by 70%+
+* โ
**Benefit:** Focus on real risks, not theoretical ones
+* ๐ ๏ธ **Tools with reachability:** Snyk, GitHub CodeQL (limited), Qwiet AI
+
+```mermaid
+flowchart LR
+ Vuln[๐จ Vulnerable Function
lodash.template] --> Check{๐ค Called by your code?}
+ Check -->|โ
Yes| Exploitable[๐ฅ HIGH PRIORITY
Actually exploitable]
+ Check -->|โ No| Safe[โ
Low Priority
Not reachable]
+
+ style Vuln fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Exploitable fill:#b71c1c,stroke:#d32f2f,stroke-width:3px,color:#fff
+ style Safe fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+
+๐ญ Discussion: Why don't all tools have reachability analysis?
+
+**Challenges:**
+
+* ๐ฌ **Technically complex:** Requires static code analysis + dataflow analysis
+* โฐ **Performance:** Slow to compute (minutes vs seconds)
+* ๐ฏ **Accuracy:** Dynamic features (eval, reflection) break analysis
+* ๐ฐ **Cost:** Expensive to build and maintain
+
+**Why it matters:**
+* ๐ Average project: **200+ vulnerabilities detected**
+* โก With reachability: **Only 60 actually exploitable**
+* โ
Security teams can focus on what matters
+
+**Future:** Reachability analysis becoming standard (AI/ML improvements)
+
+
+---
+
+## ๐ Slide 7 โ ๐๏ธ Vulnerability Databases & Tracking
+
+* ๐ **Multiple databases** track vulnerabilities (not just one source)
+* ๐ **Each database has different coverage and timing**
+* ๐ **Aggregation is key:** Use tools that combine multiple sources
+
+```mermaid
+flowchart LR
+ subgraph "๐ Vulnerability Sources"
+ CVE[๐ข CVE
MITRE]
+ NVD[๐ NVD
NIST]
+ GitHub[๐ GitHub
Advisory]
+ OSV[๐ OSV
Google]
+ end
+
+ CVE --> Tools[๐ ๏ธ SCA Tools]
+ NVD --> Tools
+ GitHub --> Tools
+ OSV --> Tools
+
+ Tools --> You[๐จโ๐ป Developers]
+
+ style Tools fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ข CVE (Common Vulnerabilities and Exposures)
+
+* ๐๏ธ **Managed by:** MITRE Corporation (US DHS funded)
+* ๐
**Created:** 1999 (25+ years old!)
+* ๐ฏ **Purpose:** Standardized vulnerability identifiers
+* ๐ **Format:** CVE-YEAR-NUMBER (e.g., CVE-2021-44228 = Log4Shell)
+* ๐ **Scale:** 200,000+ CVEs, ~25,000 new/year
+* ๐ **Database:** [cve.mitre.org](https://cve.mitre.org/)
+
+---
+
+### ๐ NVD (National Vulnerability Database)
+
+* ๐๏ธ **Managed by:** US NIST
+* ๐ฏ **Built on:** CVE data + enrichment
+* ๐ **Adds:**
+ * **CVSS scores** (severity 0-10)
+ * **CPE** (affected product identifiers)
+ * **CWE** (weakness categories)
+ * **Patches and workarounds**
+* ๐ **Database:** [nvd.nist.gov](https://nvd.nist.gov/)
+
+---
+
+### ๐ GitHub Advisory Database
+
+* ๐๏ธ **Managed by:** GitHub (Microsoft)
+* ๐ฏ **Developer-friendly:** Integrated with Dependabot
+* ๐ฆ **Coverage:** npm, PyPI, Maven, NuGet, RubyGems, Go, Rust
+* โ
**Unique:** Maintainers can publish advisories directly
+* ๐ **Automation:** Auto-alerts repository owners
+* ๐ **Database:** [github.com/advisories](https://github.com/advisories)
+
+---
+
+### ๐ OSV (Open Source Vulnerabilities)
+
+* ๐๏ธ **Created by:** Google (2021)
+* ๐ฏ **Innovation:** Distributed database, ecosystem-specific IDs
+* ๐ **IDs:** GHSA-xxxx, RUSTSEC-xxxx, GO-xxxx (not just CVE)
+* โก **Format:** Machine-readable JSON (automation-friendly)
+* ๐ **Coverage:** Aggregates from multiple sources
+* ๐ **Database:** [osv.dev](https://osv.dev/)
+
+---
+
+### ๐ CVSS Scoring System
+
+* ๐ฏ **CVSS (Common Vulnerability Scoring System)** = severity rating 0.0-10.0
+* ๐ **Current versions:** v3.1 (standard), v4.0 (new, more nuanced)
+
+| Score | Severity | Priority | SLA |
+|-------|----------|----------|-----|
+| 9.0-10.0 | ๐ด **Critical** | Fix immediately | 24 hours |
+| 7.0-8.9 | ๐ **High** | Fix urgently | 7 days |
+| 4.0-6.9 | ๐ก **Medium** | Fix soon | 30 days |
+| 0.1-3.9 | ๐ข **Low** | Fix eventually | 90 days |
+
+* ๐ **Calculator:** [first.org/cvss/calculator](https://www.first.org/cvss/calculator/)
+
+---
+
+### โก EPSS (Exploit Prediction Scoring System)
+
+* ๐ฏ **Problem:** CVSS = severity, not likelihood of exploitation
+* ๐ **EPSS = probability** vulnerability will be exploited in next 30 days
+* ๐ **Score:** 0-100% (e.g., 45% = 45% chance of active exploitation)
+* ๐ค **Uses ML:** Trained on real-world exploitation data
+* ๐ก **Prioritization:** Combine CVSS + EPSS for smarter risk assessment
+* ๐ **Database:** [first.org/epss](https://www.first.org/epss/)
+
+**Example:**
+* CVE-2021-44228 (Log4Shell): CVSS 10.0 + EPSS 97% โ **DROP EVERYTHING, PATCH NOW**
+* CVE-2023-12345: CVSS 9.8 + EPSS 0.3% โ High severity but rarely exploited โ lower priority
+
+---
+
+### ๐จ CISA KEV (Known Exploited Vulnerabilities)
+
+* ๐๏ธ **Managed by:** CISA (US Cybersecurity Agency)
+* ๐ฏ **Purpose:** Catalog of vulnerabilities **actively exploited in the wild**
+* ๐ฅ **Rule:** If it's in KEV โ patch within 48 hours (US federal mandate)
+* ๐ **Size:** 1,000+ actively exploited vulnerabilities
+* โ ๏ธ **Reality:** These are the ones attackers are using RIGHT NOW
+* ๐ **Catalog:** [cisa.gov/known-exploited-vulnerabilities](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
+
+**Prioritization Framework:**
+1. ๐ฅ **In KEV + High CVSS** โ Immediate (drop everything)
+2. ๐ **High CVSS + High EPSS** โ This week
+3. ๐ก **High CVSS + Low EPSS** โ This month
+4. ๐ข **Low CVSS** โ When convenient
+
+
+๐ญ Reality Check: How to prioritize 500 daily alerts?
+
+**The Problem:**
+* ๐ Average enterprise scans: **500+ vulnerabilities/day**
+* ๐ฅ Security team capacity: **~10 fixes/day**
+* โ Which ones matter?
+
+**Smart Prioritization:**
+
+1. **๐ฅ Filter by KEV** โ Top priority (actively exploited)
+2. **โก Check reachability** โ Unreachable = deprioritize
+3. **๐ Combine CVSS + EPSS** โ High + High = urgent
+4. **๐ Business context** โ Internet-facing > internal tools
+5. **๐ง Patch availability** โ Available patch = fix now
+
+**Reality:** You'll never fix everything. Focus on what attackers exploit.
+
+
+---
+
+## ๐ Slide 8 โ ๐ ๏ธ Dependency Management Best Practices
+
+### ๐ Lockfiles Are Mission-Critical
+
+* ๐ **Lockfile purpose:** Pin exact versions of ALL dependencies (transitive included)
+* ๐ฏ **Security benefit:** Reproducible builds prevent supply chain attacks
+* โ
**Golden rule:** Always commit lockfiles to Git
+* โ ๏ธ **Without lockfiles:** Different builds get different dependencies (dangerous!)
+
+```mermaid
+flowchart LR
+ NoLock[โ No Lockfile] --> Random[๐ฒ Random Versions
Each Install]
+ Random --> Risk[๐ฅ Supply Chain Risk]
+
+ Lock[โ
Lockfile] --> Exact[๐ Exact Versions
Every Time]
+ Exact --> Safe[๐ก๏ธ Reproducible Builds]
+
+ style NoLock fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Lock fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Risk fill:#b71c1c,stroke:#d32f2f,stroke-width:3px,color:#fff
+```
+
+**Lockfiles by ecosystem:**
+* ๐ฆ **npm:** package-lock.json, yarn.lock, pnpm-lock.yaml
+* ๐ **Python:** Pipfile.lock, poetry.lock
+* โ **Maven:** Effectively pom.xml with exact versions
+* ๐น **Go:** go.sum (cryptographic checksums)
+* ๐ **Ruby:** Gemfile.lock
+* ๐ฆ **Rust:** Cargo.lock
+
+---
+
+### ๐ Semantic Versioning Strategy
+
+* ๐ **SemVer:** MAJOR.MINOR.PATCH (e.g., 4.18.2)
+* ๐ฏ **Version range strategies:**
+
+| Range | Updates | Risk Level | Use Case |
+|-------|---------|------------|----------|
+| `4.18.2` | None (exact) | โ
Lowest | Production (with lockfile) |
+| `~4.18.2` | Patch only (4.18.x) | ๐ข Low | Conservative |
+| `^4.18.2` | Minor + Patch (4.x) | ๐ก Medium | Common default |
+| `*` | Any version | ๐ด **NEVER** | None |
+
+* ๐ **Best practice:** Use `^` in manifest + lockfile for safety
+
+---
+
+### ๐ค Automated Dependency Updates
+
+* ๐ **Tools:** GitHub Dependabot, Renovate Bot, Snyk
+* ๐ฏ **Purpose:** Auto-create PRs for dependency updates
+* โ
**Benefits:**
+ * Security patches applied automatically
+ * Avoid "big bang" updates (update incrementally)
+ * Reduce technical debt
+* โ ๏ธ **Requirements:**
+ * Good test coverage (catch breaking changes)
+ * CI/CD automation (verify updates work)
+ * Review process (not blindly merge)
+
+```mermaid
+flowchart LR
+ Bot[๐ค Dependabot] -->|New version| PR[๐ Auto PR]
+ PR --> CI[๐ Run Tests]
+ CI -->|โ
Pass| Review[๐ Review]
+ CI -->|โ Fail| Close[๐ซ Close PR]
+ Review -->|โ
Approve| Merge[โ
Auto-merge]
+
+ style Bot fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Merge fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ข Private Package Registries
+
+* ๐ฏ **Purpose:** Host internal packages + mirror public registries
+* ๐ก๏ธ **Security benefits:**
+ * Control what enters your environment (pre-scan packages)
+ * Prevent dependency confusion attacks
+ * Survive public registry outages (availability)
+ * Audit and logging (who installed what)
+* ๐ ๏ธ **Popular solutions:**
+ * **JFrog Artifactory** (enterprise, $$$)
+ * **Sonatype Nexus** (enterprise, $$$)
+ * **GitHub Packages** (integrated with GitHub)
+ * **Verdaccio** (open-source npm proxy, free)
+* ๐ **Learn more:** [JFrog Artifactory](https://jfrog.com/artifactory/), [Verdaccio](https://verdaccio.org/)
+
+---
+
+### ๐๏ธ Minimal Dependencies Philosophy
+
+* ๐ฏ **Principle:** Every dependency = potential vulnerability โ minimize them
+* ๐ **Reality:**
+ * Average npm package: **86 dependencies**
+ * Average Java project: **150+ dependencies**
+* ๐ **Strategies:**
+ * โ Question every new dependency (do you REALLY need it?)
+ * ๐ Use standard library instead (native JavaScript vs lodash)
+ * ๐ฏ Import only what you need (tree shaking)
+ * ๐งน Regular audits (remove unused dependencies)
+
+**Example:** Do you need a package for this?
+* โ **leftpad** (11 lines) โ โ
Use `str.padStart()`
+* โ **is-array** โ โ
Use `Array.isArray()`
+* โ **is-number** โ โ
Use `typeof x === 'number'`
+
+---
+
+### ๐ฆ Vendoring vs Lockfiles
+
+* ๐ฆ **Vendoring:** Copy dependencies into your repository
+* ๐ **Lockfiles:** Reference dependencies with exact versions
+
+**Lockfiles (recommended for most):**
+* โ
Smaller repository size
+* โ
Easier updates (change one file)
+* โ
Standard practice
+* โ Requires registry access
+
+**Vendoring (specialized use cases):**
+* โ
Complete control
+* โ
Offline builds
+* โ
Immune to registry outages
+* โ Large repository size
+* โ Manual update process
+
+**When to vendor:**
+* ๐ Air-gapped/high-security environments
+* ๐ญ Embedded systems (no network)
+* ๐ฆ Production deployment artifacts
+
+
+๐ญ Best Practice: Hybrid approach
+
+**Modern strategy:**
+
+* ๐ **Development:** Use lockfiles (fast, convenient)
+* ๐๏ธ **CI/CD:** Use lockfiles + caching
+* ๐ **Production:** Create vendored artifact (self-contained, no runtime dependencies)
+
+**Benefits:**
+* โก Fast development
+* ๐ก๏ธ Production resilience
+* ๐ฆ Best of both worlds
+
+**Most teams use lockfiles. Only vendor for production if needed.**
+
+
+---
+
+## ๐ Slide 9 โ ๐ป Hands-On: Advanced SCA Tools
+
+* ๐ ๏ธ **Goal:** Compare multiple SCA tools and understand their strengths
+* ๐ฏ **Defense in depth:** Different tools catch different vulnerabilities
+* ๐ **No single tool is perfect** (use multiple for best coverage)
+
+### ๐ท Tool Comparison Matrix
+
+| Tool | Cost | Ecosystems | Speed | Strengths | Weaknesses |
+|------|------|------------|-------|-----------|------------|
+| ๐ท **Snyk** | Freemium | All major | Fast | Reachability, UX | Paid for teams |
+| ๐ฆ
**OWASP Dependency-Check** | Free | Java, .NET, npm, Python | Slow | Comprehensive | False positives |
+| โ **Grype** | Free | Containers, OS | Very fast | Accurate, fast | Limited app deps |
+| ๐ท **Trivy** | Free | Multi-purpose | Very fast | Versatile | Newer tool |
+| ๐ **Dependency-Track** | Free | SBOM-based | N/A | Continuous monitor | Needs SBOM input |
+| ๐ **GitHub Dependabot** | Free | npm, PyPI, Maven | Fast | Integrated, auto-fix | GitHub only |
+
+* ๐ **Resources:** [Snyk](https://snyk.io/), [OWASP DC](https://owasp.org/www-project-dependency-check/), [Grype](https://github.com/anchore/grype), [Trivy](https://trivy.dev/), [Dependency-Track](https://dependencytrack.org/)
+
+---
+
+### ๐ท Snyk: Developer-First SCA
+
+* ๐ฏ **Focus:** Developer experience + actionable results
+* โ
**Unique features:**
+ * Reachability analysis (reduce false positives 70%)
+ * Auto-fix PRs with tested upgrades
+ * IDE integration (VS Code, IntelliJ)
+ * Container + IaC scanning included
+* ๐ฐ **Pricing:** Free for individuals, paid for teams
+* ๐ **Website:** [snyk.io](https://snyk.io/)
+
+---
+
+### ๐ฆ
OWASP Dependency-Check
+
+* ๐๏ธ **Created by:** OWASP (2012)
+* ๐ **Completely free and open-source**
+* ๐ **Coverage:** Java (excellent), .NET, npm, Python, Ruby, Go
+* ๐๏ธ **Database:** NVD, npm audit, OSS Index, RetireJS
+* โ ๏ธ **Trade-off:** Slower but more comprehensive
+* ๐ **GitHub:** [github.com/jeremylong/DependencyCheck](https://github.com/jeremylong/DependencyCheck)
+
+---
+
+### โ Grype: Fast Container & Filesystem Scanner
+
+* ๐๏ธ **Created by:** Anchore (2020)
+* ๐ **Open-source, free**
+* ๐ฏ **Focus:** Container images, filesystems, **SBOMs**
+* โก **Speed:** Very fast (local database)
+* ๐ **SBOM support:** Can scan SBOMs directly (perfect for Lab 4 integration!)
+* ๐ **GitHub:** [github.com/anchore/grype](https://github.com/anchore/grype)
+
+---
+
+### ๐ท Trivy: Multi-Purpose Scanner
+
+* ๐๏ธ **Created by:** Aqua Security (2019)
+* ๐ **Open-source, free**
+* ๐ฏ **Scans:** Containers, filesystems, Git repos, IaC, Kubernetes, SBOMs
+* โก **Speed:** Extremely fast
+* ๐ **Versatility:** One tool for multiple use cases
+* ๐ **GitHub:** [github.com/aquasecurity/trivy](https://github.com/aquasecurity/trivy)
+
+---
+
+### ๐ Dependency-Track: Continuous SBOM Monitoring
+
+* ๐ฏ **Purpose:** Continuous monitoring platform for component risks
+* ๐ **Input:** Consumes SBOMs (SPDX, CycloneDX)
+* ๐ **Workflow:** Upload SBOM โ Continuous scanning โ Risk scoring โ Alerts
+* ๐ **Features:**
+ * Portfolio view (all applications in one dashboard)
+ * Policy engine (block deployments with violations)
+ * Risk trending over time
+ * Notifications (Slack, email, webhooks)
+* ๐ **Cost:** Open-source, free
+* ๐ **Website:** [dependencytrack.org](https://dependencytrack.org/)
+
+```mermaid
+flowchart LR
+ CI[๐ CI/CD] -->|Upload SBOM| DT[๐ Dependency-Track]
+ DT -->|Scan against| DB1[๐๏ธ NVD]
+ DT -->|Scan against| DB2[๐๏ธ OSV]
+ DT -->|Calculate| Risk[๐ Risk Score]
+ Risk --> Policy{๐ก๏ธ Policy Check}
+ Policy -->|โ
Pass| Deploy[๐ Deploy]
+ Policy -->|โ Fail| Block[๐ซ Block + Alert]
+
+ style DT fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+ style Deploy fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Block fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ก๏ธ Defense in Depth: Use Multiple Tools
+
+* ๐ฏ **Why multiple tools?**
+ * Different vulnerability databases (Snyk proprietary vs NVD vs OSV)
+ * Different matching algorithms (fewer false negatives)
+ * Different strengths (Grype for containers, Snyk for apps)
+* ๐ **Reality:** Each tool finds ~80% of vulnerabilities (different 80%!)
+* โ
**Together:** 95%+ coverage
+
+**Recommended combinations:**
+* ๐ **Free stack:** Grype + Trivy + GitHub Dependabot
+* ๐ฐ **Paid:** Snyk (primary) + Grype (containers)
+* ๐ข **Enterprise:** Snyk + Dependency-Track (continuous monitoring)
+
+
+๐ญ Pro Tip: How to integrate multiple tools?
+
+**CI/CD Strategy:**
+
+1. **โก Fast scans in PR:**
+ * Snyk or Grype (5-10 seconds)
+ * Fail build on critical/high
+
+2. **๐ Comprehensive scans in CI:**
+ * OWASP Dependency-Check (minutes)
+ * Trivy (all-in-one)
+ * Upload results to Dependency-Track
+
+3. **๐ Continuous monitoring:**
+ * Dependency-Track (SBOM-based)
+ * Daily/weekly rescans
+ * Alert on new CVEs
+
+4. **๐ค Automated updates:**
+ * Dependabot or Renovate
+ * Auto-fix PRs
+
+**Don't rely on just one tool!**
+
+
+---
+
+## ๐ Fun Break: "The Great npm Registry Outage (2021)"
+
+### ๐ฑ When JavaScript Stopped Working Globally
+
+**March 2021: The Day the Internet Forgot How to JavaScript**
+
+* ๐ **npm registry** = single point of failure for JavaScript
+* ๐ **Scale:** 13 billion packages downloaded per week
+* โก **Outage:** 4 hours offline
+* ๐ฅ **Impact:** Every CI/CD pipeline failed globally
+
+```mermaid
+flowchart LR
+ NPM[โ๏ธ npm Registry] -.->|๐ฅ OFFLINE| X[โ Down]
+
+ Dev[๐จโ๐ป Developers] --> NPM
+ CI[๐ CI/CD] --> NPM
+ Deploy[๐ Deployments] --> NPM
+
+ X -.->|โ| Dev
+ X -.->|โ| CI
+ X -.->|โ| Deploy
+
+ style NPM fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style X fill:#b71c1c,stroke:#d32f2f,stroke-width:3px,color:#fff
+```
+
+**The Chaos:**
+* ๐ฑ Developers couldn't install anything
+* ๐ฅ All builds failed worldwide
+* ๐ฆ Twitter exploded: "Is npm down or is it just me?"
+* โ Productivity increased (couldn't install packages, had to write code)
+
+**The Tweets:**
+* "npm is down. Productivity is up. Coincidence?"
+* "Breaking: Millions of developers suddenly productive"
+* "Just a reminder that the entire JavaScript ecosystem depends on a single server not having a bad day"
+
+**Lessons Learned:**
+* ๐ข **Private registries** โ Business continuity
+* ๐ฆ **Lockfiles + caching** โ Survive outages
+* ๐ **Registry mirrors** โ Redundancy
+* ๐ฏ **Dependency registries = critical infrastructure**
+
+**Fun Fact:** Stack Overflow traffic increased 300% during outage
+
+---
+
+๐ **Resources for Group 2:**
+* [Snyk Documentation](https://docs.snyk.io/)
+* [OWASP Dependency-Check](https://owasp.org/www-project-dependency-check/)
+* [Grype GitHub](https://github.com/anchore/grype)
+* [Trivy Documentation](https://trivy.dev/)
+* [Dependency-Track](https://dependencytrack.org/)
+* [CVSS Calculator](https://www.first.org/cvss/calculator/)
+* [EPSS Scores](https://www.first.org/epss/)
+* [CISA KEV Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
+
+---
+
+## ๐ Group 3: SBOM Analysis & Consumption
+
+## ๐ Slide 10 โ ๐ SBOM Formats: SPDX vs CycloneDX Deep Dive
+
+* ๐ **Lab 4 recap:** You generated SBOMs โ **Now learn to consume them**
+* ๐ **Two standards:** SPDX (license focus) vs CycloneDX (security focus)
+* ๐ฏ **Both are valid** โ Choose based on use case (or support both)
+
+```mermaid
+flowchart LR
+ SPDX[๐ SPDX
Linux Foundation] --> Legal[โ๏ธ License Compliance
ISO Standard]
+ CDX[๐ CycloneDX
OWASP] --> Security[๐ก๏ธ Vulnerability Tracking
DevSecOps]
+
+ style SPDX fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style CDX fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Format Comparison
+
+| Feature | SPDX | CycloneDX |
+|---------|------|-----------|
+| ๐
**Created** | 2010 (14 years) | 2017 (7 years) |
+| ๐๏ธ **Owner** | Linux Foundation | OWASP |
+| ๐ฏ **Focus** | Legal/License | Security/Supply Chain |
+| โ
**Status** | ISO/IEC 5962:2021 | ECMA (pending) |
+| ๐ **Formats** | JSON, YAML, XML, RDF, Tag-Value | JSON, XML, Protobuf |
+| ๐ **Vulnerabilities** | External references | Native fields |
+| ๐ **Services** | Limited | First-class support |
+| โก **Performance** | Slower (complex) | Faster (lightweight) |
+| ๐ข **Best For** | Government, Legal | Security tools, CI/CD |
+
+* ๐ **Specs:** [spdx.dev](https://spdx.dev/), [cyclonedx.org](https://cyclonedx.org/)
+
+---
+
+### ๐ When to Use Which
+
+**Use SPDX if:**
+* โ๏ธ License compliance is priority
+* ๐๏ธ Government/regulatory requirements (NTIA, EU)
+* ๐ฆ File-level granularity needed
+* ๐ค Cross-organization standardization
+
+**Use CycloneDX if:**
+* ๐ก๏ธ Security is primary focus
+* ๐ Continuous vulnerability monitoring
+* โก Performance matters (CI/CD)
+* ๐ฏ DevSecOps workflows
+
+**Best practice:** Generate both formats (most tools support it)
+
+
+๐ญ Can you convert between formats?
+
+**Yes, but with limitations:**
+
+* โ
**SPDX โ CycloneDX:** Community tools available
+* โ ๏ธ **CycloneDX โ SPDX:** Lossy conversion (some fields don't map)
+* ๐ ๏ธ **Best approach:** Generate both from source
+
+**Most SBOM tools (Syft, Trivy) can output both formats natively.**
+
+
+---
+
+## ๐ Slide 11 โ ๐ SBOM Consumption & Auditing
+
+* ๐ฏ **Problem:** SBOMs are useless unless analyzed and acted upon
+* ๐ **SBOM lifecycle:** Generate (Lab 4) โ **Analyze (This lab)** โ Act โ Monitor
+
+```mermaid
+flowchart LR
+ Lab4[๐๏ธ Generate
Lab 4] --> Analyze[๐ Analyze
Find Risks]
+ Analyze --> Vulnerabilities[๐จ Vulnerabilities]
+ Analyze --> Licenses[โ๏ธ Licenses]
+ Analyze --> Risks[๐ Component Risks]
+
+ Vulnerabilities --> Act[โก Take Action]
+ Licenses --> Act
+ Risks --> Act
+
+ Act --> Monitor[๐ Continuous
Monitoring]
+ Monitor -.->|New CVE| Analyze
+
+ style Lab4 fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Analyze fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐จ Identifying Risky Components
+
+**Red flags in SBOMs:**
+
+1. **โฐ Outdated packages:**
+ * Last updated > 2 years ago
+ * No active maintenance
+
+2. **๐ฅ Single maintainer:**
+ * "Bus factor" = 1
+ * Account takeover risk
+
+3. **๐ Low popularity:**
+ * < 100 downloads/week
+ * Small community
+
+4. **๐ Known vulnerabilities:**
+ * CVEs in external references
+ * High CVSS scores
+
+5. **โ๏ธ License risks:**
+ * AGPL, GPL (copyleft)
+ * Unknown/missing licenses
+
+6. **๐ New packages:**
+ * < 6 months old (not battle-tested)
+ * Potential typosquatting
+
+---
+
+### ๐ Component Pedigree Tracking
+
+* ๐ **Pedigree** = origin and history of component
+* ๐ฏ **Key questions:**
+ * Who created it?
+ * Where did it come from?
+ * Has it been modified?
+ * Can we verify authenticity?
+
+**SBOM fields for verification:**
+* **Supplier:** Who provides the component
+* **Download location:** Where obtained
+* **Hashes:** Verify integrity (SHA-256)
+* **External references:** Source repo, advisories
+
+---
+
+### ๐ SBOM Validation Tools
+
+* ๐ **NTIA minimum elements:** 7 required fields
+* โ
**Validation tools:**
+ * SPDX validation tools
+ * CycloneDX CLI validator
+ * NTIA conformance checker
+
+**Quality levels:**
+* **Basic (40%):** NTIA minimum elements
+* **Good (70%):** + licenses, hashes, references
+* **Excellent (90%):** + complete dependency graph, vulnerabilities
+* **Perfect (100%):** + signed, attested, continuously updated
+
+---
+
+## ๐ Slide 12 โ ๐ SBOM Diff Analysis & Change Tracking
+
+* ๐ **Purpose:** Track dependency changes over time
+* ๐ฏ **Use cases:**
+ * Detect new vulnerabilities after updates
+ * Audit supply chain changes
+ * Drift detection (production vs source)
+
+```mermaid
+flowchart LR
+ V1[๐ SBOM v1.0] --> Diff{๐ Diff}
+ V2[๐ SBOM v2.0] --> Diff
+
+ Diff --> Added[โ Added: 7]
+ Diff --> Removed[โ Removed: 2]
+ Diff --> Updated[๐ Updated: 15]
+
+ Added -.->|Check| Risks[๐จ New Risks?]
+ Updated -.->|Check| Fixed[โ
Fixes?]
+
+ style Diff fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+ style Risks fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ What to Analyze in Diffs
+
+**โ Added components:**
+* Expected new features?
+* Known vulnerabilities?
+* Compatible licenses?
+
+**โ Removed components:**
+* Actually removed from code?
+* Vulnerabilities addressed?
+
+**๐ Updated components:**
+* Security patches applied?
+* Breaking changes?
+* New transitive dependencies?
+
+**โ ๏ธ Changed metadata:**
+* Supplier changed? (ownership transfer risk)
+* Download location changed? (supply chain risk)
+
+---
+
+### ๐ Drift Detection
+
+* ๐ฏ **Drift** = difference between expected SBOM and actual runtime
+* ๐ฅ **Causes:**
+ * Manual production changes
+ * Compromised deployment
+ * SBOM generation bugs
+
+```mermaid
+flowchart LR
+ Expected[๐ Expected
From CI/CD] --> Compare{๐ Compare}
+ Actual[โก Runtime
Production] --> Compare
+
+ Compare -->|Match| Good[โ
No Drift]
+ Compare -->|Mismatch| Drift[๐จ INVESTIGATE]
+
+ style Expected fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Drift fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ Continuous SBOM Monitoring
+
+* ๐ **Track metrics over time:**
+ * Total components (trend)
+ * Known vulnerabilities (improving?)
+ * License violations
+ * Average component age
+ * Dependency depth
+
+* ๐ ๏ธ **Tool:** Dependency-Track (dashboards, alerts, trends)
+
+
+๐ญ When to regenerate SBOMs?
+
+**Regenerate on:**
+
+1. โ
**Every build** (CI/CD - best practice)
+2. โ
**Every release** (minimum requirement)
+3. โ
**Dependency updates** (compare before/after)
+4. โ
**Daily/weekly** (catch new CVEs)
+5. โ
**Security incidents** (audit deployed state)
+
+**Store SBOMs alongside artifacts (container registry, S3).**
+
+
+---
+
+## ๐ Slide 13 โ ๐ป Hands-On: SBOM-Driven Vulnerability Analysis
+
+* ๐ฏ **Goal:** Use Lab 4 SBOMs to find and fix vulnerabilities
+* ๐ง **Tools:** Grype, Dependency-Track
+* ๐ **Workflow:** SBOM โ Scan โ Prioritize โ Fix โ Verify
+
+```mermaid
+flowchart LR
+ Lab4[๐ Lab 4 SBOM] --> Grype[โ Grype Scan]
+ Grype --> Report[๐ Vulnerability Report]
+ Report --> Prioritize[๐ฏ Prioritize by CVSS/EPSS]
+ Prioritize --> Fix[๐ง Update Dependencies]
+ Fix --> Verify[โ
Rescan & Verify]
+
+ style Lab4 fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Grype fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### โ Task 1: Scan SBOM with Grype
+
+* ๐ฆ **Input:** SBOM from Lab 4 (CycloneDX or SPDX)
+* ๐ **Scan:** `grype sbom:sbom.cdx.json`
+* ๐ **Output:** Table of vulnerabilities (name, version, CVE, severity)
+
+---
+
+### ๐ Task 2: Set Up Dependency-Track
+
+* ๐ณ **Deploy:** Docker Compose (API server + frontend)
+* ๐ค **Upload:** SBOM via UI or API
+* ๐ **Dashboard:** View risk score, vulnerabilities, policy violations
+* ๐ **Alerts:** Configure Slack/email notifications
+
+---
+
+### ๐ฏ Task 3: Compare Multiple Tools
+
+* ๐ **Run:** Grype + Trivy + OWASP Dependency-Check
+* ๐ **Compare:** Different tools find different vulnerabilities
+* ๐ฏ **Why?** Different databases, algorithms, coverage
+* โ
**Defense in depth:** Use multiple tools
+
+---
+
+### ๐ง Task 4: Create Fix PR
+
+* ๐ **Branch:** `security/fix-sbom-vulnerabilities`
+* ๐ **Update:** Dependencies to patched versions
+* ๐ **Regenerate:** SBOM after fixes
+* โ
**Verify:** Rescan shows reduced vulnerabilities
+* ๐ค **Submit:** PR with before/after comparison
+
+---
+
+### ๐จ Task 5: Policy Enforcement
+
+* ๐ **Create policy:** Block Critical/High vulnerabilities
+* ๐ก๏ธ **Enforce:** Fail CI/CD if policy violated
+* ๐ **Alert:** Notify security team
+* ๐ **Track:** Policy compliance metrics
+
+---
+
+## ๐ญ Interactive Challenge: "SBOM Detective"
+
+**Scenario:** Which SBOM has highest risk?
+
+**SBOM A:** react 18.2.0, express 4.18.2, lodash 4.17.21, axios 1.6.0
+
+**SBOM B:** moment 2.29.4, request 2.88.2, lodash 4.17.19, colors 1.4.0
+
+**SBOM C:** left-pad 1.3.0, is-array 1.0.1, is-number 7.0.0, pad-left 2.1.0
+
+
+๐ Click for answer
+
+**SBOM B = HIGHEST RISK** ๐จ
+
+* moment 2.29.4 โ โ ๏ธ DEPRECATED
+* request 2.88.2 โ โ ๏ธ DEPRECATED (since 2020)
+* lodash 4.17.19 โ ๐ด CVE-2020-8203, CVE-2021-23337 (High)
+* colors 1.4.0 โ ๐ด Sabotaged by maintainer (2022)
+
+**Score: 9/10 - CRITICAL**
+
+**Lesson:** Old/deprecated packages = high risk!
+
+
+---
+
+๐ **Resources for Group 3:**
+* [SPDX Specification](https://spdx.dev/)
+* [CycloneDX Specification](https://cyclonedx.org/)
+* [Dependency-Track](https://dependencytrack.org/)
+* [Grype](https://github.com/anchore/grype)
+* [NTIA SBOM Guide](https://www.ntia.gov/sbom)
+
+---
+
+## ๐ Group 4: Artifact Signing & Provenance
+
+## ๐ Slide 14 โ โ๏ธ Code Signing & Artifact Integrity
+
+* โ๏ธ **Code signing** = cryptographic proof of authenticity and integrity
+* ๐ฏ **Purpose:** Verify artifacts haven't been tampered with
+* ๐ **Traditional approach:** X.509 certificates + private keys
+* โ ๏ธ **Problems with traditional signing:**
+ * Key management burden (storage, rotation, revocation)
+ * Long-lived keys = high risk if compromised
+ * Expensive PKI infrastructure
+ * Certificate expiration management
+
+```mermaid
+flowchart LR
+ Build[๐๏ธ Build Artifact] --> Sign[โ๏ธ Sign with Key]
+ Sign --> Artifact[๐ฆ Signed Artifact]
+ Artifact --> Deploy[๐ Deployment]
+ Deploy --> Verify[๐ Verify Signature]
+ Verify -->|โ
Valid| Run[โก Run]
+ Verify -->|โ Invalid| Block[๐ซ Block]
+
+ style Sign fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Run fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Block fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Why Signing Matters
+
+* ๐ก๏ธ **Authenticity:** Proves who built the artifact
+* ๐ **Integrity:** Detects tampering (even 1 byte changed)
+* ๐ **Non-repudiation:** Can't deny you signed it
+* ๐ฏ **Trust chain:** Build trust from source to production
+
+**Without signing:**
+* ๐ฅ Attacker replaces artifact in registry โ deployed to production
+* ๐ต๏ธ SolarWinds-style build system compromise goes undetected
+* โ No way to verify artifact authenticity
+
+---
+
+## ๐ Slide 15 โ ๐ Sigstore: Modern Signing Revolution
+
+* ๐๏ธ **Sigstore** = Linux Foundation project (2021)
+* ๐ฏ **Innovation:** Keyless signing + transparency logs
+* ๐ **Public good infrastructure** (free for all)
+
+### ๐ Three Pillars of Sigstore
+
+```mermaid
+flowchart LR
+ subgraph "๐ Sigstore Ecosystem"
+ Cosign[โ๏ธ Cosign
Sign & Verify]
+ Fulcio[๐ Fulcio
Certificate Authority]
+ Rekor[๐ Rekor
Transparency Log]
+ end
+
+ Developer[๐จโ๐ป Developer] -->|1. Authenticate| Fulcio
+ Fulcio -->|2. Short-lived cert| Cosign
+ Cosign -->|3. Sign artifact| Signed[๐ฆ Signed Artifact]
+ Cosign -->|4. Record in| Rekor
+
+ style Cosign fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Fulcio fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Rekor fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+```
+
+1. **โ๏ธ Cosign:** Sign and verify container images, blobs, SBOMs
+2. **๐ Fulcio:** Free CA issuing short-lived certificates (minutes, not years)
+3. **๐ Rekor:** Transparency log (immutable audit trail)
+
+---
+
+### ๐ Keyless Signing Workflow
+
+* ๐ฏ **Revolutionary:** No private keys to manage!
+* ๐ **OIDC authentication:** Use GitHub, Google, Microsoft identity
+* โฐ **Short-lived certificates:** Valid for 10 minutes (reduces risk)
+* ๐ **Transparency log:** Immutable proof of signing event
+
+**How it works:**
+1. Developer authenticates via OIDC (GitHub login)
+2. Fulcio issues short-lived certificate
+3. Cosign signs artifact with certificate
+4. Signature recorded in Rekor (public log)
+5. Certificate expires, but log entry proves it existed
+
+**Benefits:**
+* โ
No key storage (nothing to leak!)
+* โ
No key rotation (certs expire automatically)
+* โ
Transparency (all signatures public)
+* โ
Free infrastructure
+
+---
+
+### ๐ Industry Adoption
+
+* ๐ฆ **npm:** All packages signed with Sigstore (2023+)
+* ๐ **PyPI:** Sigstore signing available
+* โธ๏ธ **Kubernetes:** Release artifacts signed
+* ๐ **GitHub:** Actions can sign artifacts
+* ๐ **RubyGems:** Sigstore integration in progress
+
+* ๐ **Website:** [sigstore.dev](https://www.sigstore.dev/)
+
+
+๐ญ How is keyless signing secure without keys?
+
+**Trust model:**
+
+1. **Identity verification:** OIDC proves who you are (GitHub, Google)
+2. **Short-lived certificates:** Compromised cert expires in minutes
+3. **Transparency log:** Rekor provides non-repudiation (immutable proof)
+4. **Certificate chain:** Fulcio CA is trusted root
+
+**Security properties:**
+* ๐ Can't forge signatures (need valid OIDC identity)
+* ๐ Can't backdate signatures (Rekor timestamps are immutable)
+* โฐ Can't reuse compromised cert (expires in 10 minutes)
+
+**Trade-off:** Trust Sigstore infrastructure (but it's open, auditable, and run by Linux Foundation)
+
+
+---
+
+## ๐ Slide 16 โ ๐ Provenance & Build Attestations
+
+* ๐ **Provenance** = metadata about how artifact was built
+* ๐ฏ **Answers:** Who, what, when, where, how
+* ๐ **Prevents:** Supply chain attacks via build manipulation
+
+```mermaid
+flowchart LR
+ Source[๐ Source Code
github.com/user/repo
commit: abc123] --> Build[๐๏ธ Build System
GitHub Actions
builder: ubuntu-22.04]
+ Build --> Artifact[๐ฆ Artifact
container:v1.0]
+
+ Build -.->|Generates| Provenance[๐ Provenance
Signed attestation]
+ Provenance -->|Attached to| Artifact
+
+ Deploy[๐ Deployment] -->|Verifies| Provenance
+ Deploy -->|If valid| Run[โก Run]
+
+ style Provenance fill:#f3e5f5,stroke:#7b1fa2,stroke-width:3px,color:#2c3e50
+ style Run fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ What's in Provenance?
+
+**SLSA Provenance format includes:**
+* **Builder identity:** Who/what performed the build (GitHub Actions, GitLab CI)
+* **Source repository:** Git repo URL + commit SHA
+* **Build command:** How artifact was built
+* **Build timestamp:** When it was built
+* **Build materials:** Dependencies used
+* **Signing identity:** Who signed the provenance
+
+**Purpose:**
+* โ
Verify artifact came from expected source
+* โ
Detect build system compromises
+* โ
Ensure reproducible builds
+* โ
Audit trail for compliance
+
+---
+
+### ๐ In-toto Attestations Framework
+
+* ๐ **In-toto** = framework for securing software supply chain steps
+* ๐ฏ **Purpose:** Define and verify supply chain steps
+* ๐ **Attestation types:**
+ * Build provenance
+ * SBOM attestation
+ * Vulnerability scan results
+ * Code review approval
+
+* ๐ **Spec:** [in-toto.io](https://in-toto.io/)
+
+---
+
+### ๐ Reproducible Builds
+
+* ๐ฏ **Goal:** Same source code โ identical binary (bit-for-bit)
+* โ
**Benefit:** Verify binary matches source (no hidden code injection)
+* ๐ง **Challenges:**
+ * Timestamps in builds
+ * Non-deterministic build tools
+ * Build environment differences
+* ๐ **Projects:** Debian, Arch Linux, Bitcoin Core use reproducible builds
+
+---
+
+## ๐ Slide 17 โ ๐ป Hands-On: Signing & Provenance Verification
+
+* ๐ฏ **Goal:** Sign container images and generate provenance
+* ๐ง **Tools:** Cosign, GitHub Actions
+* ๐ **Workflow:** Build โ Sign โ Attest โ Verify โ Deploy
+
+```mermaid
+flowchart LR
+ Build[๐๏ธ Build Image] --> Sign[โ๏ธ Sign with Cosign]
+ Sign --> Provenance[๐ Generate Provenance]
+ Provenance --> SBOM[๐ Attach SBOM]
+ SBOM --> Push[๐ค Push to Registry]
+ Push --> Deploy[๐ Deployment]
+ Deploy --> Verify[๐ Verify All]
+ Verify -->|โ
Valid| Run[โก Run]
+ Verify -->|โ Invalid| Block[๐ซ Block]
+
+ style Sign fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Verify fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Run fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Block fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### โ๏ธ Task 1: Sign Container Image with Cosign
+
+* ๐ **Keyless signing** via GitHub OIDC
+* ๐ฆ **Sign:** Container image
+* ๐ **Transparency:** Recorded in Rekor
+
+---
+
+### ๐ Task 2: Generate SLSA Provenance
+
+* ๐๏ธ **Use:** GitHub Actions SLSA generator
+* ๐ **Generate:** Build provenance attestation
+* โ
**Achieve:** SLSA Level 3
+
+---
+
+### ๐ Task 3: Attach SBOM as Attestation
+
+* ๐ฆ **Attach:** Lab 4 SBOM to container image
+* ๐ **Link:** SBOM + signature + provenance
+* ๐ฏ **Result:** Complete artifact metadata
+
+---
+
+### ๐ Task 4: Verify in Deployment
+
+* ๐ก๏ธ **Policy:** Only deploy signed + attested images
+* โธ๏ธ **Kubernetes:** Use admission controller (Kyverno, OPA Gatekeeper)
+* โ
**Verify:** Signature + provenance before deployment
+
+---
+
+### ๐ Task 5: CI/CD Integration
+
+* ๐ **Workflow:** Build โ Scan โ Sign โ Attest โ Push โ Verify โ Deploy
+* ๐ค **Automation:** All steps in GitHub Actions
+* ๐ **Evidence:** Complete audit trail (SBOM, provenance, signatures)
+
+---
+
+## ๐ Fun Break: "The XZ Utils Backdoor (2024)"
+
+### ๐ต๏ธ The Most Sophisticated Supply Chain Attack Ever
+
+**The Setup:**
+* ๐ฆ **xz Utils** = compression library in every Linux distribution
+* ๐ฏ **Target:** SSH authentication via systemd
+
+**The Attack (2-year social engineering):**
+1. **2021:** Attacker creates GitHub account, contributes helpful patches
+2. **2022:** Gains trust, becomes regular contributor
+3. **2023:** Social engineers way to co-maintainer status
+4. **2024:** Injects sophisticated backdoor in build system
+5. **Discovery:** Microsoft engineer notices 500ms SSH delay
+
+```mermaid
+flowchart LR
+ Year1[2021
๐จโ๐ป Contributor] --> Year2[2022
๐ค Trusted Member]
+ Year2 --> Year3[2023
โ๏ธ Co-Maintainer]
+ Year3 --> Year4[2024
๐ Backdoor]
+ Year4 -.->|Almost| Disaster[๐ All Linux
Distributions]
+
+ Discovery[๐ Discovery
500ms SSH delay] -.->|Stopped| Year4
+
+ style Year4 fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style Disaster fill:#b71c1c,stroke:#d32f2f,stroke-width:3px,color:#fff
+ style Discovery fill:#e8f5e8,stroke:#388e3c,stroke-width:3px,color:#2c3e50
+```
+
+**The Sophistication:**
+* ๐ญ Multi-year social engineering
+* ๐ง Hidden in build scripts (not source code!)
+* ๐ต๏ธ Only activated for specific SSH configurations
+* ๐ Nearly compromised all major Linux distros
+
+**Why it Failed:**
+* โก Pure luck (500ms delay noticed)
+* โฐ Discovered before stable release
+
+**Lessons:**
+* ๐ **Provenance matters** (build system is critical)
+* ๐ **Build transparency** (know what's in your builds)
+* โ๏ธ **Signing alone isn't enough** (attacker had signing rights!)
+* ๐ฏ **SLSA Level 3+** would have detected this (hermetic builds)
+
+**The Hero:** Andres Freund (Microsoft engineer) noticed the SSH delay
+
+---
+
+๐ **Resources for Group 4:**
+* [Sigstore Documentation](https://docs.sigstore.dev/)
+* [Cosign](https://github.com/sigstore/cosign)
+* [SLSA Provenance](https://slsa.dev/provenance/)
+* [In-toto Framework](https://in-toto.io/)
+* [GitHub Actions SLSA Generator](https://github.com/slsa-framework/slsa-github-generator)
+
+---
+
+## ๐ Group 5: Advanced Supply Chain Security
+
+## ๐ Slide 18 โ ๐ฏ SLSA Framework Implementation
+
+* ๐ **SLSA (Supply Chain Levels for Software Artifacts)** = maturity model for supply chain security
+* ๐ **4 levels:** Progressive security guarantees (0-4)
+* ๐ฏ **Goal:** Achieve Level 3 (realistic for most teams)
+
+```mermaid
+flowchart LR
+ L0[๐ Level 0
No guarantees
Most software today] --> L1[๐ Level 1
Build documented
Basic provenance]
+ L1 --> L2[โ
Level 2
Signed provenance
Build service]
+ L2 --> L3[๐ Level 3
Hardened builds
Non-falsifiable]
+ L3 --> L4[๐ Level 4
Two-party review
Hermetic builds]
+
+ style L0 fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style L1 fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style L2 fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,color:#2c3e50
+ style L3 fill:#e8f5e8,stroke:#388e3c,stroke-width:3px,color:#2c3e50
+ style L4 fill:#1b5e20,stroke:#388e3c,stroke-width:3px,color:#fff
+```
+
+---
+
+### ๐ SLSA Level Requirements
+
+**Level 0:** No requirements (starting point)
+
+**Level 1:** Build process documented
+* โ
Provenance exists (who/what/when/how)
+
+**Level 2:** Build service generates signed provenance
+* โ
Authenticated identity (builder)
+* โ
Tamper-proof provenance
+
+**Level 3:** Hardened build platform
+* โ
Isolated build environment
+* โ
Non-falsifiable provenance
+* โ
**GitHub Actions can achieve this!**
+
+**Level 4:** Hermetic + two-party review
+* โ
Reproducible builds
+* โ
All changes reviewed by 2+ people
+* ๐ฏ Very few projects achieve this
+
+---
+
+### ๐ Achieving SLSA Level 3 with GitHub Actions
+
+* ๐ฏ **Good news:** GitHub Actions + SLSA generator = Level 3
+* ๐ง **Tools:** slsa-github-generator (official)
+* โ
**Requirements met:**
+ * Isolated build (GitHub-hosted runners)
+ * Non-falsifiable provenance (signed by GitHub)
+ * Build service (GitHub Actions)
+
+* ๐ **Tool:** [slsa-github-generator](https://github.com/slsa-framework/slsa-github-generator)
+
+
+๐ญ Why is Level 4 so hard?
+
+**Level 4 requirements:**
+
+1. **๐ Hermetic builds:**
+ * No network access during build
+ * All inputs declared upfront
+ * Reproducible bit-for-bit
+
+2. **๐ฅ Two-party review:**
+ * Every change reviewed by 2+ people
+ * No self-merge
+ * Enforced by platform
+
+**Challenges:**
+* ๐ฆ Most build tools fetch dependencies over network
+* โฐ Hermetic builds are slow (can't cache)
+* ๐ฅ Small teams struggle with 2-party review
+
+**Who achieves Level 4?**
+* ๐๏ธ Critical infrastructure (Kubernetes, Debian)
+* ๐ฐ Well-funded open source (large teams)
+* ๐ High-security environments
+
+**Most teams should aim for Level 3 (practical and effective).**
+
+
+---
+
+## ๐ Slide 19 โ ๐ Securing the Build Pipeline
+
+* ๐ฏ **SolarWinds lesson:** Build systems are critical infrastructure
+* ๐ฅ **If build is compromised:** Every artifact is poisoned
+* ๐ก๏ธ **Defense:** Harden build systems like production
+
+```mermaid
+flowchart LR
+ Source[๐ Clean Source] --> Build{๐๏ธ Build System}
+ Build -->|โ
Secure| Safe[๐ฆ Safe Artifact]
+ Build -->|๐ Compromised| Poisoned[โ ๏ธ Poisoned Artifact]
+
+ Poisoned --> Victims[๐ฏ All Users Affected]
+
+ style Build fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+ style Poisoned fill:#b71c1c,stroke:#d32f2f,stroke-width:3px,color:#fff
+ style Victims fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Build System Hardening
+
+**๐ Access control:**
+* Least privilege (minimal permissions)
+* MFA for all accounts
+* Audit logs
+
+**๐ก๏ธ Environment isolation:**
+* Ephemeral build environments
+* No persistent state
+* Network segmentation
+
+**๐ Provenance generation:**
+* Automatic build attestations
+* Signed by build system
+* Immutable audit trail
+
+**๐ Monitoring:**
+* Build duration anomalies
+* Unexpected network access
+* File system changes
+
+---
+
+### ๐๏ธ Hermetic Builds
+
+* ๐ฏ **Hermetic** = completely isolated, no external dependencies
+* ๐ **Characteristics:**
+ * No network access during build
+ * All inputs declared in manifest
+ * Reproducible (same inputs โ same output)
+* โ
**Benefits:**
+ * Can't fetch malicious dependencies
+ * Can't exfiltrate secrets
+ * Reproducible = verifiable
+
+**Tools:**
+* ๐ณ Docker (with network disabled)
+* ๐ฆ Bazel (hermetic by design)
+* ๐ง Nix (functional package manager)
+
+---
+
+### โ ๏ธ GitHub Actions Security
+
+**๐ด Common mistakes:**
+
+1. **Using `pull_request_target` with untrusted code**
+ * ๐จ Allows untrusted PRs to access secrets
+
+2. **Not pinning actions by SHA**
+ * ๐จ Action maintainer can inject malicious code
+
+3. **Overly permissive `GITHUB_TOKEN`**
+ * ๐จ Default permissions too broad
+
+4. **Secrets in build logs**
+ * ๐จ Can leak via debug output
+
+**โ
Best practices:**
+* Pin actions by commit SHA (not tag)
+* Minimal `GITHUB_TOKEN` permissions
+* Use `pull_request` (not `pull_request_target`)
+* Separate workflows for untrusted code
+
+---
+
+## ๐ Slide 20 โ ๐ Runtime Supply Chain Security
+
+* ๐ฏ **Problem:** Security doesn't end at deployment
+* ๐ **Continuous:** Monitor supply chain in production
+* ๐ก๏ธ **Policy enforcement:** Only run verified artifacts
+
+```mermaid
+flowchart LR
+ Deploy[๐ Deployment] --> Admission[๐ก๏ธ Admission Control]
+ Admission -->|Check| Signature{โ๏ธ Signed?}
+ Admission -->|Check| Provenance{๐ Provenance?}
+ Admission -->|Check| Policy{๐ Policy OK?}
+
+ Signature -->|โ No| Block[๐ซ Block]
+ Provenance -->|โ No| Block
+ Policy -->|โ Fail| Block
+
+ Signature -->|โ
Yes| Allow[โก Allow]
+ Provenance -->|โ
Yes| Allow
+ Policy -->|โ
Pass| Allow
+
+ Allow --> Runtime[๐ Runtime Monitoring]
+
+ style Admission fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+ style Block fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Allow fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ก๏ธ Kubernetes Admission Controllers
+
+* ๐ฏ **Purpose:** Enforce policies at deployment time
+* ๐ง **Tools:**
+ * **Kyverno** (Kubernetes-native, easy YAML policies)
+ * **OPA Gatekeeper** (powerful, Rego policies)
+ * **Cosign Policy Controller** (signature verification)
+
+**Example policies:**
+* โ
Only deploy signed images
+* โ
Require valid SLSA provenance
+* โ
Block images with critical vulnerabilities
+* โ
Enforce SBOM attestation
+
+---
+
+### ๐ Runtime Drift Detection
+
+* ๐ฏ **Drift** = production doesn't match expected SBOM
+* ๐ **Detection methods:**
+ * Compare runtime SBOM vs build SBOM
+ * Monitor for unexpected processes
+ * File integrity monitoring
+* ๐จ **Alert:** Unauthorized changes
+
+---
+
+### ๐ Continuous Supply Chain Monitoring
+
+**Monitor for:**
+* ๐จ New CVEs in deployed components
+* ๐ SBOM changes (drift)
+* โ ๏ธ Policy violations
+* ๐ License compliance
+
+**Tools:**
+* Dependency-Track (SBOM monitoring)
+* Falco (runtime security)
+* Tetragon (eBPF-based monitoring)
+
+---
+
+### ๐ Supply Chain Security Metrics
+
+**Track:**
+* ๐ % artifacts signed
+* ๐ % artifacts with provenance
+* ๐ % SBOMs generated
+* ๐ฏ SLSA level distribution
+* โฐ Mean time to patch vulnerabilities
+* ๐ Policy compliance rate
+
+**Goal:** Continuous improvement
+
+
+๐ญ Complete Supply Chain Security Checklist
+
+**โ
Development:**
+* Lockfiles committed
+* Dependency updates automated
+* Pre-commit secret scanning
+
+**โ
Build:**
+* SBOM generated
+* Artifacts signed (Cosign)
+* Provenance generated (SLSA)
+* Vulnerability scanning
+
+**โ
Registry:**
+* Image scanning on push
+* Policy enforcement
+* SBOM storage
+
+**โ
Deployment:**
+* Signature verification
+* Provenance verification
+* Admission control policies
+
+**โ
Runtime:**
+* Continuous monitoring
+* Drift detection
+* New CVE alerts
+
+**Goal:** Defense in depth at every stage
+
+
+---
+
+## ๐ Fun Break: "The Dependency Confusion Gold Rush (2021)"
+
+### ๐ฐ How One Researcher Made $130K Finding a New Attack
+
+**February 2021: Alex Birsan discovers dependency confusion**
+
+**The Attack:**
+1. Companies use internal packages: `@company/auth-lib`
+2. Package manager checks: internal registry โ public npm
+3. Public npm has higher version โ **installs public package!**
+4. Attacker publishes malicious `company-auth-lib` v99.0
+
+```mermaid
+flowchart LR
+ Dev[๐จโ๐ป Developer
npm install @company/auth] --> Check{๐ฆ Package Manager}
+ Check -->|Check| Internal[๐ข Internal Registry
v1.0.0]
+ Check -->|Check| Public[๐ Public npm
v99.0.0 ๐]
+ Check -->|Higher version!| Install[๐ฅ Installs Public]
+
+ Install --> Compromised[๐ Company Compromised]
+
+ style Public fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style Compromised fill:#b71c1c,stroke:#d32f2f,stroke-width:3px,color:#fff
+```
+
+**The Gold Rush:**
+* ๐ Alex targets 35+ companies
+* ๐ฆ Publishes "security research" packages
+* ๐ฐ Companies pay bug bounties: **$130,000 total**
+* ๐ฏ Victims: Apple, Microsoft, Tesla, Uber, PayPal, Netflix
+
+**The Impact:**
+* ๐ฅ Thousands of companies vulnerable
+* ๐ Package managers add protections
+* ๐ข Companies create private registries
+
+**The Fix:**
+* ๐ Namespace scoping (`@company/` on private registry)
+* ๐ก๏ธ Registry priority configuration
+* ๐ฆ Internal package allowlisting
+
+**Lesson:** Supply chain attacks are profitable (for attackers AND researchers)
+
+---
+
+## ๐ Summary: Key Takeaways
+
+### โ
Core Principles
+
+* ๐ **Modern software = complex supply chains** (200+ dependencies)
+* ๐ **SBOMs provide transparency** (Lab 4: generate โ Lab 8: analyze)
+* ๐ **SCA tools find vulnerabilities** (use multiple tools)
+* โ๏ธ **Signing ensures authenticity** (Sigstore makes it easy)
+* ๐ **Provenance proves secure builds** (SLSA framework)
+* ๐ค **Automation is essential** (too complex for manual tracking)
+* ๐ **Continuous monitoring catches new threats** (Dependency-Track)
+* ๐จ **Policy enforcement prevents risky deployments** (admission controllers)
+
+---
+
+### ๐ฏ Practical Actions
+
+**๐๏ธ This week:**
+1. Generate SBOMs in CI/CD (if not from Lab 4)
+2. Scan with Grype or Trivy
+3. Sign one artifact with Cosign
+
+**๐ This month:**
+1. Set up Dependency-Track
+2. Generate provenance attestations
+3. Create security policies
+
+**๐ This quarter:**
+1. Achieve SLSA Level 3
+2. Automate dependency updates
+3. Continuous supply chain monitoring
+
+---
+
+### ๐ Essential Resources
+
+**๐ Frameworks:**
+* [SLSA](https://slsa.dev/)
+* [NIST SSDF](https://csrc.nist.gov/Projects/ssdf)
+* [OWASP SCVS](https://scvs.owasp.org/)
+
+**โ๏ธ Signing:**
+* [Sigstore](https://www.sigstore.dev/)
+* [Cosign](https://github.com/sigstore/cosign)
+
+**๐ SBOM:**
+* [SPDX](https://spdx.dev/)
+* [CycloneDX](https://cyclonedx.org/)
+
+**๐ ๏ธ Tools:**
+* [Syft](https://github.com/anchore/syft)
+* [Grype](https://github.com/anchore/grype)
+* [Dependency-Track](https://dependencytrack.org/)
+
+**๐๏ธ Databases:**
+* [OSV](https://osv.dev/)
+* [NVD](https://nvd.nist.gov/)
+* [CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
+
+---
\ No newline at end of file
diff --git a/lectures/lec9.md b/lectures/lec9.md
new file mode 100644
index 00000000..577c0d25
--- /dev/null
+++ b/lectures/lec9.md
@@ -0,0 +1,2872 @@
+# ๐ Lecture 9 - Monitoring, Compliance & Improvement: Security Operations & Maturity
+
+## ๐ Group 1: Security Observability
+
+## ๐ Slide 1 โ ๐ Security Monitoring in DevSecOps
+
+* ๐ **Security monitoring** = continuous visibility into security posture across SDLC
+* ๐ฏ **Shift:** Reactive (after breach) โ Proactive (before exploit)
+* ๐ฐ **Cost of delayed detection:**
+ * Average breach detection time: **207 days** (IBM 2024)
+ * Cost per day undetected: **$1.2M+**
+ * Early detection (< 30 days) saves **$1M on average**
+* ๐ฅ **Famous delayed detections:**
+ * **SolarWinds (2020):** 9 months undetected โ 18,000 organizations compromised
+ * **Equifax (2017):** 76 days undetected โ 147M records stolen
+ * **Target (2013):** 19 days with alerts ignored โ $18M settlement
+* ๐ **Learn more:** [IBM Cost of Data Breach Report](https://www.ibm.com/security/data-breach), [Ponemon Cost of Cyber Crime](https://www.ponemon.org/)
+
+```mermaid
+flowchart LR
+ Traditional[๐จ Traditional Security
React after breach] -->|Days/months| Detect1[๐ Detect]
+ Detect1 -->|Cleanup| Cost1[๐ฐ High Cost
$4.5M average]
+
+ DevSecOps[โ
DevSecOps Monitoring
Continuous visibility] -->|Minutes/hours| Detect2[๐ Detect]
+ Detect2 -->|Fast response| Cost2[๐ฐ Lower Cost
$1M saved]
+
+ style Traditional fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style DevSecOps fill:#e8f5e8,stroke:#388e3c,stroke-width:3px,color:#2c3e50
+ style Cost1 fill:#ffcdd2,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Cost2 fill:#c8e6c9,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Monitoring as Feedback Loop
+
+* ๐ฏ **Purpose:** Learn and improve continuously
+* ๐ **Cycle:** Monitor โ Detect โ Respond โ Analyze โ Improve โ Monitor
+* โ
**Benefits:**
+ * Catch issues earlier in SDLC
+ * Validate security controls work
+ * Measure improvement over time
+ * Evidence for compliance
+
+```mermaid
+flowchart LR
+ Monitor[๐ Monitor
Collect signals] --> Detect[๐ Detect
Identify issues]
+ Detect --> Respond[โก Respond
Fix & contain]
+ Respond --> Analyze[๐ง Analyze
Root cause]
+ Analyze --> Improve[๐ Improve
Prevent recurrence]
+ Improve --> Monitor
+
+ style Monitor fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Detect fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Respond fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Analyze fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ style Improve fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ฏ Why Continuous Monitoring Matters
+
+* โฐ **New vulnerabilities discovered daily:**
+ * Average: **50+ CVEs per day**
+ * Your dependencies get new CVEs after deployment
+ * Zero-days emerge (Log4Shell, Heartbleed)
+* ๐ **Configuration drift:**
+ * Production changes without approval
+ * Unauthorized deployments
+ * Expired certificates
+* ๐จ **Runtime threats:**
+ * Exploitation attempts
+ * Unusual network activity
+ * Privilege escalation
+
+**Without monitoring:** You're flying blind ๐
+
+
+๐ญ Discussion: What's worse - no monitoring or alert fatigue?
+
+**No monitoring:**
+* โ Breaches go undetected for months
+* โ No evidence for compliance
+* โ Can't measure improvement
+
+**Alert fatigue:**
+* โ ๏ธ Real alerts ignored (signal-to-noise problem)
+* โ ๏ธ Teams become desensitized
+* โ ๏ธ Critical alerts missed in noise
+
+**The Answer:** Neither! You need **smart monitoring**:
+* โ
Focus on high-signal alerts (reduce noise)
+* โ
Automate responses where possible
+* โ
Context-aware alerting (not everything is Critical)
+* โ
Regular tuning (remove false positives)
+
+**Key metric:** Alert signal-to-noise ratio should be > 80% actionable
+
+
+---
+
+## ๐ Slide 2 โ ๐ What to Monitor: Logs, Metrics, Traces
+
+* ๐ **Observability = Logs + Metrics + Traces** (three pillars)
+* ๐ฏ **Monitoring = subset of observability** (predefined dashboards/alerts)
+* ๐ **Security observability:** Apply three pillars to security signals
+
+```mermaid
+flowchart LR
+ subgraph "๐ Three Pillars of Observability"
+ Logs[๐ Logs
What happened]
+ Metrics[๐ Metrics
How much/how fast]
+ Traces[๐ Traces
Request flow]
+ end
+
+ Logs --> Security[๐ก๏ธ Security
Observability]
+ Metrics --> Security
+ Traces --> Security
+
+ Security --> Detect[๐ Detect Threats]
+ Security --> Measure[๐ Measure Posture]
+ Security --> Improve[๐ Improve Programs]
+
+ style Security fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ Logs: What Happened
+
+* ๐ฏ **Security logs to collect:**
+ * **Authentication logs** (who logged in, failed attempts)
+ * **Authorization logs** (who accessed what, permission denials)
+ * **Audit logs** (configuration changes, policy updates)
+ * **Security tool outputs** (scan results, alerts)
+ * **Pipeline logs** (build failures, security gate blocks)
+ * **Application logs** (errors, exceptions, suspicious patterns)
+* ๐ **Use cases:**
+ * Incident investigation (what happened?)
+ * Compliance evidence (audit trail)
+ * Anomaly detection (unusual patterns)
+* โ ๏ธ **Challenge:** Log volume (terabytes/day in large orgs)
+
+---
+
+### ๐ Metrics: How Much / How Fast
+
+* ๐ฏ **Security metrics to track:**
+ * **Vulnerability counts** (total, by severity)
+ * **Detection times** (MTTD - Mean Time to Detect)
+ * **Response times** (MTTR - Mean Time to Respond)
+ * **Deployment frequency** (with security gates)
+ * **Security test coverage** (% of code scanned)
+ * **Policy violations** (count, trends)
+ * **False positive rate** (alert accuracy)
+* ๐ **Use cases:**
+ * Trend analysis (improving or degrading?)
+ * SLA tracking (meeting targets?)
+ * Capacity planning (security team workload)
+* โ
**Advantage:** Time-series data enables predictions
+
+---
+
+### ๐ Traces: Request Flow
+
+* ๐ฏ **Security-relevant traces:**
+ * **API call chains** (which services talked to which)
+ * **Authentication flows** (token passing, validation)
+ * **Data access patterns** (which user accessed sensitive data)
+ * **Dependency calls** (external API usage)
+* ๐ **Use cases:**
+ * Lateral movement detection (attacker pivoting)
+ * Privilege escalation tracking
+ * Data exfiltration paths
+ * Understanding blast radius
+* ๐ ๏ธ **Tools:** OpenTelemetry, Jaeger, Zipkin (with security context)
+
+---
+
+### ๐ก๏ธ Security-Specific Monitoring Needs
+
+**Beyond traditional observability:**
+
+* ๐จ **Vulnerability trends:**
+ * New vulnerabilities discovered
+ * Vulnerability backlog growth
+ * Fix rates by severity
+* ๐ **Deployment security gates:**
+ * % deployments blocked
+ * Reasons for blocks
+ * Override frequency
+* โ **Failed security scans:**
+ * Which scans failed
+ * Failure patterns
+ * Recurrence of same issues
+* ๐ **Policy violations:**
+ * Which policies violated most
+ * By team/service
+ * Trends over time
+* โฑ๏ธ **Incident response:**
+ * Response times by severity
+ * Escalation patterns
+ * Resolution effectiveness
+
+```mermaid
+flowchart LR
+ subgraph "๐๏ธ Data Sources"
+ SIEM[๐ก๏ธ SIEM]
+ Scanners[๐ Security Scanners]
+ CICD[๐ CI/CD Systems]
+ Runtime[โก Runtime Agents]
+ Cloud[โ๏ธ Cloud APIs]
+ end
+
+ SIEM --> Aggregate[๐ Aggregation Layer]
+ Scanners --> Aggregate
+ CICD --> Aggregate
+ Runtime --> Aggregate
+ Cloud --> Aggregate
+
+ Aggregate --> Dashboard[๐ Security Dashboards]
+ Aggregate --> Alerts[๐จ Alerting]
+ Aggregate --> Reports[๐ Compliance Reports]
+
+ style Aggregate fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+```
+
+
+๐ญ Question: Should security use the same observability stack as operations?
+
+**Arguments for sharing:**
+* โ
Correlated data (security + performance together)
+* โ
Cost savings (one platform)
+* โ
Developer familiarity (one tool to learn)
+* โ
Easier incident response (unified view)
+
+**Arguments for separation:**
+* โ ๏ธ Access control (security data is sensitive)
+* โ ๏ธ Retention requirements (compliance needs longer retention)
+* โ ๏ธ Security-specific features (threat intel, CVSS scoring)
+* โ ๏ธ Performance (security logs are high-volume)
+
+**Best Practice:** Hybrid approach
+* ๐ฏ Use shared observability platform (Datadog, Splunk, ELK)
+* ๐ Add security-specific overlays (security dashboards, RBAC)
+* ๐ Integrate security tools (feed data into observability platform)
+* ๐ก๏ธ Separate retention/access for sensitive security data
+
+**Modern trend:** Security observability built into platform (not separate)
+
+
+---
+
+## ๐ Slide 3 โ ๐ ๏ธ Security Monitoring Tools & Platforms
+
+* ๐ฏ **Tool categories:** SIEM, dashboards, vulnerability platforms, CSPM, observability
+* ๐ **No single tool does everything** โ integrated ecosystem
+* ๐ **Choose based on:** Scale, budget, existing tools, team skills
+
+```mermaid
+flowchart LR
+ subgraph "๐ ๏ธ Security Monitoring Ecosystem"
+ SIEM[๐ก๏ธ SIEM
Splunk, ELK]
+ Dash[๐ Dashboards
Grafana, Kibana]
+ Vuln[๐ Vuln Management
DefectDojo, Dependency-Track]
+ CSPM[โ๏ธ CSPM
Prisma, Wiz]
+ Obs[๐ Observability
Datadog, New Relic]
+ end
+
+ Sources[๐๏ธ Security Data
Scanners, CI/CD, Cloud] --> SIEM
+ Sources --> Dash
+ Sources --> Vuln
+ Sources --> CSPM
+ Sources --> Obs
+
+ SIEM --> Teams[๐ฅ Security Teams]
+ Dash --> Teams
+ Vuln --> Teams
+ CSPM --> Teams
+ Obs --> Teams
+
+ style Sources fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Teams fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ก๏ธ SIEM (Security Information and Event Management)
+
+* ๐ฏ **Purpose:** Centralized log aggregation, correlation, alerting
+* ๐ **Core capabilities:**
+ * Log collection from multiple sources
+ * Real-time correlation (detect patterns)
+ * Alerting and incident management
+ * Long-term retention (compliance)
+ * Threat intelligence integration
+* ๐ ๏ธ **Popular platforms:**
+ * **Splunk** (enterprise, expensive, powerful)
+ * **ELK Stack** (Elasticsearch, Logstash, Kibana - open-source)
+ * **QRadar** (IBM, enterprise)
+ * **Azure Sentinel** (cloud-native, Microsoft)
+ * **Sumo Logic** (SaaS, modern)
+* โ ๏ธ **Challenge:** High cost (license + storage), complex setup
+* ๐ **Resources:** [Splunk](https://www.splunk.com/), [Elastic Security](https://www.elastic.co/security)
+
+---
+
+### ๐ Security Dashboards
+
+* ๐ฏ **Purpose:** Visualize security metrics and trends
+* ๐ **Dashboard types:**
+ * **Executive dashboard** (high-level, risk scores)
+ * **Manager dashboard** (team metrics, SLAs)
+ * **Engineer dashboard** (detailed vulnerabilities, remediation)
+* ๐ ๏ธ **Popular tools:**
+ * **Grafana** (open-source, flexible, integrates everything)
+ * **Kibana** (part of ELK stack)
+ * **Datadog** (SaaS, modern UI)
+ * **Tableau/PowerBI** (for compliance reporting)
+* โ
**Best practice:** Different dashboards for different audiences
+* ๐ **Resources:** [Grafana](https://grafana.com/), [Kibana](https://www.elastic.co/kibana)
+
+---
+
+### ๐ Vulnerability Management Platforms
+
+* ๐ฏ **Purpose:** Aggregate, deduplicate, track vulnerabilities
+* ๐ **Core capabilities:**
+ * Import from multiple scanners (SAST, DAST, SCA)
+ * Deduplication (same vuln from multiple tools)
+ * Risk scoring and prioritization
+ * Workflow management (assign, track, verify)
+ * Reporting and metrics
+* ๐ ๏ธ **Popular platforms:**
+ * **DefectDojo** (open-source, developer-friendly)
+ * **Dependency-Track** (SBOM-based, open-source)
+ * **ThreadFix** (commercial, enterprise)
+ * **Jira + plugins** (many teams use issue trackers)
+* โ
**Integration:** Should integrate with CI/CD and dashboards
+* ๐ **Resources:** [DefectDojo](https://www.defectdojo.org/), [Dependency-Track](https://dependencytrack.org/)
+
+---
+
+### โ๏ธ CSPM (Cloud Security Posture Management)
+
+* ๐ฏ **Purpose:** Monitor cloud configuration compliance
+* ๐ **What it monitors:**
+ * Misconfigured resources (public S3 buckets)
+ * IAM overpermissions (too many admin accounts)
+ * Network security (open security groups)
+ * Compliance violations (CIS benchmarks)
+ * Configuration drift (unauthorized changes)
+* ๐ ๏ธ **Popular platforms:**
+ * **Prisma Cloud** (Palo Alto, multi-cloud)
+ * **Wiz** (modern, developer-friendly)
+ * **Orca Security** (agentless)
+ * **AWS Security Hub** (AWS-native)
+ * **Azure Defender** (Azure-native)
+ * **Open-source:** Prowler, ScoutSuite, CloudSploit
+* ๐ **Covered in:** Lab 6 (IaC Security)
+* ๐ **Resources:** [Prowler](https://github.com/prowler-cloud/prowler), [Wiz](https://www.wiz.io/)
+
+---
+
+### ๐ Observability Platforms with Security
+
+* ๐ฏ **Modern trend:** Unified observability + security
+* ๐ **Platforms adding security features:**
+ * **Datadog** (APM + security monitoring)
+ * **New Relic** (observability + vulnerability management)
+ * **Dynatrace** (performance + runtime security)
+ * **Elastic** (observability + SIEM in one)
+* โ
**Advantage:** Correlated security + performance data
+* ๐ **Use case:** See security issues alongside performance issues
+* ๐ **Resources:** [Datadog Security](https://www.datadoghq.com/product/security-platform/), [Elastic Observability](https://www.elastic.co/observability)
+
+---
+
+### ๐๏ธ Building Your Security Monitoring Stack
+
+**Typical evolution:**
+
+**Stage 1 (Small teams):**
+* ๐ Grafana + Prometheus (metrics)
+* ๐ ELK or Loki (logs)
+* ๐ DefectDojo or Jira (vulnerabilities)
+
+**Stage 2 (Growth):**
+* โ Add SIEM (Splunk or Elastic Security)
+* โ Add CSPM (cloud-specific tools)
+* โ Integrate security tools into observability
+
+**Stage 3 (Enterprise):**
+* ๐ข Commercial unified platform (Datadog, Splunk)
+* ๐ Full automation (API integrations)
+* ๐ค AI/ML for anomaly detection
+
+```mermaid
+flowchart LR
+ Stage1[๐ฑ Stage 1
Grafana + ELK + Jira] --> Stage2[๐ Stage 2
+ SIEM + CSPM]
+ Stage2 --> Stage3[๐ข Stage 3
Unified Platform]
+
+ style Stage1 fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Stage2 fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Stage3 fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+
+๐ญ Best Practice: Start simple, grow as needed
+
+**Avoid the trap:** Buying expensive enterprise SIEM on day 1
+
+**Better approach:**
+
+**Month 1:**
+* โ
Start with free tools (Grafana, ELK)
+* โ
Focus on key metrics (vulnerabilities, deployment frequency)
+* โ
Manual processes are OK initially
+
+**Month 3:**
+* โ
Automate data collection (CI/CD integration)
+* โ
Add basic alerting (critical vulns, failed deployments)
+* โ
Create team dashboards
+
+**Month 6:**
+* โ
Evaluate commercial tools (if free tools limiting)
+* โ
Add advanced features (anomaly detection, correlation)
+* โ
Integrate threat intelligence
+
+**Month 12:**
+* โ
Mature monitoring program
+* โ
Evidence-based tool decisions
+* โ
Proven ROI before big investments
+
+**Key insight:** Your monitoring needs will change as you grow. Build for now, plan for future.
+
+
+---
+
+๐ **Resources for Group 1:**
+* [IBM Cost of Data Breach Report](https://www.ibm.com/security/data-breach)
+* [NIST Cybersecurity Framework: Detect Function](https://www.nist.gov/cyberframework/detect)
+* [Grafana Security Dashboards](https://grafana.com/grafana/dashboards/?search=security)
+* [DefectDojo](https://www.defectdojo.org/)
+* [Elastic Security](https://www.elastic.co/security)
+* [OpenTelemetry Security](https://opentelemetry.io/)
+
+---
+
+## ๐ Group 2: Security Metrics & KPIs
+
+## ๐ Slide 4 โ ๐ Security Metrics vs Vanity Metrics
+
+* ๐ **Metric** = quantifiable measurement of security program effectiveness
+* ๐ฏ **KPI (Key Performance Indicator)** = metric tied to business objectives
+* โ ๏ธ **Vanity metric** = looks impressive but doesn't drive decisions
+* ๐ **Goal:** Measure what matters, not what's easy to count
+
+```mermaid
+flowchart LR
+ Vanity[๐ Vanity Metrics
Look good, no action] --> Examples1[๐ Total scans run
๐ Lines of code
๐ # of security tools]
+
+ Actionable[โ
Actionable Metrics
Drive decisions] --> Examples2[โฑ๏ธ Time to fix critical vulns
๐ Vulnerability trends
๐ฏ Policy compliance rate]
+
+ Examples1 -.->|No impact| Decision1[โ What do we do?]
+ Examples2 -->|Clear action| Decision2[โ
Fix, improve, adjust]
+
+ style Vanity fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Actionable fill:#e8f5e8,stroke:#388e3c,stroke-width:3px,color:#2c3e50
+ style Decision2 fill:#c8e6c9,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Vanity Metrics (Avoid These)
+
+**Look impressive but don't help:**
+
+* โ **Total number of scans run** (doesn't mean code is secure)
+* โ **Lines of code scanned** (quantity โ quality)
+* โ **Number of security tools deployed** (tool sprawl โ security)
+* โ **Total vulnerabilities found** (without context of severity/age)
+* โ **Number of security meetings** (meetings โ action)
+* โ **Security training completion rate** (completion โ behavior change)
+
+**Why they're bad:**
+* ๐ฏ No actionable insight (what should we do?)
+* ๐ Can be gamed (inflate numbers without improving security)
+* ๐ผ Create false confidence (high numbers โ secure)
+
+---
+
+### โ
Actionable Metrics (Use These)
+
+**Drive real decisions:**
+
+* โ
**Mean Time to Remediate (MTTR)** โ Are we getting faster?
+* โ
**Vulnerability backlog trend** โ Growing or shrinking?
+* โ
**Deployment security gate pass rate** โ Quality improving?
+* โ
**Critical vulnerability age** โ Old vulns still open?
+* โ
**False positive rate** โ Are alerts useful?
+* โ
**Policy compliance rate** โ Meeting standards?
+* โ
**Security test coverage** โ Blind spots?
+
+**Why they're good:**
+* ๐ฏ Clear action (if metric is bad, we know what to fix)
+* ๐ Tied to business impact (reduce risk, improve speed)
+* ๐ Show trends (improving or degrading?)
+
+```mermaid
+flowchart LR
+ Metric[๐ Metric: MTTR = 45 days] --> Question{๐ค Is this good?}
+ Question -->|Benchmark| Industry[๐ Industry: 30 days]
+ Question -->|Trend| Previous[๐ Last quarter: 60 days]
+
+ Industry -->|We're slower| Action1[โก Action: Prioritize faster fixes]
+ Previous -->|We're improving| Action2[โ
Keep current approach]
+
+ style Metric fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Action1 fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Action2 fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ SMART Criteria for Security Metrics
+
+* ๐ **Specific:** Clear definition (no ambiguity)
+* ๐ **Measurable:** Quantifiable (numbers, not feelings)
+* ๐ฏ **Achievable:** Realistic targets (not impossible goals)
+* ๐ **Relevant:** Tied to business objectives (reduce risk, enable speed)
+* โฐ **Time-bound:** Defined timeframe (monthly, quarterly)
+
+**Example:**
+
+**โ Bad metric:** "Improve security"
+* Not specific, not measurable, no timeframe
+
+**โ
Good metric:** "Reduce MTTR for critical vulnerabilities from 45 days to 30 days by Q3 2024"
+* Specific (MTTR, critical vulns)
+* Measurable (45 โ 30 days)
+* Achievable (33% improvement)
+* Relevant (faster fixes = lower risk)
+* Time-bound (Q3 2024)
+
+---
+
+### ๐ Leading vs Lagging Indicators
+
+* ๐ฎ **Leading indicators:** Predict future outcomes (proactive)
+* ๐ **Lagging indicators:** Measure past results (reactive)
+
+| Type | Examples | Use Case |
+|------|----------|----------|
+| ๐ฎ **Leading** | โข Security test coverage
โข Pre-commit scan adoption
โข Training completion | Predict future security posture |
+| ๐ **Lagging** | โข Vulnerabilities found in prod
โข Breach incidents
โข MTTR | Measure past performance |
+
+**Best practice:** Track both
+* ๐ฎ Leading โ Prevent problems
+* ๐ Lagging โ Validate improvements
+
+
+๐ญ Warning: Goodhart's Law in Security
+
+**Goodhart's Law:** "When a measure becomes a target, it ceases to be a good measure"
+
+**Security examples:**
+
+**Metric:** Number of vulnerabilities fixed per sprint
+* ๐ฏ **Goal:** Increase fixes
+* ๐จ **Gaming:** Team fixes low-severity vulns, ignores critical ones
+* ๐ฅ **Result:** High numbers, low security
+
+**Metric:** Security scan pass rate
+* ๐ฏ **Goal:** Clean scans
+* ๐จ **Gaming:** Disable strict rules, mark issues as false positives
+* ๐ฅ **Result:** Green dashboards, vulnerable code
+
+**Metric:** Training completion rate
+* ๐ฏ **Goal:** 100% completion
+* ๐จ **Gaming:** Click through without learning
+* ๐ฅ **Result:** Certificates issued, no behavior change
+
+**How to avoid:**
+* โ
Use multiple metrics (can't game all)
+* โ
Focus on outcomes, not activities
+* โ
Regular audits of metric quality
+* โ
Combine quantitative + qualitative assessment
+
+**Remember:** Metrics should serve security, not the other way around
+
+
+---
+
+## ๐ Slide 5 โ โฑ๏ธ Time-Based KPIs: MTTD, MTTR, MTTA
+
+* โฐ **Time is money** in security (literally)
+* ๐ฏ **Four critical time-based KPIs:** MTTD, MTTR, MTTA, Dwell Time
+* ๐ **Track trends:** Are we getting faster?
+
+```mermaid
+flowchart LR
+ Incident[๐จ Security Issue
Occurs] -->|MTTD| Detect[๐ Detected]
+ Detect -->|MTTA| Acknowledge[๐ Acknowledged]
+ Acknowledge -->|MTTR| Resolve[โ
Resolved]
+
+ Incident -.->|Dwell Time| Resolve
+
+ style Incident fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Detect fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Acknowledge fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Resolve fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ MTTD (Mean Time to Detect)
+
+* ๐ฏ **Definition:** Average time from issue occurrence โ detection
+* ๐ **Formula:** Sum of detection times / Number of incidents
+* โฐ **Industry benchmark:**
+ * **Best-in-class:** < 1 hour
+ * **Good:** < 24 hours
+ * **Average:** 24-72 hours
+ * **Poor:** > 1 week
+* ๐ **Improvements:**
+ * Continuous scanning (not scheduled)
+ * Real-time alerting (not daily reports)
+ * Automated detection (no manual review)
+ * Better tooling (reduce false negatives)
+
+**Why it matters:**
+* โฐ Faster detection = smaller blast radius
+* ๐ฐ Every hour counts (cost escalates quickly)
+* ๐ฏ Measure effectiveness of monitoring
+
+---
+
+### โก MTTR (Mean Time to Respond/Resolve)
+
+* ๐ฏ **Definition:** Average time from detection โ resolution
+* ๐ **Formula:** Sum of resolution times / Number of incidents
+* โฐ **SLAs by severity:**
+
+| Severity | Target MTTR | Example |
+|----------|-------------|---------|
+| ๐ด **Critical** | < 24 hours | Remote code execution in production |
+| ๐ **High** | < 7 days | SQL injection in API |
+| ๐ก **Medium** | < 30 days | Outdated library with CVE |
+| ๐ข **Low** | < 90 days | Info disclosure, low impact |
+
+* ๐ **Improvements:**
+ * Automated remediation (Dependabot, auto-patching)
+ * Prioritization (fix critical first)
+ * Clear ownership (who fixes what)
+ * Runbooks (standardized procedures)
+
+**Why it matters:**
+* โฐ Faster fixes = lower risk exposure
+* ๐ Measure team responsiveness
+* ๐ฏ SLA compliance
+
+---
+
+### ๐ MTTA (Mean Time to Acknowledge)
+
+* ๐ฏ **Definition:** Average time from detection โ someone starts working on it
+* ๐ **Formula:** Sum of acknowledgment times / Number of incidents
+* โฐ **Target:** < 1 hour for critical issues
+* ๐ **Improvements:**
+ * Clear escalation paths (who's on-call?)
+ * Good alerting (right person, right channel)
+ * Reduce alert fatigue (fewer false positives)
+ * Incident response playbooks
+
+**Why it matters:**
+* โฐ Shows organizational responsiveness
+* ๐ Identifies process bottlenecks (alerts ignored?)
+* ๐จ High MTTA = alerts not working
+
+---
+
+### ๐ต๏ธ Dwell Time (Attacker Dwell Time)
+
+* ๐ฏ **Definition:** Time from initial compromise โ detection
+* โฐ **Industry benchmarks:**
+ * **2024 average:** 16 days (IBM)
+ * **Ransomware:** 5-7 days
+ * **Nation-state:** 200+ days (SolarWinds = 9 months)
+* ๐ฅ **Why critical:**
+ * Longer dwell time = more damage
+ * Attackers establish persistence
+ * Data exfiltration happens slowly
+* ๐ **Improvements:**
+ * Runtime monitoring (detect anomalies)
+ * Deception technology (honeypots)
+ * Behavioral analysis (unusual patterns)
+ * Threat hunting (proactive search)
+
+```mermaid
+flowchart LR
+ Compromise[๐ Initial
Compromise] -.->|Dwell Time| Detection[๐ Detection]
+
+ Compromise -->|Days 1-7| Recon[๐ต๏ธ Reconnaissance]
+ Recon -->|Days 8-14| Lateral[๐ Lateral Movement]
+ Lateral -->|Days 15+| Exfil[๐ค Data Exfiltration]
+
+ Detection -->|Stop| Response[โก Incident Response]
+
+ style Compromise fill:#b71c1c,stroke:#d32f2f,stroke-width:3px,color:#fff
+ style Exfil fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Detection fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Time-Based KPI Dashboard Example
+
+**Tracking over time:**
+
+| Metric | Q1 2024 | Q2 2024 | Target | Trend |
+|--------|---------|---------|--------|-------|
+| **MTTD** | 48 hrs | 24 hrs | < 24 hrs | ๐ Improving |
+| **MTTA** | 2 hrs | 1.5 hrs | < 1 hr | ๐ Improving |
+| **MTTR (Critical)** | 5 days | 3 days | < 2 days | ๐ Improving |
+| **MTTR (High)** | 15 days | 12 days | < 7 days | ๐ Improving |
+| **Dwell Time** | 21 days | 18 days | < 10 days | ๐ Improving |
+
+โ
**All metrics improving** โ Security program maturing
+
+
+๐ญ Discussion: What's more important - MTTD or MTTR?
+
+**It depends on context!**
+
+**MTTD matters more when:**
+* ๐จ Active breaches (every minute counts)
+* ๐โโ๏ธ Fast-moving threats (ransomware, worms)
+* ๐ฐ High-value targets (financial, healthcare)
+* ๐ You have good detection but slow response
+
+**MTTR matters more when:**
+* ๐ Known vulnerability backlog (need to clear it)
+* ๐ง Complex remediation (patches, code changes)
+* ๐ฅ Limited team capacity (can't do everything)
+* โก You detect quickly but fix slowly
+
+**Best answer:** Both matter!
+* ๐ฏ **MTTD** determines how long attacker has undetected
+* ๐ฏ **MTTR** determines how long vulnerability exists after detection
+
+**Optimization strategy:**
+1. First: Improve MTTD (detect threats faster)
+2. Then: Improve MTTR (fix faster)
+3. Continuously: Reduce both
+
+**Real-world priority:**
+* Critical issues: MTTD < 1 hour, MTTR < 24 hours
+* High issues: MTTD < 24 hours, MTTR < 7 days
+
+
+---
+
+## ๐ Slide 6 โ ๐ Program Health KPIs
+
+* ๐ฏ **Beyond time:** Other KPIs that measure security program effectiveness
+* ๐ **Categories:** Coverage, quality, compliance, efficiency
+
+```mermaid
+flowchart LR
+ subgraph "๐ Program Health KPIs"
+ Coverage[๐ Coverage
What % is secured?]
+ Quality[โ
Quality
How good are results?]
+ Compliance[๐ Compliance
Meeting standards?]
+ Efficiency[โก Efficiency
Cost vs value?]
+ end
+
+ Coverage --> Health[๐ฏ Overall
Program Health]
+ Quality --> Health
+ Compliance --> Health
+ Efficiency --> Health
+
+ style Health fill:#e8f5e8,stroke:#388e3c,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ Coverage Metrics
+
+* ๐ฏ **Security test coverage:**
+ * % of codebase scanned by SAST
+ * % of APIs tested by DAST
+ * % of dependencies scanned by SCA
+ * % of infrastructure scanned (IaC)
+* **Target:** > 80% coverage
+* **Blind spots:** Code without security testing = high risk
+
+**Formula:**
+```
+Coverage = (Lines scanned / Total lines) ร 100%
+```
+
+* ๐ **Deployment security gate coverage:**
+ * % of deployments going through security gates
+ * % of services with automated security tests
+* **Target:** 100% of production deployments
+
+---
+
+### โ
Quality Metrics
+
+* ๐ฏ **False positive rate:**
+ * % of alerts that are not real issues
+ * **Formula:** False positives / Total alerts ร 100%
+ * **Target:** < 20% false positive rate
+ * **High FP rate:** Alert fatigue, ignored alerts
+
+* ๐ **Deployment security gate pass rate:**
+ * % of builds passing security gates on first try
+ * **Low pass rate:** Quality issues, rushed code
+ * **High pass rate:** Good security practices
+
+* ๐ **Vulnerability recurrence rate:**
+ * % of fixed vulnerabilities that reappear
+ * **Formula:** Recurring vulns / Total fixed ร 100%
+ * **Target:** < 5% recurrence
+ * **High recurrence:** Root cause not addressed
+
+```mermaid
+flowchart LR
+ Total[๐ 1000 Alerts] --> FP[โ 300 False Positives]
+ Total --> TP[โ
700 True Positives]
+
+ FP -.->|30% FP Rate| Problem[๐จ Alert Fatigue]
+ TP -.->|70% TP Rate| Good[โ
Actionable Alerts]
+
+ style FP fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Problem fill:#ffcdd2,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style TP fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Compliance Metrics
+
+* ๐ฏ **Policy compliance rate:**
+ * % of deployments meeting security policies
+ * **Target:** > 95% compliance
+ * **Violations:** Track what policies are violated most
+
+* โฐ **Remediation SLA compliance:**
+ * % of vulnerabilities fixed within SLA
+ * **By severity:** Track separately (critical vs low)
+ * **Target:** 90% for critical, 80% for high
+
+* ๐ **Audit findings:**
+ * Number of findings in compliance audits
+ * **Trend:** Should decrease over time
+ * **Severity:** Critical findings should be zero
+
+**Example tracking:**
+
+| Policy | Compliance Rate | Violations This Month |
+|--------|----------------|-----------------------|
+| No secrets in code | 98% | 12 |
+| Container images signed | 95% | 34 |
+| SBOM generated | 100% | 0 |
+| Critical vulns < 24hr | 85% | 8 |
+
+---
+
+### โก Efficiency Metrics
+
+* ๐ฐ **Cost per vulnerability found:**
+ * Security tool costs / Vulnerabilities found
+ * **Lower is better** (but don't compromise coverage)
+
+* ๐ฅ **Security team velocity:**
+ * Vulnerabilities triaged per week
+ * Vulnerabilities fixed per week
+ * **Trend matters:** Improving or stagnating?
+
+* ๐ค **Automation rate:**
+ * % of security tasks automated
+ * **Target:** > 70% automated
+ * **Manual work:** Should be for high-value activities
+
+* ๐ **Mean time between failures (MTBF):**
+ * Average time between security incidents
+ * **Higher is better** (fewer incidents)
+
+---
+
+### ๐ฏ Vulnerability-Specific Metrics
+
+**Covered in Lecture 10, but related:**
+
+* ๐ **Vulnerability backlog:**
+ * Total open vulnerabilities (trend)
+ * By severity (critical, high, medium, low)
+ * **Growing backlog:** Problem
+
+* โฐ **Vulnerability age:**
+ * Average age of open vulnerabilities
+ * **Critical vulns:** Should be < 7 days old
+ * **Old vulns:** Technical debt
+
+* ๐ **Vulnerability introduction rate:**
+ * New vulnerabilities found per sprint/release
+ * **High rate:** Quality issues
+ * **Trend:** Should stabilize or decrease
+
+* ๐ **Vulnerability fix rate:**
+ * Vulnerabilities fixed per sprint/release
+ * **Should exceed introduction rate**
+
+```mermaid
+flowchart LR
+ Intro[โ Introduction Rate
100 vulns/month] --> Backlog{๐ Backlog}
+ Fix[โ Fix Rate
80 vulns/month] --> Backlog
+
+ Backlog -->|Growing| Problem[๐จ +20 vulns/month
Backlog growing]
+
+ Improve[โก Improve Fix Rate
120 vulns/month] --> Backlog2{๐ Backlog}
+ Intro --> Backlog2
+ Backlog2 -->|Shrinking| Good[โ
-20 vulns/month
Improving]
+
+ style Problem fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Good fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+
+๐ญ Pro Tip: Balance quantity and quality metrics
+
+**Common mistake:** Focus only on quantity
+* โ "We fixed 500 vulnerabilities this quarter!"
+* โ But were they the right ones? Were they actually fixed? Did new ones appear?
+
+**Better approach:** Combine metrics
+* โ
Fixed 500 vulnerabilities (quantity)
+* โ
90% were High/Critical (quality)
+* โ
Recurrence rate < 5% (sustainability)
+* โ
Backlog decreased 20% (progress)
+
+**Dashboard structure:**
+
+**Quantity metrics:**
+* Total vulnerabilities found/fixed
+* Scan coverage
+* Tests run
+
+**Quality metrics:**
+* False positive rate
+* Recurrence rate
+* SLA compliance
+
+**Impact metrics:**
+* MTTR by severity
+* Backlog trend
+* Risk score trend
+
+**All three together = complete picture**
+
+
+---
+
+## ๐ Slide 7 โ ๐ป Hands-On: Building Security Dashboards
+
+* ๐ฏ **Goal:** Turn metrics into visual insights
+* ๐ **Audience matters:** Different dashboards for different roles
+* ๐ ๏ธ **Tools:** Grafana, Kibana, Datadog (covered in Slide 3)
+
+```mermaid
+flowchart LR
+ Data[๐๏ธ Security Data
Scanners, CI/CD, SIEM] --> Dashboards{๐ Dashboards}
+
+ Dashboards --> Executive[๐ Executive
High-level, risk]
+ Dashboards --> Manager[๐จโ๐ผ Manager
Team metrics, SLAs]
+ Dashboards --> Engineer[๐จโ๐ป Engineer
Actionable details]
+
+ style Data fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Dashboards fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ Executive Dashboard
+
+**Purpose:** At-a-glance security posture
+
+**Key elements:**
+* ๐ฏ **Risk score trend** (improving or degrading?)
+* ๐ **Critical vulnerability count** (must be near zero)
+* โฐ **MTTR for critical issues** (meeting SLAs?)
+* ๐ **Compliance status** (red/yellow/green)
+* ๐ฐ **Security incidents this quarter** (count and cost)
+* ๐ **Trend lines** (quarter-over-quarter comparison)
+
+**Design principles:**
+* ๐ฆ Red/Yellow/Green indicators (traffic light)
+* ๐ Simple trend lines (up/down arrows)
+* ๐ข Big numbers (easy to read from distance)
+* โฑ๏ธ Updated daily (no stale data)
+
+**Avoid:**
+* โ Too many metrics (< 8 KPIs)
+* โ Technical jargon (use business language)
+* โ Detailed vulnerability lists
+
+---
+
+### ๐จโ๐ผ Manager Dashboard
+
+**Purpose:** Team performance and SLA tracking
+
+**Key elements:**
+* โฐ **Time-based KPIs:** MTTD, MTTR, MTTA by team
+* ๐ **Backlog by severity:** Trend over time
+* ๐ **SLA compliance:** % meeting targets
+* ๐ฅ **Team velocity:** Vulns fixed per sprint
+* ๐ **Deployment gate metrics:** Pass/fail rates
+* ๐จ **Alert volume:** Are alerts actionable?
+
+**Design principles:**
+* ๐
Weekly/monthly views (operational timeframe)
+* ๐ Comparison charts (team vs team, sprint vs sprint)
+* ๐ฏ Threshold indicators (SLA targets marked)
+* ๐ Drill-down capability (click for details)
+
+---
+
+### ๐จโ๐ป Engineer Dashboard
+
+**Purpose:** Actionable vulnerability details
+
+**Key elements:**
+* ๐จ **My assigned vulnerabilities:** Sorted by severity
+* โฐ **Age indicators:** How old is each issue?
+* ๐ **Source:** Which scanner found it?
+* ๐ง **Remediation guidance:** How to fix
+* ๐ **Trend for my services:** Getting better or worse?
+* ๐ **Recent scans:** Latest results
+
+**Design principles:**
+* โ
Actionable (click to open ticket/PR)
+* ๐ฏ Filtered view (only relevant to me)
+* ๐ Real-time updates (no refresh needed)
+* ๐ฑ Mobile-friendly (view on the go)
+
+**Avoid:**
+* โ Aggregated metrics (too high-level)
+* โ Historical data (focus on current)
+
+---
+
+### ๐จ Dashboard Design Best Practices
+
+**Layout:**
+* ๐ **F-pattern:** Most important top-left
+* ๐ฏ **Grouping:** Related metrics together
+* ๐ **Color coding:** Consistent (red = bad, green = good)
+* โก **Performance:** Load in < 2 seconds
+
+**Visualization types:**
+
+| Metric Type | Best Visualization |
+|-------------|-------------------|
+| **Single value** | Gauge, big number |
+| **Trend over time** | Line chart, area chart |
+| **Comparison** | Bar chart, column chart |
+| **Distribution** | Histogram, pie chart |
+| **Status** | Table, heatmap |
+
+**Refresh rates:**
+* ๐ด **Critical dashboards:** Real-time (< 1 min)
+* ๐ก **Operational:** Every 5-15 minutes
+* ๐ข **Strategic:** Daily
+
+---
+
+### ๐ ๏ธ Data Sources for Dashboards
+
+**Common integrations:**
+
+* ๐ **Vulnerability scanners:**
+ * Snyk, Trivy, Grype (via API)
+ * DefectDojo (centralized)
+
+* ๐ **CI/CD systems:**
+ * GitHub Actions (workflow runs)
+ * GitLab CI (pipeline status)
+ * Jenkins (build metrics)
+
+* โ๏ธ **Cloud providers:**
+ * AWS Security Hub
+ * Azure Defender
+ * GCP Security Command Center
+
+* ๐ **SIEM platforms:**
+ * Splunk, ELK (query APIs)
+
+* ๐ **Issue trackers:**
+ * Jira, GitHub Issues (vulnerability tickets)
+
+**Data collection methods:**
+* ๐ **Direct API:** Query tools directly
+* ๐ค **Push model:** Tools send data to dashboard
+* ๐๏ธ **Data warehouse:** Centralized metrics database (recommended)
+
+---
+
+### ๐ Example Grafana Setup
+
+**Architecture:**
+
+```mermaid
+flowchart LR
+ Scanners[๐ Security Scanners] -->|Metrics| Prometheus[๐ Prometheus]
+ CICD[๐ CI/CD] -->|Logs| Loki[๐ Loki]
+ SIEM[๐ก๏ธ SIEM] -->|Alerts| Prometheus
+
+ Prometheus --> Grafana[๐ Grafana]
+ Loki --> Grafana
+
+ Grafana --> Dashboard1[๐ Executive]
+ Grafana --> Dashboard2[๐จโ๐ผ Manager]
+ Grafana --> Dashboard3[๐จโ๐ป Engineer]
+
+ style Grafana fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+```
+
+**Prometheus exporters:**
+* ๐ Custom exporters for security tools
+* ๐ Metrics: vulnerability counts, scan durations, MTTR
+* โฐ Scrape interval: 30-60 seconds
+
+**Grafana panels:**
+* ๐ Time-series (MTTR trend)
+* ๐ Bar gauge (vulnerability counts by severity)
+* ๐ฏ Stat panel (big numbers with thresholds)
+* ๐ Table (vulnerability list)
+
+---
+
+### ๐ Implementation Roadmap
+
+**Week 1: Foundation**
+* โ
Define key metrics (5-10 KPIs)
+* โ
Identify data sources
+* โ
Set up Grafana/Kibana
+
+**Week 2: Data Collection**
+* โ
Connect data sources
+* โ
Create Prometheus exporters (if needed)
+* โ
Validate data accuracy
+
+**Week 3: Dashboard Development**
+* โ
Build executive dashboard
+* โ
Build manager dashboard
+* โ
Build engineer dashboard
+
+**Week 4: Rollout**
+* โ
Share dashboards with teams
+* โ
Gather feedback
+* โ
Iterate and improve
+
+**Ongoing:**
+* ๐ Weekly review of metrics
+* ๐ Monthly dashboard tuning
+* ๐ฏ Quarterly metric review (add/remove KPIs)
+
+
+๐ญ Common Mistakes to Avoid
+
+**1. Too many metrics (dashboard clutter)**
+* โ 50 metrics on one dashboard
+* โ
5-8 key metrics per dashboard
+
+**2. No context (numbers without meaning)**
+* โ "45 vulnerabilities"
+* โ
"45 vulnerabilities (down from 60 last week)"
+
+**3. Stale data (nobody trusts it)**
+* โ Updated weekly
+* โ
Updated hourly/daily
+
+**4. One dashboard for everyone**
+* โ Same view for CEO and engineer
+* โ
Different dashboards for different roles
+
+**5. No actionability (pretty but useless)**
+* โ Can only view metrics
+* โ
Click to drill down, create tickets, investigate
+
+**6. Ignoring mobile (everyone has phones)**
+* โ Only works on desktop
+* โ
Responsive design
+
+**7. No alerting (passive monitoring)**
+* โ Must check dashboard manually
+* โ
Alerts sent to Slack/email when thresholds crossed
+
+**Remember:** Dashboard is a tool, not a goal. Focus on driving decisions, not pretty charts.
+
+
+---
+
+## ๐ Fun Break: "When Metrics Go Wrong"
+
+### ๐ Goodhart's Law: The Cobra Effect
+
+**The Original "Cobra Effect" (Delhi, British India):**
+* ๐ Problem: Too many cobras in Delhi
+* ๐ก Solution: Government pays bounty for dead cobras
+* ๐ฏ Result: People start breeding cobras to kill for bounty
+* ๐ฅ Outcome: More cobras than before!
+
+**Security Metrics Edition:**
+
+**Metric:** "Number of vulnerabilities fixed per month"
+* ๐ฏ **Target:** Increase fixes to 500/month
+* ๐ **Result:** Team fixes hundreds of "info" severity issues, ignores critical ones
+* ๐ฅ **Outcome:** Dashboard looks green, critical vulns unfixed for months
+
+**Metric:** "100% test coverage"
+* ๐ฏ **Target:** All code must have tests
+* ๐ **Result:** Developers write meaningless tests that always pass
+* ๐ฅ **Outcome:** 100% coverage, 0% actual security validation
+
+**Metric:** "Zero security gate failures"
+* ๐ฏ **Target:** All builds pass security gates
+* ๐ **Result:** Teams lower security gate thresholds or disable checks
+* ๐ฅ **Outcome:** Green pipelines, vulnerable code in production
+
+**Metric:** "Reduce security incidents to zero"
+* ๐ฏ **Target:** No incidents reported
+* ๐ **Result:** Teams stop reporting incidents (bad for career)
+* ๐ฅ **Outcome:** Zero reported incidents, many unreported breaches
+
+```mermaid
+flowchart LR
+ Metric[๐ Metric Becomes
Performance Target] --> Gaming[๐ฎ Gaming Begins]
+ Gaming --> Manipulate[๐ญ Manipulate Numbers
Not Behavior]
+ Manipulate --> Useless[โ Metric Becomes
Useless]
+
+ style Metric fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Gaming fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Useless fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ก๏ธ How to Prevent Gaming
+
+**1. Use multiple metrics (can't game them all)**
+* โ
Vulnerabilities fixed + MTTR + recurrence rate
+* โ Just count of vulnerabilities fixed
+
+**2. Focus on outcomes, not activities**
+* โ
Reduction in production incidents
+* โ Number of security scans run
+
+**3. Measure what you can't easily manipulate**
+* โ
Customer-reported security issues
+* โ Self-reported compliance scores
+
+**4. Regular audits**
+* โ
Sample vulnerabilities to verify fixes are real
+* โ
Review code to verify tests are meaningful
+
+**5. Qualitative + quantitative**
+* โ
Metrics + peer reviews + incident retrospectives
+* โ Metrics alone
+
+**6. Transparent goals**
+* โ
"Improve security posture" (outcome)
+* โ "Hit these exact numbers" (output)
+
+---
+
+### ๐ก Real-World Gaming Examples
+
+**Case 1: The "False Positive" Epidemic**
+* ๐ฏ Metric: Reduce open vulnerability count
+* ๐ฎ Gaming: Mark everything as "false positive" or "won't fix"
+* ๐ Dashboard: 95% vulnerabilities resolved!
+* ๐ฅ Reality: Nothing actually fixed, just hidden
+
+**Case 2: The Test Coverage Illusion**
+* ๐ฏ Metric: 80% code coverage required
+* ๐ฎ Gaming: Write tests that call functions but assert nothing
+* ๐ Dashboard: 85% coverage achieved!
+* ๐ฅ Reality: Tests pass even with vulnerabilities
+
+**Case 3: The Quick Fix Trap**
+* ๐ฏ Metric: MTTR < 24 hours for critical
+* ๐ฎ Gaming: Mark critical as "mitigated" (not actually fixed), downgrade severity
+* ๐ Dashboard: 100% SLA compliance!
+* ๐ฅ Reality: Critical vulnerabilities still exploitable
+
+**Lessons:**
+* ๐ฏ Metrics should help, not hurt
+* ๐๏ธ Trust but verify
+* ๐ Continuously refine metrics
+* ๐ง Use judgment, not just dashboards
+
+---
+
+### ๐ค The Right Way to Use Metrics
+
+**Metrics are:**
+* โ
Conversation starters (not conversation enders)
+* โ
Indicators (not absolute truth)
+* โ
Tools for improvement (not punishment)
+
+**Metrics are NOT:**
+* โ Performance review scores
+* โ Targets to hit at all costs
+* โ Replacement for judgment
+
+**Golden rule:** "If a metric becomes a target, prepare to change the metric"
+
+---
+
+๐ **Resources for Group 2:**
+* [SANS Security Metrics Guide](https://www.sans.org/white-papers/55/)
+* [OWASP Security Metrics](https://owasp.org/www-community/Security_Metrics)
+* [Google SRE Book - Monitoring](https://sre.google/sre-book/monitoring-distributed-systems/)
+* [Grafana Dashboards](https://grafana.com/grafana/dashboards/)
+* [IBM Cost of Data Breach Report](https://www.ibm.com/security/data-breach)
+* [Goodhart's Law Explained](https://en.wikipedia.org/wiki/Goodhart%27s_law)
+
+---
+## ๐ Group 3: Compliance Frameworks
+
+## ๐ Slide 8 โ โ๏ธ Compliance Basics for Developers
+
+* โ๏ธ **Compliance** = meeting legal/regulatory requirements
+* ๐ฐ **Non-compliance cost:** Fines (โฌ20M+), lawsuits, lost business
+* ๐ **Key insight:** Compliance โ security (overlap ~70%)
+* ๐ฏ **Compliance:** Minimum baseline (point-in-time audits)
+* ๐ก๏ธ **Security:** Continuous improvement (real-time protection)
+
+```mermaid
+flowchart LR
+ Security[๐ก๏ธ Security] --> Overlap[๐ฏ 70% Overlap]
+ Compliance[โ๏ธ Compliance] --> Overlap
+
+ Overlap --> Common[Encryption
Access control
Vulnerability mgmt]
+
+ style Overlap fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+```
+
+**Developer responsibilities:**
+* ๐ Encrypt sensitive data (at rest, in transit)
+* ๐ Access control (authentication, authorization)
+* ๐ Audit logs (who accessed what)
+* ๐๏ธ Data deletion (GDPR "right to be forgotten")
+* ๐จ Breach notification (within 72 hours)
+
+---
+
+## ๐ Slide 9 โ ๐ช๐บ GDPR Essentials
+
+* ๐ช๐บ **GDPR:** EU data privacy regulation (applies globally if you have EU users)
+* ๐ฐ **Penalty:** โฌ20M or 4% revenue (whichever higher)
+* ๐
**Effective:** May 2018
+
+**Key principles:**
+* ๐ Data minimization (collect only what's needed)
+* ๐ Privacy by design (build privacy in from start)
+* โฐ Storage limitation (don't keep forever)
+* โ
User consent (explicit opt-in)
+
+**User rights (must implement):**
+* ๐ฅ Right to access (export my data)
+* โ๏ธ Right to rectification (correct my data)
+* ๐๏ธ Right to erasure (delete my data)
+* ๐ค Right to portability (transfer my data)
+
+**Technical requirements:**
+* ๐ Encryption mandatory (at rest, in transit)
+* ๐ Audit logs (track all access)
+* ๐จ Breach notification within 72 hours
+* ๐ [GDPR Official](https://gdpr.eu/)
+
+---
+
+## ๐ Slide 10 โ ๐๏ธ NIST Cybersecurity Framework
+
+* ๐๏ธ **NIST CSF:** US risk management framework (voluntary but widely adopted)
+* ๐ฏ **5 Functions:** Identify โ Protect โ Detect โ Respond โ Recover
+
+```mermaid
+flowchart LR
+ Identify[๐ Identify
Assets & Risks] --> Protect[๐ก๏ธ Protect
Safeguards]
+ Protect --> Detect[๐๏ธ Detect
Monitoring]
+ Detect --> Respond[โก Respond
Incidents]
+ Respond --> Recover[๐ Recover
Restore]
+
+ style Identify fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Protect fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Detect fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+ style Respond fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Recover fill:#e1f5fe,stroke:#0288d1,stroke-width:2px,color:#2c3e50
+```
+
+**DevSecOps mapping:**
+* ๐ Identify: SBOM, threat modeling, asset inventory
+* ๐ก๏ธ Protect: SAST/DAST, IaC security, secrets management
+* ๐๏ธ Detect: Vulnerability scanning, SIEM, monitoring
+* โก Respond: Incident response, automated rollback
+* ๐ Recover: Backup/restore, disaster recovery
+
+* ๐ [NIST CSF](https://www.nist.gov/cyberframework)
+
+---
+
+## ๐ Slide 11 โ ๐ ISO 27001 Basics
+
+* ๐ **ISO 27001:** International standard for ISMS (Information Security Management System)
+* ๐ **Certification-based:** Requires external audit
+* ๐ **Structure:** PDCA cycle (Plan-Do-Check-Act) + 93 security controls
+
+**Annex A domains (14 categories):**
+* Access control, cryptography, operations security
+* Secure development, supplier relationships, incident management
+
+**Certification timeline:**
+* โฐ Preparation: 6-12 months
+* ๐ฐ Cost: $15K-$50K
+* ๐ Renewal: Every 3 years
+
+**Why organizations pursue:**
+* ๐ค Customer trust (global recognition)
+* ๐ผ Required for some contracts
+* ๐ Accepted worldwide
+
+* ๐ [ISO 27001](https://www.iso.org/isoiec-27001-information-security.html)
+
+---
+
+## ๐ Slide 12 โ ๐ณ Other Key Frameworks (Quick Overview)
+
+| Framework | Scope | Geography | Key Requirement |
+|-----------|-------|-----------|-----------------|
+| ๐ณ **PCI-DSS** | Payment cards | Global | Protect cardholder data, quarterly scans |
+| ๐ **SOC 2** | SaaS/Cloud | US | Trust Service Criteria (Security + optional) |
+| ๐ฅ **HIPAA** | Healthcare | US | Protect PHI, encryption, audit logs |
+| ๐๏ธ **FedRAMP** | Federal cloud | US Gov | NIST 800-53 controls (12-18 months) |
+
+**Quick decision guide:**
+* Accept credit cards โ **PCI-DSS** (required)
+* SaaS company, US customers โ **SOC 2**
+* Healthcare data โ **HIPAA** (required)
+* International sales โ **ISO 27001**
+* US government โ **FedRAMP**
+
+---
+
+## ๐ Fun Break: "The $746M Mistake"
+
+**Amazon's Record GDPR Fine (2021):**
+* ๐ฏ Violation: Targeted advertising without proper consent
+* ๐ฐ Fine: โฌ746M (largest ever)
+* ๐ค Amazon: "We disagree" (still under appeal)
+
+**Meta's $1.2B Fine (2023):**
+* ๐ฏ Violation: EU-US data transfers without safeguards
+* ๐ฑ Response: Threatened to leave Europe
+
+**Lessons:**
+* โ
Cookie consent must be real (reject as easy as accept)
+* โ
Data deletion must be permanent (not soft delete)
+* โ
Privacy policy must be clear (not legalese)
+* โ Don't ignore regulators
+
+**Developer reality:**
+* Before GDPR: `DELETE FROM users`
+* After GDPR: 500 lines of cascade deletion code
+
+---
+
+๐ **Resources for Group 3:**
+* [GDPR Official](https://gdpr.eu/)
+* [NIST CSF](https://www.nist.gov/cyberframework)
+* [ISO 27001](https://www.iso.org/isoiec-27001-information-security.html)
+* [PCI-DSS](https://www.pcisecuritystandards.org/)
+* [SOC 2](https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/sorhome)
+
+---
+## ๐ Group 3: Compliance Frameworks
+
+## ๐ Slide 8 โ โ๏ธ Compliance Basics for Developers
+
+* โ๏ธ **Compliance** = meeting legal, regulatory, and industry standards
+* ๐ฏ **Why it matters:** Fines, lawsuits, lost business, reputation damage
+* ๐ **Key insight:** Compliance โ security (but ~70% overlap)
+
+```mermaid
+flowchart LR
+ Security[๐ก๏ธ Security
Protect against threats] --> Overlap[๐ฏ Overlap 70%]
+ Compliance[โ๏ธ Compliance
Meet regulations] --> Overlap
+
+ Security --> Only1[๐ Zero-days
APT protection]
+ Compliance --> Only2[๐ Audit logs
Process docs]
+
+ Overlap --> Both[Encryption
Access control
Vulnerability mgmt]
+
+ style Overlap fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ฐ The Cost of Non-Compliance
+
+**Major penalties:**
+* ๐ช๐บ **GDPR:** โฌ20M or 4% revenue (Amazon: โฌ746M fine)
+* ๐ณ **PCI-DSS:** $500K/month
+* ๐ฅ **HIPAA:** $1.5M/year (Anthem: $16M settlement)
+
+**Beyond fines:**
+* ๐ Stock price drop (avg 7.5% after breach)
+* ๐ค Customer churn (31% switch providers)
+* ๐ผ Executive liability
+
+---
+
+### ๐ฏ Compliance vs Security Differences
+
+| Aspect | Compliance | Security |
+|--------|-----------|----------|
+| **Goal** | Meet minimum standards | Protect against threats |
+| **Timing** | Point-in-time (audits) | Continuous (real-time) |
+| **Approach** | Checkbox (yes/no) | Risk-based (prioritize) |
+| **Verification** | External auditors | Internal testing |
+| **Focus** | Process + documentation | Technical controls |
+
+**Warning:** You can be compliant but insecure!
+* โ
Pass all compliance checks
+* ๐จ Still get breached (if only doing minimum)
+
+---
+
+### ๐จโ๐ป Developer Responsibilities
+
+**What you must implement:**
+
+* ๐ **Data protection:**
+ * Encrypt sensitive data (at rest + in transit)
+ * Use TLS 1.2+, AES-256
+
+* ๐ **Access control:**
+ * Authentication (MFA for sensitive access)
+ * Authorization (RBAC, least privilege)
+ * Session management
+
+* ๐ **Audit logging:**
+ * Log security events (who, what, when)
+ * Tamper-proof logs (immutable)
+ * Retention (7+ years for some regulations)
+
+* ๐๏ธ **Data lifecycle:**
+ * Retention policies (keep for required time)
+ * Secure deletion (GDPR "right to be forgotten")
+ * Data minimization (collect only necessary)
+
+* ๐จ **Breach response:**
+ * Detection mechanisms
+ * Notification workflows (72-hour deadline)
+ * Incident documentation
+
+---
+
+### ๐ค Compliance Automation in DevSecOps
+
+**Shift-left compliance:**
+* ๐ Pre-commit: Secret scanning, license checks
+* ๐ CI/CD: Policy enforcement (OPA, Sentinel)
+* ๐ Runtime: Continuous compliance monitoring
+
+**Benefits:**
+* โฐ Catch issues early (dev vs production)
+* ๐ฐ Reduce audit costs (automated evidence)
+* ๐ Continuous compliance (not annual)
+
+* ๐ **Resources:** [GDPR Developer Guide](https://www.smashingmagazine.com/2017/07/privacy-by-design-framework/)
+
+
+๐ญ Common Question: "Do startups need compliance?"
+
+**YES, if you:**
+* ๐ Have EU users โ GDPR (regardless of company location)
+* ๐ณ Accept credit cards โ PCI-DSS
+* ๐ฅ Handle health data โ HIPAA
+* ๐ข Sell to enterprises โ SOC 2 often required
+
+**Strategy:**
+1. **Now:** Security best practices (encryption, access control)
+2. **When customers ask:** Formal compliance programs
+3. **For sales:** Certifications (ISO 27001, SOC 2)
+
+**Build compliance in from day 1** (cheaper than retrofitting)
+
+
+---
+
+## ๐ Slide 9 โ ๐ช๐บ GDPR (General Data Protection Regulation)
+
+* ๐ช๐บ **GDPR:** EU regulation protecting citizen data privacy
+* ๐
**Effective:** May 25, 2018
+* ๐ **Applies to:** ANY company processing EU residents' data (global reach)
+* ๐ฐ **Penalty:** โฌ20M or 4% global revenue (whichever higher)
+* ๐ฏ **Core principle:** Privacy by design and by default
+* ๐ **Learn more:** [GDPR Official](https://gdpr.eu/)
+
+```mermaid
+flowchart LR
+ User[๐ค EU Resident] -->|Personal data| Company[๐ข Your Company
Anywhere in world]
+ Company -->|Must comply| GDPR[๐ช๐บ GDPR Requirements]
+
+ GDPR --> Rights[โ
User Rights]
+ GDPR --> Protection[๐ Data Protection]
+ GDPR --> Breach[๐จ 72h Notification]
+
+ Violation[โ Violation] -->|โฌ20M or 4%| Fine[๐ฐ Penalties]
+
+ style GDPR fill:#fff3e0,stroke:#f57c00,stroke-width:3px,color:#2c3e50
+ style Fine fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ GDPR Key Principles
+
+* ๐ฏ **Lawfulness & transparency:** Clear privacy policy, no hidden collection
+* ๐ฏ **Purpose limitation:** Use data only for stated purposes
+* ๐ฏ **Data minimization:** Collect only what's necessary
+* ๐ฏ **Accuracy:** Keep data up-to-date, allow corrections
+* ๐ฏ **Storage limitation:** Delete after retention period
+* ๐ฏ **Integrity & confidentiality:** Security measures mandatory
+
+---
+
+### ๐ค User Rights (Must Implement)
+
+**Technical implementations required:**
+
+* โ
**Right to access:** Export user data (JSON/CSV format)
+* โ
**Right to rectification:** Edit profile/data functionality
+* โ
**Right to erasure:** Delete account + all data permanently
+* โ
**Right to portability:** Transfer data to competitor
+* โ
**Right to object:** Opt-out of processing (e.g., marketing)
+
+**Response time:** 30 days maximum
+
+```mermaid
+flowchart LR
+ User[๐ค User Request] --> Actions{๐ Required Actions}
+
+ Actions --> Export[๐ค Export Data]
+ Actions --> Correct[โ๏ธ Correct Data]
+ Actions --> Delete[๐๏ธ Delete Data]
+
+ Delete --> Cascade[๐ Cascade Delete
All tables]
+ Delete --> Backups[๐พ Remove from
Backups]
+ Delete --> Logs[๐ Anonymize
Audit logs]
+
+ style Actions fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Delete fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Technical Requirements for Developers
+
+**1. Encryption (mandatory):**
+* At rest: AES-256 for databases/files
+* In transit: TLS 1.2+ for all connections
+* Pseudonymization where possible
+
+**2. Access control:**
+* RBAC with least privilege
+* MFA for admin access
+* Audit all PII access
+
+**3. Consent management:**
+* Explicit opt-in (no pre-checked boxes)
+* Granular consent (separate for each purpose)
+* Easy withdrawal mechanism
+* Log consent timestamps
+
+**4. Breach notification:**
+* Detect breaches (monitoring + alerts)
+* Notify DPA within 72 hours
+* Notify users if high risk
+* Document: what, when, impact, response
+
+---
+
+### โฐ GDPR Breach Timeline
+
+```mermaid
+flowchart LR
+ Breach[๐ฅ Breach] -->|0-24h| Assess[๐ Assess
Impact]
+ Assess -->|24-48h| Contain[๐ Contain]
+ Contain -->|48-72h| Notify[๐ข Notify DPA]
+
+ Assess -->|If high risk| Users[๐ฅ Notify Users
Immediately]
+
+ Notify -->|Late?| Fine[๐ฐ Penalty]
+
+ style Breach fill:#ffebee,stroke:#d32f2f,stroke-width:3px,color:#2c3e50
+ style Notify fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### โ
GDPR Implementation Checklist
+
+**Development:**
+* โ Encrypt all PII (at rest + transit)
+* โ Implement user data export (machine-readable)
+* โ Implement permanent deletion (cascade all tables)
+* โ Consent management (opt-in/opt-out)
+* โ Access controls (RBAC + MFA)
+* โ Audit logging (track PII access)
+
+**Operations:**
+* โ Privacy policy published (plain language)
+* โ Cookie consent (if applicable)
+* โ Breach detection monitoring
+* โ Incident response plan
+* โ Data retention policy (auto-delete)
+
+
+๐ญ GDPR Myth: "Small companies are exempt"
+
+**FALSE:** GDPR applies to ALL companies with EU users
+
+**Reality:**
+* โ
Penalties may be lower for SMBs
+* โ
But compliance is still required
+* โ
DPAs consider: size, intent, cooperation
+
+**Example:**
+* Small company ($1M revenue): โฌ40K fine (4% of revenue)
+* Big Tech ($100B revenue): โฌ20M fine (capped)
+
+**Pro tip:** Build privacy in early, cheaper than retrofitting
+
+
+---
+
+## ๐ Slide 10 โ ๐๏ธ NIST Cybersecurity Framework
+
+* ๐๏ธ **NIST CSF:** US framework for managing cybersecurity risk
+* ๐
**Created:** 2014 (updated 2018, 2.0 in 2024)
+* ๐ฏ **Voluntary** but widely adopted (especially US gov contractors)
+* ๐ **Focus:** Risk management, not compliance checklist
+* ๐ **Learn more:** [NIST CSF](https://www.nist.gov/cyberframework)
+
+```mermaid
+flowchart LR
+ NIST[๐๏ธ NIST CSF] --> F1[๐ Identify]
+ NIST --> F2[๐ก๏ธ Protect]
+ NIST --> F3[๐๏ธ Detect]
+ NIST --> F4[โก Respond]
+ NIST --> F5[๐ Recover]
+
+ style NIST fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ Five Functions
+
+**๐ Identify:** Understand assets, risks, priorities
+* Asset management (inventory systems, data)
+* Risk assessment (threats, vulnerabilities)
+* Supply chain (third-party risks)
+
+**๐ก๏ธ Protect:** Implement safeguards
+* Access control (authentication, authorization)
+* Data security (encryption, DLP)
+* Secure SDLC (SAST/DAST)
+
+**๐๏ธ Detect:** Find security events quickly
+* Continuous monitoring (security events)
+* Anomaly detection (baseline deviations)
+
+**โก Respond:** Take action on incidents
+* Response planning (IR procedures)
+* Mitigation (contain, eliminate)
+* Post-incident analysis (lessons learned)
+
+**๐ Recover:** Restore services
+* Recovery planning (restore operations)
+* Improvements (update plans)
+
+---
+
+### ๐บ๏ธ DevSecOps Mapping to NIST
+
+```mermaid
+flowchart LR
+ subgraph DevSecOps
+ SBOM[๐ SBOM]
+ SAST[๐ SAST/DAST]
+ Scan[๐ Vuln Scanning]
+ IR[๐จ Incident Response]
+ DR[๐ DR Testing]
+ end
+
+ SBOM --> Identify[๐ Identify]
+ SAST --> Protect[๐ก๏ธ Protect]
+ Scan --> Detect[๐๏ธ Detect]
+ IR --> Respond[โก Respond]
+ DR --> Recover[๐ Recover]
+
+ style DevSecOps fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+**Practical examples:**
+* **Identify:** SBOM generation, asset inventory
+* **Protect:** IaC security scanning, secret management
+* **Detect:** SIEM integration, continuous scanning
+* **Respond:** Automated rollback, blameless post-mortems
+* **Recover:** Backup/restore testing, DR drills
+
+---
+
+### ๐ฏ Implementation Tiers
+
+| Tier | Name | Characteristics |
+|------|------|-----------------|
+| **Tier 1** | Partial | Ad-hoc, reactive, no formal processes |
+| **Tier 2** | Risk Informed | Policies exist, inconsistent implementation |
+| **Tier 3** | Repeatable | Formal policies, regular updates |
+| **Tier 4** | Adaptive | Continuous improvement, predictive |
+
+**Most organizations:** Tier 2-3 (Tier 4 is rare)
+
+
+๐ญ NIST CSF vs NIST SSDF
+
+**NIST CSF (Cybersecurity Framework):**
+* ๐ฏ Scope: Entire organization
+* ๐ Audience: Executives, CISOs
+* ๐ Structure: 5 functions
+
+**NIST SSDF (Secure Software Development):**
+* ๐ฏ Scope: Software development only
+* ๐จโ๐ป Audience: Developers, DevOps
+* ๐ Structure: 4 practice groups
+* ๐ Covered in: Lab 8 (supply chain)
+
+**Use both:** CSF for strategy, SSDF for tactics
+
+
+---
+
+## ๐ Slide 11 โ ๐ ISO 27001 Information Security Management
+
+* ๐ **ISO 27001:** International standard for ISMS
+* ๐ **Certification-based:** Requires external audit
+* ๐ฏ **Focus:** Process-driven security management
+* ๐ **Recognition:** Global (accepted worldwide)
+* ๐ **Learn more:** [ISO 27001](https://www.iso.org/isoiec-27001-information-security.html)
+
+```mermaid
+flowchart LR
+ Plan[๐ Plan
Risk assessment] --> Do[โ๏ธ Do
Implement]
+ Do --> Check[๐ Check
Audit]
+ Check --> Act[โก Act
Improve]
+ Act --> Plan
+
+ style Plan fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Do fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Check fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Act fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Structure
+
+**Requirements (Clauses 4-10):**
+* Context and leadership
+* Risk assessment and treatment
+* Implementation and operation
+* Performance evaluation
+* Continual improvement
+
+**Annex A: 93 Security Controls**
+* 14 domains (choose based on risk assessment)
+* Examples: Access control, cryptography, operations security, secure development
+
+---
+
+### ๐ Key Domains for Developers
+
+| Domain | Controls | DevSecOps Examples |
+|--------|----------|-------------------|
+| **Access Control** | Authentication, privileges | RBAC, MFA, IAM |
+| **Cryptography** | Encryption, keys | TLS, secrets management |
+| **Operations** | Change mgmt, backups | CI/CD, backup procedures |
+| **Development** | Secure SDLC, testing | SAST/DAST, code review |
+| **Suppliers** | Third-party security | Supply chain (Lab 8) |
+| **Incidents** | Response procedures | IR playbooks |
+
+---
+
+### ๐ Certification Process
+
+```mermaid
+flowchart LR
+ Gap[๐ Gap Analysis] --> Implement[โ๏ธ Implement
6-12 months]
+ Implement --> Audit[๐ External Audit]
+ Audit --> Cert{โ
Pass?}
+ Cert -->|Yes| Certificate[๐๏ธ Certificate]
+ Cert -->|No| Fix[๐ง Fix]
+ Fix --> Audit
+
+ Certificate --> Annual[๐ Annual
Surveillance]
+ Annual -.->|3 years| Recert[๐ Recertify]
+
+ style Certificate fill:#e8f5e8,stroke:#388e3c,stroke-width:3px,color:#2c3e50
+```
+
+**Timeline & Cost:**
+* โฐ Preparation: 6-12 months
+* ๐ฐ Cost: $15K-$50K (audits + consulting)
+* ๐ Maintenance: Annual surveillance audits
+* ๐
Renewal: Every 3 years
+
+---
+
+### ๐ผ Why Organizations Pursue ISO 27001
+
+**Benefits:**
+* ๐ค Customer trust (global recognition)
+* ๐ผ Competitive advantage (required for some RFPs)
+* ๐ International sales (accepted in EU, Asia)
+* ๐ Reduces audits (one cert vs many customer audits)
+
+**Not for everyone:**
+* ๐ฐ Expensive for SMBs (consider SOC 2 instead)
+* โฐ Time-consuming
+* ๐ Bureaucratic overhead
+
+
+๐ญ ISO 27001 vs SOC 2
+
+| Aspect | ISO 27001 | SOC 2 |
+|--------|-----------|-------|
+| **Recognition** | Global | Primarily US |
+| **Certificate** | Yes | No (report only) |
+| **Cost** | Higher ($15K-$50K) | Lower ($10K-$30K) |
+| **Timeline** | 6-12 months | 3-6 months |
+| **Best for** | International, EU sales | US SaaS companies |
+
+**Choose based on:** Customer requirements
+
+
+---
+
+## ๐ Slide 12 โ ๐ณ Other Key Frameworks (Overview)
+
+### Quick Comparison
+
+| Framework | Applies When | Key Requirement | Penalty |
+|-----------|-------------|-----------------|---------|
+| ๐ณ **PCI-DSS** | Accept credit cards | Protect cardholder data | $500K/month |
+| ๐ **SOC 2** | SaaS provider | Trust Service Criteria | Lost sales |
+| ๐ฅ **HIPAA** | Healthcare data (US) | Protect PHI, encryption | $1.5M/year |
+| ๐๏ธ **FedRAMP** | US gov cloud | NIST 800-53 controls | No access |
+
+---
+
+### ๐ณ PCI-DSS (Payment Card Industry)
+
+**12 Requirements (grouped):**
+* ๐ Secure network (firewalls, no defaults)
+* ๐ Protect cardholder data (encrypt storage + transmission)
+* ๐ Vulnerability management (secure development, anti-virus)
+* ๐ Access control (restrict access, unique IDs)
+* ๐ Monitor networks (logs, testing)
+* ๐ Security policy (documented, maintained)
+
+**Developer focus:**
+* Never store full card numbers (tokenize)
+* Use payment gateway APIs
+* Follow OWASP Top 10
+
+---
+
+### ๐ SOC 2 (Service Organization Control)
+
+**Trust Service Criteria:**
+* **Security** (required): Protection from unauthorized access
+* **Availability** (optional): System uptime
+* **Processing Integrity** (optional): Accurate processing
+* **Confidentiality** (optional): Confidential data protected
+* **Privacy** (optional): Personal info protected
+
+**Types:**
+* **Type I:** Controls exist (point-in-time)
+* **Type II:** Controls work over 6-12 months
+
+**Timeline:** 6-12 months, $10K-$30K
+
+---
+
+### ๐ฅ HIPAA (Healthcare - US)
+
+**Technical Safeguards:**
+* ๐ Access control (unique IDs, auto-logoff)
+* ๐ Audit logs (all PHI access tracked)
+* ๐ Encryption (PHI at rest + transit)
+* ๐ Integrity controls (prevent alteration)
+
+**Key:** BAA (Business Associate Agreement) required with vendors
+
+---
+
+### ๐๏ธ FedRAMP (Federal Cloud - US)
+
+**Authorization Levels:**
+* **Low:** Public data
+* **Moderate:** CUI (most common)
+* **High:** National security
+
+**Reality:**
+* โฐ 12-18 months authorization
+* ๐ฐ $100K-$500K cost
+* ๐ฏ Only for US federal sales
+
+---
+
+## ๐ Fun Break: "The โฌ746M Cookie"
+
+### ๐ฐ Biggest GDPR Fines
+
+**Top 3:**
+1. **Amazon:** โฌ746M (2021) - Targeted ads without consent
+2. **Meta:** โฌ1.2B (2023) - Illegal EU-US data transfers
+3. **Google:** โฌ90M (2021) - Cookie consent dark patterns
+
+**Common violations:**
+* ๐ช Cookie reject harder than accept
+* ๐ง Marketing without consent
+* ๐๏ธ Not deleting data (soft delete โ deleted)
+* ๐ Poor security (unencrypted databases)
+
+**Lessons:**
+* โ
Consent must be real (reject = easy as accept)
+* โ
Deletion must be permanent (overwrite data)
+* โ
Privacy policy must be clear (plain language)
+* โ
Cooperate with regulators (reduces fines)
+
+**Developer reality:**
+* Before GDPR: `DELETE FROM users WHERE id = ?`
+* After GDPR: 500 lines cascade deletion + backups + logs
+
+---
+
+๐ **Resources for Group 3:**
+* [GDPR Official](https://gdpr.eu/)
+* [NIST CSF](https://www.nist.gov/cyberframework)
+* [ISO 27001](https://www.iso.org/isoiec-27001-information-security.html)
+* [PCI-DSS](https://www.pcisecuritystandards.org/)
+* [SOC 2](https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/sorhome)
+* [HIPAA Security Rule](https://www.hhs.gov/hipaa/for-professionals/security/index.html)
+
+---
+
+## ๐ Group 4: Security Maturity Models
+
+## ๐ Slide 13 โ ๐ฏ Security Maturity Model Concepts
+
+* ๐ฏ **Maturity model** = framework to assess and improve security practices
+* ๐ **Purpose:** Benchmark current state, plan improvements, track progress
+* ๐ **Not compliance:** Maturity = continuous improvement, Compliance = pass/fail
+
+```mermaid
+flowchart LR
+ Level0[๐ Level 0
Ad-hoc] --> Level1[๐ Level 1
Initial]
+ Level1 --> Level2[โ๏ธ Level 2
Managed]
+ Level2 --> Level3[๐ฏ Level 3
Defined]
+ Level3 --> Level4[๐ Level 4
Measured]
+ Level4 --> Level5[๐ Level 5
Optimized]
+
+ style Level0 fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Level1 fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style Level2 fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,color:#2c3e50
+ style Level3 fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style Level4 fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Level5 fill:#1b5e20,stroke:#388e3c,stroke-width:3px,color:#fff
+```
+
+---
+
+### ๐ Typical Maturity Levels
+
+| Level | Name | Characteristics | Example |
+|-------|------|-----------------|---------|
+| **0** | Non-existent | No practices | No security testing |
+| **1** | Initial/Ad-hoc | Reactive, inconsistent | Manual security reviews |
+| **2** | Managed | Documented, repeatable | Some automated scans |
+| **3** | Defined | Standardized, organization-wide | Security in all CI/CD |
+| **4** | Measured | Quantified, metrics-driven | MTTR tracked, improving |
+| **5** | Optimized | Continuous improvement, predictive | AI-driven, proactive |
+
+**Most organizations:** Level 2-3 (Level 5 is rare)
+
+---
+
+### ๐ฏ Why Use Maturity Models?
+
+**Benefits:**
+* ๐ **Objective assessment:** Where are we now?
+* ๐บ๏ธ **Roadmap planning:** Where should we go?
+* ๐ **Progress tracking:** Are we improving?
+* ๐ผ **Executive communication:** Show maturity to leadership
+* ๐ค **Benchmarking:** Compare to industry peers
+
+**Use cases:**
+* Gap analysis (what's missing?)
+* Budget justification (why invest in security?)
+* Team planning (prioritize improvements)
+* Customer requirements (prove security maturity)
+
+---
+
+### โ๏ธ Maturity vs Compliance
+
+**Maturity Model:**
+* ๐ฏ Goal: Continuous improvement
+* ๐ Focus: How well do you do things
+* ๐ Assessment: Levels 0-5
+* ๐ Frequency: Ongoing self-assessment
+* ๐ก Outcome: Improvement roadmap
+
+**Compliance:**
+* ๐ฏ Goal: Meet minimum requirements
+* ๐ Focus: Do you meet standards
+* โ
Assessment: Pass/fail
+* ๐
Frequency: Annual/periodic audits
+* ๐ Outcome: Certificate/attestation
+
+**Both are important:**
+* Compliance = floor (minimum)
+* Maturity = ceiling (excellence)
+
+
+๐ญ Common Mistake: Focusing only on maturity level numbers
+
+**Wrong approach:**
+* "We must reach Level 4 in all practices!"
+* Spreads resources thin
+* Level 4 everywhere = expensive
+
+**Right approach:**
+* "We need Level 4 in critical areas, Level 2 in others"
+* Focus on what matters most
+* Risk-based prioritization
+
+**Example:**
+* **Authentication:** Level 4 (critical)
+* **Code signing:** Level 3 (important)
+* **Security awareness:** Level 2 (basic)
+* **Physical security:** Level 1 (cloud-native company)
+
+**Strategy:** Mature what matters, maintain minimum elsewhere
+
+
+---
+
+## ๐ Slide 14 โ ๐ฆ
OWASP SAMM (Software Assurance Maturity Model)
+
+* ๐ฆ
**OWASP SAMM:** Framework for software security maturity
+* ๐ฏ **Focus:** Software security practices (not entire org)
+* ๐ **Structure:** 5 business functions, 15 practices, 3 maturity levels
+* ๐ **Free:** Open-source model with tools
+* ๐ **Learn more:** [OWASP SAMM](https://owaspsamm.org/)
+
+```mermaid
+flowchart LR
+ SAMM[๐ฆ
OWASP SAMM] --> Gov[๐๏ธ Governance]
+ SAMM --> Design[๐ Design]
+ SAMM --> Impl[โ๏ธ Implementation]
+ SAMM --> Verif[โ
Verification]
+ SAMM --> Ops[๐ Operations]
+
+ style SAMM fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ SAMM Structure: 5 Business Functions
+
+**๐๏ธ Governance:**
+* Strategy & Metrics (define security goals)
+* Policy & Compliance (document standards)
+* Education & Guidance (train teams)
+
+**๐ Design:**
+* Threat Assessment (identify risks)
+* Security Requirements (define what's needed)
+* Security Architecture (design secure systems)
+
+**โ๏ธ Implementation:**
+* Secure Build (build securely)
+* Secure Deployment (deploy securely)
+* Defect Management (track and fix)
+
+**โ
Verification:**
+* Architecture Analysis (review design)
+* Requirements-driven Testing (test requirements)
+* Security Testing (automated + manual)
+
+**๐ Operations:**
+* Incident Management (respond to incidents)
+* Environment Management (secure infrastructure)
+* Operational Enablement (support teams)
+
+---
+
+### ๐ Maturity Levels in SAMM
+
+**Each practice has 3 levels (0-3):**
+
+| Level | Description | Example: Security Testing |
+|-------|-------------|---------------------------|
+| **0** | No practice | No security testing |
+| **1** | Initial | Manual security reviews, ad-hoc |
+| **2** | Managed | Automated SAST/DAST in CI/CD |
+| **3** | Defined | Comprehensive testing, metrics, continuous improvement |
+
+**Assessment result:** Scorecard showing current maturity per practice
+
+---
+
+### ๐บ๏ธ SAMM Roadmap Generation
+
+**Process:**
+1. **Current state:** Assess all 15 practices (self-assessment)
+2. **Target state:** Define desired maturity (risk-based)
+3. **Gap analysis:** Identify gaps (current vs target)
+4. **Roadmap:** Prioritize improvements (phases)
+5. **Implement:** Execute roadmap (quarterly iterations)
+6. **Measure:** Track progress (re-assess regularly)
+
+```mermaid
+flowchart LR
+ Assess[๐ Assess
Current State] --> Target[๐ฏ Define
Target State]
+ Target --> Gap[๐ Gap
Analysis]
+ Gap --> Roadmap[๐บ๏ธ Build
Roadmap]
+ Roadmap --> Implement[โ๏ธ Implement
Improvements]
+ Implement --> Measure[๐ Measure
Progress]
+ Measure -.->|Iterate| Assess
+
+ style Roadmap fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ฏ SAMM for DevSecOps Teams
+
+**Most relevant practices:**
+
+| SAMM Practice | DevSecOps Mapping |
+|---------------|-------------------|
+| **Secure Build** | SAST/DAST in CI/CD, secret scanning |
+| **Secure Deployment** | IaC security, container scanning |
+| **Security Testing** | Automated security tests, DAST |
+| **Defect Management** | Vulnerability tracking, MTTR |
+| **Threat Assessment** | Threat modeling (Lab 2) |
+| **Security Requirements** | Security stories, acceptance criteria |
+
+**Tool:** [SAMM Toolbox](https://owaspsamm.org/assessment/) (online self-assessment)
+
+
+๐ญ SAMM Quick Start: Where to begin?
+
+**Priority order for DevSecOps:**
+
+**Phase 1 (First 3 months):**
+1. **Security Testing (Verification):** Add SAST/DAST to CI/CD
+2. **Defect Management (Implementation):** Track vulnerabilities
+3. **Secure Build (Implementation):** Secret scanning, dependency checks
+
+**Phase 2 (Months 4-6):**
+4. **Secure Deployment (Implementation):** IaC scanning
+5. **Threat Assessment (Design):** Basic threat modeling
+6. **Strategy & Metrics (Governance):** Define security KPIs
+
+**Phase 3 (Months 7-12):**
+7. **Security Requirements (Design):** Security in user stories
+8. **Education & Guidance (Governance):** Security training
+9. **Incident Management (Operations):** IR playbooks
+
+**Don't try to do everything at once!** Focus on high-impact, low-effort practices first.
+
+
+---
+
+## ๐ Slide 15 โ ๐ BSIMM (Building Security In Maturity Model)
+
+* ๐ **BSIMM:** Data-driven maturity model (descriptive, not prescriptive)
+* ๐ข **Based on:** Real companies (120+ organizations studied)
+* ๐ฏ **Shows:** What others are doing (not what you should do)
+* ๐
**Updated:** Annually with new data
+* ๐ **Learn more:** [BSIMM](https://www.bsimm.com/)
+
+**Key difference from SAMM:**
+* SAMM: "Here's what to do" (prescriptive)
+* BSIMM: "Here's what others do" (descriptive)
+
+---
+
+### ๐ BSIMM Structure
+
+**4 Domains, 12 Practices:**
+
+**๐๏ธ Governance:**
+* Strategy & Metrics
+* Compliance & Policy
+* Training
+
+**๐ Intelligence:**
+* Attack Models
+* Security Features & Design
+* Standards & Requirements
+
+**๐ง SSDL Touchpoints:**
+* Architecture Analysis
+* Code Review
+* Security Testing
+
+**๐ Deployment:**
+* Penetration Testing
+* Software Environment
+* Configuration Management & Vulnerability Management
+
+---
+
+### ๐ BSIMM Activities
+
+**Each practice has activities (119 total):**
+* Classified by maturity level
+* Shows prevalence (% of companies doing it)
+
+**Example: Code Review practice**
+* **Level 1:** Ad-hoc code reviews (75% of companies)
+* **Level 2:** Automated SAST in CI/CD (60%)
+* **Level 3:** AI-assisted code review (25%)
+
+**Insight:** "If 60% of companies do X, maybe we should too"
+
+---
+
+### ๐ฏ BSIMM vs SAMM Comparison
+
+| Aspect | BSIMM | SAMM |
+|--------|-------|------|
+| **Approach** | Descriptive (what others do) | Prescriptive (what to do) |
+| **Data** | Real company data | Community best practices |
+| **Cost** | Free (report) | Free (open-source) |
+| **Updates** | Annual | Ongoing |
+| **Best for** | Benchmarking | Improvement roadmap |
+| **Use case** | "Are we behind peers?" | "How to improve?" |
+
+**Use both:**
+* BSIMM: Benchmark against industry
+* SAMM: Build improvement roadmap
+
+
+๐ญ BSIMM Insight: What top performers do differently
+
+**Top 10% of BSIMM companies:**
+
+**They do MORE of:**
+* ๐ค Automation (CI/CD security fully automated)
+* ๐ Metrics (track everything, data-driven)
+* ๐ Training (regular security training for all)
+* ๐ Testing (multiple types: SAST, DAST, IAST, pentests)
+
+**They do LESS of:**
+* ๐ Manual processes (minimal manual reviews)
+* ๐ฏ Ad-hoc security (everything is systematic)
+* ๐ฅ Firefighting (proactive, not reactive)
+
+**Key insight:** Maturity = automation + measurement + consistency
+
+
+---
+
+## ๐ Slide 16 โ ๐ DevSecOps Maturity Assessment
+
+* ๐ **DevSecOps maturity:** Specific to DevSecOps practices
+* ๐ฏ **Dimensions:** Culture, process, automation, technology
+* ๐ **Levels:** Similar to general maturity (0-5)
+
+```mermaid
+flowchart LR
+ subgraph "๐ DevSecOps Maturity Dimensions"
+ Culture[๐ฅ Culture &
Organization]
+ Process[๐ Process &
Governance]
+ Auto[๐ค Automation &
Integration]
+ Tech[๐ ๏ธ Technology &
Tools]
+ end
+
+ Culture --> Maturity[๐ฏ Overall
Maturity]
+ Process --> Maturity
+ Auto --> Maturity
+ Tech --> Maturity
+
+ style Maturity fill:#e8f5e8,stroke:#388e3c,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ Maturity Levels by Dimension
+
+**๐ฅ Culture & Organization:**
+
+| Level | Characteristics |
+|-------|-----------------|
+| **1** | Security is afterthought, separate team |
+| **2** | Security awareness growing, some collaboration |
+| **3** | Security champions in teams, shared responsibility |
+| **4** | Security embedded in culture, everyone owns it |
+| **5** | Security as enabler, competitive advantage |
+
+**๐ Process & Governance:**
+
+| Level | Characteristics |
+|-------|-----------------|
+| **1** | No security processes, manual reviews |
+| **2** | Basic security policies, ad-hoc reviews |
+| **3** | Documented secure SDLC, consistent processes |
+| **4** | Optimized processes, continuous improvement |
+| **5** | Predictive, risk-adaptive processes |
+
+**๐ค Automation & Integration:**
+
+| Level | Characteristics |
+|-------|-----------------|
+| **1** | No automation, manual security tasks |
+| **2** | Some automated scans (weekly/monthly) |
+| **3** | Security in CI/CD, automated gates |
+| **4** | Full automation, auto-remediation |
+| **5** | AI-driven, self-healing systems |
+
+**๐ ๏ธ Technology & Tools:**
+
+| Level | Characteristics |
+|-------|-----------------|
+| **1** | No security tools |
+| **2** | Basic scanners (SAST or DAST) |
+| **3** | Multiple tools (SAST, DAST, SCA, IaC) |
+| **4** | Integrated platform, centralized dashboards |
+| **5** | Unified observability, AI/ML-powered |
+
+---
+
+### ๐ฏ Self-Assessment Exercise
+
+**Quick maturity check (answer for your organization):**
+
+**Culture:**
+* โ Do developers view security as their responsibility? (Yes = Level 3+)
+* โ Are there security champions in each team? (Yes = Level 3+)
+
+**Process:**
+* โ Is secure SDLC documented and followed? (Yes = Level 3+)
+* โ Are security requirements part of every user story? (Yes = Level 3+)
+
+**Automation:**
+* โ Do all builds run security scans? (Yes = Level 3+)
+* โ Are security gates automated in CI/CD? (Yes = Level 3+)
+
+**Technology:**
+* โ Do you have SAST, DAST, and SCA? (Yes = Level 3+)
+* โ Is vulnerability data centralized? (Yes = Level 3+)
+
+**Result:**
+* Mostly No: Level 1-2 (building foundation)
+* Half Yes: Level 2-3 (making progress)
+* Mostly Yes: Level 3-4 (mature program)
+
+---
+
+### ๐บ๏ธ Maturity Progression Path
+
+**Typical journey:**
+
+```mermaid
+flowchart LR
+ Start[๐ฑ Level 1
6 months] --> L2[๐ Level 2
6 months]
+ L2 --> L3[๐ฏ Level 3
12 months]
+ L3 --> L4[๐ Level 4
18 months+]
+
+ Start -.->|Tools| T1[Add SAST/DAST]
+ L2 -.->|Automation| T2[CI/CD integration]
+ L3 -.->|Culture| T3[Security champions]
+ L4 -.->|Optimization| T4[Metrics-driven]
+
+ style Start fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#2c3e50
+ style L3 fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+ style L4 fill:#1b5e20,stroke:#388e3c,stroke-width:2px,color:#fff
+```
+
+**Timeline:** 2-3 years from Level 1 to Level 4 (realistic)
+
+---
+
+### ๐ก Improvement Strategies by Current Level
+
+**If you're at Level 1:**
+* ๐ฏ Focus: Add basic tooling (SAST, secret scanning)
+* โฐ Timeline: 6 months to reach Level 2
+* ๐ฐ Investment: Tools + training
+
+**If you're at Level 2:**
+* ๐ฏ Focus: Automate in CI/CD, add security gates
+* โฐ Timeline: 6-12 months to reach Level 3
+* ๐ฐ Investment: CI/CD integration, process docs
+
+**If you're at Level 3:**
+* ๐ฏ Focus: Metrics, culture, advanced automation
+* โฐ Timeline: 12-18 months to reach Level 4
+* ๐ฐ Investment: Dashboards, training, optimization
+
+**If you're at Level 4:**
+* ๐ฏ Focus: Innovation, predictive, AI/ML
+* โฐ Timeline: Ongoing
+* ๐ฐ Investment: R&D, advanced tools
+
+
+๐ญ Realistic Expectations: How long does maturity take?
+
+**Startup (< 50 people):**
+* Year 1: Level 1 โ Level 2 (tools + basics)
+* Year 2: Level 2 โ Level 3 (automation + process)
+* Year 3+: Level 3 โ Level 4 (maturity + culture)
+
+**Enterprise (1000+ people):**
+* Year 1: Assess current state (varies by team)
+* Year 2-3: Standardize across org (reach Level 3)
+* Year 4+: Optimize and innovate (Level 4)
+
+**Key factors:**
+* ๐ฐ Budget (tools, headcount)
+* ๐ฅ Leadership support (cultural change)
+* ๐ Team skills (training needed)
+* ๐ Starting point (Level 0 vs Level 2)
+
+**Don't rush:** Sustainable maturity > quick wins
+
+
+---
+
+## ๐ Group 5: Continuous Improvement
+
+## ๐ Slide 17 โ ๐ Feedback Loops & Security Improvement
+
+* ๐ **Continuous improvement:** Core DevSecOps principle
+* ๐ **Feedback loops:** Measure โ Analyze โ Improve โ Measure
+* ๐ฏ **Goal:** Get better over time (security + speed)
+
+```mermaid
+flowchart LR
+ Measure[๐ Measure
Metrics, KPIs] --> Analyze[๐ Analyze
Root causes]
+ Analyze --> Improve[โก Improve
Fix, optimize]
+ Improve --> Validate[โ
Validate
Did it work?]
+ Validate --> Measure
+
+ style Measure fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#2c3e50
+ style Improve fill:#e8f5e8,stroke:#388e3c,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ Types of Feedback Loops
+
+**๐ Short-term (daily/weekly):**
+* Developer gets scan results in IDE
+* PR blocked by security gate
+* Alert triggers immediate investigation
+
+**๐
Medium-term (sprint/monthly):**
+* Sprint retrospectives (security topics)
+* Monthly security metrics review
+* Vulnerability backlog trends
+
+**๐ Long-term (quarterly/annual):**
+* Maturity assessment (SAMM/BSIMM)
+* Program effectiveness review
+* Strategic adjustments
+
+---
+
+### ๐จ Post-Incident Reviews (Blameless Post-Mortems)
+
+**Purpose:** Learn from incidents without blame
+
+**Process:**
+1. **Document:** What happened (timeline)
+2. **Analyze:** Why it happened (root causes)
+3. **Identify:** What could prevent recurrence
+4. **Implement:** Action items (fix, improve)
+5. **Share:** Lessons learned (org-wide)
+
+**Key rule:** No blame, focus on systems/process
+
+**Example questions:**
+* ๐ค Why wasn't this caught in scanning?
+* ๐ค Why did it take X days to detect?
+* ๐ค What process failed?
+* ๐ค How can we prevent this category?
+
+```mermaid
+flowchart LR
+ Incident[๐จ Security
Incident] --> Document[๐ Document
What happened]
+ Document --> RCA[๐ Root Cause
Analysis]
+ RCA --> Actions[โก Action Items
Fix, improve]
+ Actions --> Implement[โ
Implement
Changes]
+ Implement --> Share[๐ข Share
Lessons Learned]
+
+ Share -.->|Prevent| Future[๐ก๏ธ Future
Incidents]
+
+ style Incident fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Implement fill:#e8f5e8,stroke:#388e3c,stroke-width:2px,color:#2c3e50
+```
+
+---
+
+### ๐ Security Retrospectives
+
+**Sprint retrospective with security focus:**
+
+**What went well? ๐ข**
+* All PRs passed security gates
+* MTTR decreased from 5 to 3 days
+* New SAST tool reduced false positives
+
+**What needs improvement? ๐ก**
+* 3 critical vulnerabilities missed by scanners
+* Manual secret scanning slowed deployment
+* Security training attendance low
+
+**Action items: โก**
+* Add Grype for container scanning
+* Automate secret scanning in pre-commit
+* Make security training during work hours
+
+**Retrospective frequency:** Every sprint (2 weeks)
+
+---
+
+### ๐ฏ Setting Improvement Goals (SMART)
+
+**Example goals:**
+
+**โ Vague goal:** "Improve security"
+
+**โ
SMART goal:** "Reduce MTTR for critical vulnerabilities from 5 days to 2 days by Q3 2024"
+* Specific: MTTR for critical vulns
+* Measurable: 5 days โ 2 days
+* Achievable: 60% reduction
+* Relevant: Lower risk exposure
+* Time-bound: Q3 2024
+
+**More examples:**
+* "Increase security test coverage from 60% to 80% by Q2"
+* "Achieve 100% automated security scans in CI/CD by Q4"
+* "Reduce false positive rate from 30% to 15% in 6 months"
+
+---
+
+### ๐ Gamification & Security Champions
+
+**Security champions program:**
+* ๐ฅ One per team (volunteers)
+* ๐ Extra training (security experts)
+* ๐ค Liaison between security and dev teams
+* ๐ Track security metrics for their team
+
+**Gamification ideas:**
+* ๐ Leaderboards (most vulns fixed, fastest MTTR)
+* ๐๏ธ Badges (clean scans, security contributions)
+* ๐ Rewards (swag, recognition, bonuses)
+* ๐ฎ CTF competitions (capture the flag)
+
+**Goal:** Make security engaging, not punishing
+
+
+๐ญ Warning: Gamification done wrong
+
+**Bad gamification:**
+* ๐ Reward quantity over quality (fix 100 low vulns, ignore critical)
+* ๐ Public shaming (worst team rankings)
+* ๐ฐ High-stakes rewards (creates perverse incentives)
+
+**Good gamification:**
+* ๐ฏ Reward meaningful metrics (MTTR, recurrence rate)
+* ๐ค Team-based, not individual (collaboration)
+* ๐ Recognition, not just rewards (celebrate wins)
+* ๐ Progress tracking (improvement over time)
+
+**Remember:** Metrics + rewards = gaming risk (Goodhart's Law from Group 2!)
+
+
+---
+
+## ๐ Slide 18 โ ๐ค Compliance as Code & Automation
+
+* ๐ค **Compliance as Code:** Automate compliance checks and evidence
+* ๐ฏ **Goal:** Continuous compliance (not annual audits)
+* ๐ **Benefits:** Faster audits, reduced costs, always compliant
+
+```mermaid
+flowchart LR
+ Traditional[๐ Traditional
Annual audit
Manual evidence] -->|Slow| Cost1[๐ฐ High cost
3-6 months prep]
+
+ Automated[๐ค Compliance
as Code
Automated evidence] -->|Fast| Cost2[๐ฐ Low cost
Always ready]
+
+ style Traditional fill:#ffebee,stroke:#d32f2f,stroke-width:2px,color:#2c3e50
+ style Automated fill:#e8f5e8,stroke:#388e3c,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ Policy as Code Tools
+
+**Popular frameworks:**
+
+**๐ฏ Open Policy Agent (OPA):**
+* Write policies in Rego language
+* Enforce in CI/CD, Kubernetes, cloud
+* Example: "Block deployments with critical vulns"
+
+**๐ HashiCorp Sentinel:**
+* Policy engine for Terraform
+* Enforce before infrastructure changes
+* Example: "Require encryption for all databases"
+
+**๐ ๏ธ Cloud-specific:**
+* AWS Config Rules (automated compliance checks)
+* Azure Policy (enforce resource standards)
+* GCP Organization Policy (centralized governance)
+
+---
+
+### ๐ค Automated Compliance Checks
+
+**Examples:**
+
+**Infrastructure compliance:**
+* All S3 buckets must be private (scan daily)
+* All databases must be encrypted (enforce in IaC)
+* No security groups with 0.0.0.0/0 (block in CI/CD)
+
+**Application compliance:**
+* No secrets in code (pre-commit hook)
+* All APIs require authentication (automated test)
+* PII must be encrypted (data validation)
+
+**Operational compliance:**
+* All logins logged (SIEM integration)
+* Failed logins trigger alerts (automated)
+* Logs retained for 7 years (automated retention)
+
+---
+
+### ๐ Automated Evidence Collection
+
+**Traditional audit:**
+* ๐ Auditor: "Show me access control logs for Q2"
+* ๐จโ๐ป You: "Let me dig through systems for 2 weeks..."
+
+**Automated audit:**
+* ๐ Auditor: "Show me access control logs for Q2"
+* ๐ค System: "Here's the automated report (generated in 5 seconds)"
+
+**What to automate:**
+* ๐ Security scan reports (daily)
+* ๐ Policy compliance status (real-time dashboard)
+* ๐ Access logs (centralized, queryable)
+* ๐ Change logs (Git commits, deployments)
+* ๐ Training completion (automated tracking)
+
+```mermaid
+flowchart LR
+ Systems[๐ป Systems &
Tools] -->|Automated| Evidence[๐ Evidence
Repository]
+
+ Evidence --> Report1[๐ SOC 2 Report]
+ Evidence --> Report2[๐ ISO 27001 Audit]
+ Evidence --> Report3[๐ PCI-DSS Scan]
+ Evidence --> Report4[๐ GDPR Compliance]
+
+ style Evidence fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#2c3e50
+```
+
+---
+
+### ๐ Continuous Compliance Monitoring
+
+**Shift from:**
+* ๐
Annual audit (point-in-time snapshot)
+* โ
Pass or fail
+
+**Shift to:**
+* ๐ Continuous monitoring (real-time)
+* ๐ Trending compliance (always improving)
+
+**Implementation:**
+* ๐ Daily compliance scans (infrastructure, code)
+* ๐ Real-time dashboard (compliance status)
+* ๐จ Alerts on drift (unauthorized changes)
+* ๐ Trend analysis (improving or degrading?)
+
+**Benefits:**
+* โ
Always audit-ready
+* โฐ Faster audit process (evidence ready)
+* ๐ฐ Lower audit costs (less manual work)
+* ๐ก๏ธ Catch issues faster (don't wait for annual audit)
+
+
+๐ญ Example: AWS Config for Continuous Compliance
+
+**AWS Config Rules (automated compliance):**
+
+**Rule 1: S3 buckets must be private**
+* Check: Every hour
+* Action: Alert if public bucket found
+* Remediation: Auto-fix (set to private)
+
+**Rule 2: EC2 instances must have encryption**
+* Check: On launch
+* Action: Block if not encrypted
+* Evidence: Report of all checks (automated)
+
+**Rule 3: IAM users must have MFA**
+* Check: Daily
+* Action: Alert if MFA disabled
+* Evidence: Compliance dashboard (real-time)
+
+**Result:**
+* Continuous compliance (not annual)
+* Automated evidence (auditor-ready)
+* Faster remediation (hours, not months)
+
+**Similar tools:** Azure Policy, GCP Organization Policy, Chef InSpec
+
+
+---
+
+๐ **Resources for Groups 4 & 5:**
+* [OWASP SAMM](https://owaspsamm.org/)
+* [BSIMM](https://www.bsimm.com/)
+* [Open Policy Agent](https://www.openpolicyagent.org/)
+* [AWS Config Rules](https://docs.aws.amazon.com/config/)
+* [Chef InSpec](https://www.inspec.io/)
+* [Toyota Production System](https://en.wikipedia.org/wiki/Toyota_Production_System)
+* [Blameless Post-Mortems](https://sre.google/sre-book/postmortem-culture/)
+
+---
\ No newline at end of file