feat(lab10): defectdojo governance report and walkthrough

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,34 @@
+## Goal
+
+This PR delivers the required lab submission and supporting workflow artifacts.
+
+## Changes
+
+- Added or updated `submissions/labN.md`
+- Added or updated lab-related configuration files
+- Documented testing commands, observed outputs, and screenshots where useful
+
+## Testing
+
+Commands used:
+
+```bash
+<paste commands used for this lab here>
+```
+
+Observed output:
+
+```text
+<paste important output here>
+```
+
+## Artifacts & Screenshots
+
+- Submission file: `submissions/labN.md`
+- Screenshots or evidence: `<add screenshots or links if needed>`
+
+## Checklist
+
+- [ ] Title is clear (`feat(labN): <topic>` style)
+- [ ] No secrets/large temp files committed
+- [ ] Submission file at `submissions/labN.md` exists

.gitignore

@@ -29,3 +29,7 @@ node_modules/
 .venv/
 .DS_Store
 *.swp
+
+# Lab 10 local DefectDojo instance
+labs/lab10/work/dd/
+labs/lab10/work/*.json

submissions/lab10-walkthrough.md

@@ -0,0 +1,55 @@
+# 5-Minute DevSecOps Program Walkthrough — Juice Shop
+
+## (0:00–0:30) Context
+
+I built a small DevSecOps vulnerability management program around OWASP Juice Shop as the target application. The scope included SBOM generation, software composition analysis, SAST, DAST, IaC scanning, container scanning, Kubernetes scanning, supply-chain verification, runtime detection, and centralized vulnerability management in DefectDojo.
+
+The goal was not just to run scanners, but to connect their outputs into one program where findings are imported, prioritized, assigned SLA expectations, and tracked as a backlog.
+
+## (0:30–2:00) Layers
+
+The first layer was pre-commit security. I configured secret scanning with gitleaks and enabled signed commits, so the repository had protection against accidentally committed secrets and better commit authenticity.
+
+The second layer was build-time security. I generated SBOMs with Syft and used Grype and Trivy to identify vulnerable dependencies and container image vulnerabilities. This gave visibility into what components existed in the application and which advisories affected them.
+
+The third layer was application security testing. I used Semgrep for SAST and ZAP for DAST. Semgrep helped identify code-level patterns, while ZAP tested the running application from the outside, including an authenticated scan.
+
+The fourth layer was infrastructure and deployment security. I used Checkov and KICS to scan Terraform, Ansible, and Pulumi-style infrastructure definitions. I also used Kubernetes hardening controls such as restricted pod security settings, non-root execution, dropped capabilities, read-only root filesystem, resource limits, and network policies.
+
+The fifth layer was supply-chain and runtime security. I used Cosign to sign and verify artifacts and showed that tampered artifacts fail verification. For runtime detection, I used Falco custom rules to detect suspicious behavior in containers.
+
+Finally, I aggregated the findings into DefectDojo. This is the program layer: instead of having separate reports, DefectDojo gives one product, one engagement, severity tracking, SLA expectations, backlog metrics, and a place to investigate deduplication.
+
+## (2:00–3:00) Findings + Closures
+
+In this run, DefectDojo centralized 385 findings from the successful imports. The active backlog included 17 Critical findings, 164 High findings, 168 Medium findings, 27 Low findings, and 9 Info findings.
+
+The strongest correlation example was `GHSA-5mrr-rgp6-x4gr` affecting `marsdb:0.6.11`. It appeared in Grype and Trivy outputs as three related DefectDojo findings: IDs 98, 164, and 353. Automatic deduplication did not collapse them in this local run, likely because the scanner metadata and titles were slightly different and the CVE field was empty. That is a useful program lesson: scanner metadata normalization is required before relying on cross-tool deduplication.
+
+I did not risk-accept findings without expiry. If a finding is risk-accepted in a real program, it must have a clear reason, an owner, and an expiration date. Otherwise, risk acceptance becomes a way to hide vulnerabilities instead of managing them.
+
+## (3:00–4:00) Metrics
+
+The key metrics I tracked were severity distribution, active backlog, imported finding count, MTTR, vulnerability age, and SLA compliance. For this lab run, MTTD is effectively zero days because findings were detected when reports were imported into DefectDojo.
+
+MTTR is not available for this run because I did not fully remediate and close findings during the lab. In a real program, MTTR would be measured only on mitigated findings, comparing the detection date to the mitigation date.
+
+The backlog baseline is 385 active findings. The Critical and High backlog is 181 findings, which is about 47 percent of the total backlog. That means the immediate remediation focus should be Critical and High dependency vulnerabilities, container image vulnerabilities, and high-impact IaC misconfigurations.
+
+SLA compliance is based on the lecture matrix: Critical findings should be handled within 24 hours, High within 7 days, Medium within 30 days, and Low within 90 days.
+
+## (4:00–4:30) Next Steps
+
+If I had another quarter, I would automate DefectDojo imports directly from CI/CD pipelines. That would mature the OWASP SAMM Defect Management practice because vulnerability tracking would become continuous instead of manual.
+
+The next concrete step would be to normalize scanner metadata before import, especially CVE/GHSA identifiers, package names, and component versions. This would make deduplication more reliable and reduce repeated triage work.
+
+## (4:30–5:00) Q&A Anticipation
+
+### Question 1: How would you handle a Log4Shell scenario?
+
+I would start from the SBOM. Because the SBOM lists application components and dependencies, I can quickly search whether the vulnerable Log4j package exists in the product. Then I would use DefectDojo to identify affected findings, prioritize internet-exposed and exploitable services first, apply emergency patching or mitigation, and track remediation through SLA. After remediation, I would rescan and verify that the finding is closed.
+
+### Question 2: Why did you not use IAST or paid tools?
+
+I focused on open-source tools because this was a university lab and the goal was to build the full DevSecOps process, not to depend on commercial tooling. The tradeoff is that paid tools may provide better correlation, dashboards, and support, but the open-source stack still demonstrates the core program: scanning, signing, runtime detection, centralized findings, SLA, backlog metrics, and deduplication analysis.

submissions/lab10.md

@@ -0,0 +1,145 @@
+# Lab 10 — Vulnerability Management with DefectDojo
+
+## Task 1: DefectDojo Setup + Import
+
+### DefectDojo version
+
+- Version installed: DefectDojo 2.58.4
+- Deployment mode: local Docker Compose release configuration
+- URL: http://localhost:8080
+- Runtime evidence:
+  - `curl -I http://localhost:8080` returned `HTTP/1.1 302 Found`
+  - Redirect target: `/login?next=/`
+
+### Product + Engagement
+
+- Product Type ID: 2
+- Product Type name: Course Labs
+- Product ID: 1
+- Product name: OWASP Juice Shop
+- Engagement ID: 1
+- Engagement name: Course Semester Run
+- Engagement status: In Progress
+
+### Imports completed
+
+| Lab | Scan type | File | Findings imported |
+|-----|-----------|------|------------------:|
+| 4 | Anchore Grype | `labs/lab4/grype-from-sbom.json` | 104 |
+| 4 | Trivy Scan | `labs/lab4/trivy.json` | 113 |
+| 5 | Semgrep JSON Report | `labs/lab5/results/semgrep.json` | 22 |
+| 5 | ZAP Scan | `labs/lab5/results/auth-report.json` | 0 |
+| 6 | Checkov Scan | `labs/lab6/results/checkov-terraform/results_json.json` | 80 |
+| 6 | KICS Scan | `labs/lab6/results/kics-ansible/results.json` | 10 |
+| 6 | KICS Scan | `labs/lab6/results/kics-pulumi/results.json` | 6 |
+| 7 | Trivy Scan | `labs/lab7/results/trivy-image.json` | 50 |
+| 7 | Trivy Operator Scan | `labs/lab7/results/trivy-k8s.json` | 0 |
+| 9 | Falco custom runtime alerts | `labs/lab9/falco/logs/falco.log` | Not imported: custom runtime log format is not supported by the default importer |
+| **Total raw imported findings** | | | **385** |
+| **After DefectDojo import/dedup processing** | | | **385** |
+
+### Import notes
+
+The ZAP authenticated report existed as JSON, but DefectDojo's `ZAP Scan` parser in this local run expected XML and returned:
+
+    Wrong file format, please use xml.
+
+The Trivy Operator Scan test was created, but the imported report produced 0 findings in DefectDojo. This was documented as an importer/format limitation for this local run.
+
+### Dedup / cross-tool correlation example
+
+A repeated advisory was identified across scanner outputs:
+
+- Advisory ID: `GHSA-5mrr-rgp6-x4gr`
+- Affected package: `marsdb:0.6.11`
+- Severity: Critical
+- Related DefectDojo findings:
+  - Finding ID 98 — `GHSA-5mrr-rgp6-x4gr in marsdb:0.6.11` — Test 1 — Anchore Grype
+  - Finding ID 164 — `GHSA-5mrr-rgp6-x4gr Marsdb 0.6.11` — Test 2 — Trivy Scan
+  - Finding ID 353 — `GHSA-5mrr-rgp6-x4gr Marsdb 0.6.11` — Test 8 — Trivy Scan
+- Number of source tools/tests: 3
+- Observed dedup status:
+  - `duplicate: false`
+  - `duplicate_finding: null`
+
+In this local run, DefectDojo successfully centralized the scanner outputs, but automatic cross-tool deduplication did not collapse this repeated GHSA advisory into a single finding. The likely reason is scanner-specific metadata differences: Grype and Trivy produced slightly different titles, and the `cve` field was not populated for these imported SCA records. This is an important governance finding: before relying on cross-tool deduplication in CI/CD, scanner metadata should be normalized and DefectDojo deduplication rules should be validated.
+
+---
+
+## Task 2: Governance Report
+
+### SLA matrix
+
+The SLA matrix from Lecture 9 / Lecture 10 was applied as the target vulnerability management policy:
+
+| Severity | SLA |
+|----------|-----|
+| Critical | 24 hours |
+| High | 7 days |
+| Medium | 30 days |
+| Low | 90 days |
+
+### Executive Summary
+
+OWASP Juice Shop was scanned across multiple DevSecOps layers: SBOM/SCA, SAST, DAST, IaC, container image scanning, Kubernetes scanning, supply-chain verification, and runtime monitoring. DefectDojo centralized 385 findings from the successful imports, including 17 Critical and 164 High active findings. The main risk is concentrated in vulnerable dependencies, container image findings, and IaC misconfigurations, so the next remediation focus should be dependency upgrades, base image updates, and repeatable CI/CD imports into DefectDojo.
+
+### Findings by severity
+
+| Severity | Count |
+|----------|------:|
+| Critical | 17 |
+| High | 164 |
+| Medium | 168 |
+| Low | 27 |
+| Info | 9 |
+| **Total** | **385** |
+
+### Findings by source tool
+
+| Tool / Test | Active findings | Mitigated | False Positive | Risk Accepted |
+|-------------|----------------:|----------:|---------------:|--------------:|
+| Anchore Grype | 104 | 0 | 0 | 0 |
+| Trivy Scan — Lab 4 | 113 | 0 | 0 | 0 |
+| Semgrep JSON Report | 22 | 0 | 0 | 0 |
+| ZAP Scan | 0 | 0 | 0 | 0 |
+| Checkov Scan | 80 | 0 | 0 | 0 |
+| KICS Scan — Ansible | 10 | 0 | 0 | 0 |
+| KICS Scan — Pulumi | 6 | 0 | 0 | 0 |
+| Trivy Scan — Lab 7 image | 50 | 0 | 0 | 0 |
+| Trivy Operator Scan | 0 | 0 | 0 | 0 |
+| **Total** | **385** | **0** | **0** | **0** |
+
+### Program metrics
+
+- **MTTD**: 0 days for this lab baseline. Findings were detected when scan reports were imported into DefectDojo.
+- **MTTR**: N/A for this run. No findings were fully remediated and closed during the lab execution.
+- **Vuln-age median**: 0 days at import time. This lab created the baseline dataset.
+- **Backlog trend**: Baseline created with 385 active findings. Future runs should compare against this number after remediation and re-import.
+- **SLA compliance**: Baseline established. SLA tracking starts from the DefectDojo finding creation date.
+- **Critical + High backlog**: 181 findings.
+- **Critical + High share of backlog**: approximately 47.0% of all active findings.
+
+### Risk-accepted items
+
+No findings were risk-accepted during this lab run.
+
+| Finding | Severity | Reason | Expiry date |
+|---------|----------|--------|-------------|
+| N/A | N/A | No risk acceptance was used | N/A |
+
+In a real program, every risk-accepted item must have an owner, business justification, and explicit expiry date. Otherwise, risk acceptance becomes a way to hide vulnerabilities instead of managing them.
+
+### Next-quarter goal
+
+Next quarter, I would mature the OWASP SAMM Defect Management practice. This lab already centralized findings from multiple scanners in DefectDojo, but the next step is to make this repeatable in CI/CD: automatically import Grype, Trivy, Semgrep, ZAP, Checkov, KICS, and runtime security outputs after every pipeline run.
+
+A concrete improvement would be to normalize scanner metadata before import, especially CVE/GHSA identifiers and component names. The dedup investigation showed that the same advisory, `GHSA-5mrr-rgp6-x4gr`, appeared across Grype and Trivy outputs but was not automatically collapsed into one DefectDojo finding. Fixing this would improve triage quality, reduce duplicated work, and make SLA tracking more reliable.
+
+---
+
+## Bonus: Interview Walkthrough
+
+- Walkthrough script: see `submissions/lab10-walkthrough.md`
+- Practiced runtime: approximately 5 minutes
+- Two anticipated Q&A questions covered: yes
+- Strongest claim in the script: "I turned separate security scan outputs into a vulnerability management program with centralized tracking, SLA policy, backlog metrics, and deduplication analysis."