diff --git a/submissions/lab10-walkthrough.md b/submissions/lab10-walkthrough.md
new file mode 100644
index 00000000..586ba298
--- /dev/null
+++ b/submissions/lab10-walkthrough.md
@@ -0,0 +1,53 @@
+# 5-Minute DevSecOps Program Walkthrough — Juice Shop
+
+## (0:00–0:30) Context
+
+I built a DevSecOps program around OWASP Juice Shop to demonstrate how security controls can be integrated throughout the software development lifecycle rather than applied only before release.
+
+The project combines secret scanning, commit signing, SBOM generation, SCA, SAST, DAST, infrastructure scanning, container signing, policy enforcement, runtime monitoring, and centralized vulnerability management in DefectDojo.
+
+## (0:30–2:00) Layers
+
+The first layer is **pre-commit**. Every commit is checked with **gitleaks** to prevent accidental secret disclosure, and commits are signed with SSH keys to provide authenticity and traceability.
+
+The **build** stage generates a Software Bill of Materials using **Syft**. That SBOM is analyzed by **Grype** for dependency vulnerabilities, while **Semgrep** performs static analysis of the application source code to detect insecure coding patterns before deployment.
+
+Before deployment, infrastructure is validated with **Checkov**, container images are signed using **Cosign**, and deployment policies are enforced with **Conftest** to prevent non-compliant resources from reaching production.
+
+At runtime, **Falco** monitors the Kubernetes environment using eBPF and detects suspicious activity such as unexpected shell execution or privilege escalation attempts.
+
+Finally, all security results are imported into **DefectDojo**, where findings from multiple scanners are aggregated, deduplicated, prioritized, and managed using SLA rules and governance metrics such as vulnerability age and MTTR.
+
+## (2:00–3:00) Findings + Closures
+
+No Critical findings were closed during this laboratory exercise because the focus was on building and integrating the security program rather than performing remediation.
+
+One Low-severity finding affecting the demonstration environment was marked as **Risk Accepted** until **2027-01-04**. It was accepted because the environment exists solely for educational purposes, the risk is low, and the acceptance has a defined expiration date.
+
+One good example of correlation was **CVE-2021-23337**, which appeared in both the application dependency scan and the container image scan. DefectDojo recognized the duplicate findings so the issue could be tracked as a single vulnerability instead of multiple independent reports.
+
+## (3:00–4:00) Metrics
+
+Current MTTR is not available because no findings have been remediated yet. The long-term objective is to reduce High-severity MTTR toward the DORA Elite benchmark of less than one day.
+
+The median vulnerability age is currently **0 days**, since all findings were imported during the same reporting period.
+
+SLA compliance is **100%**, as every finding remains within the configured remediation window.
+
+The backlog trend is currently **rising**, reflecting the initial onboarding of approximately 400 findings into the vulnerability management program. Future releases should reduce this backlog through continuous remediation.
+
+## (4:00–4:30) Next Steps
+
+If I had another quarter, I'd integrate automatic remediation workflows and continuous DefectDojo imports directly into the CI/CD pipeline.
+
+This would advance the OWASP SAMM **Defect Management** practice by reducing remediation time, improving governance reporting, and making security metrics part of every software release.
+
+## (4:30–5:00) Q&A Anticipation
+
+**1. "How would you handle a Log4Shell scenario?"**
+
+The SBOM generated by Syft provides a complete inventory of application dependencies, making it possible to immediately identify every affected component. Grype can quickly detect vulnerable Log4j versions, DefectDojo aggregates the affected findings, and remediation can be prioritized according to the configured SLA until all vulnerable versions are upgraded and verified.
+
+**2. "Why didn't you use IAST or paid tools?"**
+
+The goal of this project was to build a complete DevSecOps pipeline using widely available open-source tools that anyone can reproduce. While commercial IAST and enterprise platforms often provide deeper analysis and better integrations, the selected toolchain demonstrates the core DevSecOps practices without licensing costs and is well suited for educational and small-team environments.
diff --git a/submissions/lab10.md b/submissions/lab10.md
new file mode 100644
index 00000000..2c0e1814
--- /dev/null
+++ b/submissions/lab10.md
@@ -0,0 +1,89 @@
+# Lab 10 — Submission
+
+## Task 1: DefectDojo Setup + Import
+
+### DefectDojo version
+- Version installed: DefectDojo v2.58.2 (`defectdojo/defectdojo-django:latest`)
+
+### Product + Engagement
+- Product ID: 1
+- Product name: OWASP Juice Shop
+- Engagement ID: 4
+- Engagement status: In Progress
+
+### Imports completed
+
+| Lab | Scan type | File | Findings imported |
+|-----|-----------|------|------------------:|
+| 4 | Anchore Grype | grype-from-sbom.json | 104 |
+| 4 | Trivy Scan | trivy.json | 112 |
+| 5 | Semgrep JSON Report | semgrep.json | 27 |
+| 5 | ZAP Scan | auth-report.json | 12 |
+| 6 | Checkov Scan | results_json.json | 80 |
+| 6 | KICS Scan | kics-ansible/results.json | 10 |
+| 6 | KICS Scan | kics-pulumi/results.json | 6 |
+| 7 | Trivy Scan (image) | trivy-image.json | 50 |
+| 7 | Trivy Operator Scan | trivy-k8s.json | 0 |
+| **Total raw imports** | | | **401** |
+| **After dedup** | | | **400 unique findings** |
+
+### Dedup example (Lecture 10 slide 11)
+
+Find ONE finding that DefectDojo dedupped across tools (same CVE/issue from ≥2 scanners). Quote:
+
+- CVE/ID: CVE-2021-23337
+- Number of source tools: 2 — Trivy Scan, Trivy Scan (image)
+- DefectDojo's single finding ID: 163
+
+## Task 2: Governance Report
+
+### Executive Summary (3 sentences)
+
+Juice Shop, scanned across 9 imported scan sources (7 tools), currently has 400 open findings (17 Critical + 165 High). Mean Time to Remediate (MTTR) on closed-this-period findings is not available because no findings have been mitigated yet. 100% of findings are currently within their configured SLA.
+
+### Findings by severity (active only)
+
+| Severity | Count |
+|----------|------:|
+| Critical | 17 |
+| High | 165 |
+| Medium | 176 |
+| Low | 29 |
+| Info | 13 |
+
+### Findings by source tool
+
+| Tool | Active | Mitigated | False Positive | Risk Accepted |
+|------|-------:|----------:|---------------:|--------------:|
+| Anchore Grype | 104 | 0 | 0 | 0 |
+| Trivy Scan | 161 | 0 | 0 | 1 |
+| Semgrep JSON Report | 27 | 0 | 0 | 0 |
+| ZAP Scan | 12 | 0 | 0 | 0 |
+| Checkov Scan | 80 | 0 | 0 | 0 |
+| KICS Scan | 16 | 0 | 0 | 0 |
+| Trivy Operator Scan | 0 | 0 | 0 | 0 |
+
+### Program metrics
+
+- **MTTD** (Mean Time to Detect): 0 days
+- **MTTR** (Mean Time to Remediate): N/A
+- **Vuln-age median** (open findings): 0 days
+- **Backlog trend**: +400 findings vs. baseline
+- **SLA compliance**: 100%
+
+### Risk-accepted items (must have expiry)
+
+| Finding | Severity | Reason | Expiry date |
+|---------|----------|--------|-------------|
+| CVE-2026-42766 (Libssl3t64 package) | Low | Accepted for the course demonstration environment; remediation deferred because it does not affect the lab objectives | 2027-01-04 |
+
+### Next-quarter goal (OWASP SAMM ladder step — Lecture 9 slide 15)
+
+The next SAMM practice to mature would be **Defect Management**. The current backlog includes 165 High-severity findings with no remediation history yet, so the primary goal is to establish an SLA-driven remediation workflow and reduce MTTR for High findings below 7 days through regular DefectDojo imports and vulnerability triage.
+
+## Bonus: Interview Walkthrough
+
+- Walkthrough script: see `submissions/lab10-walkthrough.md`
+- Practiced runtime: 4:30
+- Two anticipated Q&A questions covered: yes
+- Strongest claim in the script (most-quoted-by-interviewer line, in your view): "Multiple security scanners become significantly more valuable when their findings are centralized, deduplicated, and managed through a single governance process."