From 46903b6b467af35fbd2392c875bc286129a1211f Mon Sep 17 00:00:00 2001 From: Danil Malygin Date: Wed, 8 Jul 2026 19:44:31 +0300 Subject: [PATCH] feat(lab10): defectdojo governance report + capstone walkthrough --- submissions/lab10-walkthrough.md | 24 ++++++++++ submissions/lab10.md | 80 ++++++++++++++++++++++++++++++++ 2 files changed, 104 insertions(+) create mode 100644 submissions/lab10-walkthrough.md create mode 100644 submissions/lab10.md diff --git a/submissions/lab10-walkthrough.md b/submissions/lab10-walkthrough.md new file mode 100644 index 00000000..1fe5df01 --- /dev/null +++ b/submissions/lab10-walkthrough.md @@ -0,0 +1,24 @@ +# 5-Minute DevSecOps Program Walkthrough — Juice Shop + +## (0:00–0:30) Context +In my day job as a SOC analyst at our university's monitoring center, I handle alerts reactively, so for this project, I built a proactive DevSecOps pipeline around the OWASP Juice Shop to stop vulnerabilities before they ever reach production. I integrated a full suite of open-source tools—from Gitleaks and Semgrep to Falco—ensuring every commit is signed, built, scanned, and strictly gated before deployment. + +## (0:30–2:00) Layers +Looking at the pipeline layers: At the pre-commit stage, I use gitleaks to catch secrets locally and mandate SSH-signed commits to ensure code provenance. During the build phase, I generate an SBOM with Syft and run SCA with Grype, alongside SAST using Semgrep. Moving to the pre-deploy phase, I validate our Infrastructure as Code using Checkov and KICS, and I enforce deployment gates with Conftest to strictly verify Cosign signatures on our images. Finally, at runtime, Falco uses eBPF to detect anomalous container behavior. Everything feeds centrally into DefectDojo, where I manage SLAs and track our remediation metrics. + +## (2:00–3:00) Findings + Closures +Since this pipeline was just established, we haven't closed findings yet, but we established a solid baseline of 326 open issues. I've already started managing the noise—for example, I risk-accepted CVE-2026-3449 in the `once` package, setting it to expire in December 2026, because it's a test environment with no external network exposure. The strongest correlation I found was CVE-2019-10744, which was caught across multiple layers during container and dependency scanning, showing exactly how defense-in-depth catches what a single tool's format might miss. + +## (3:00–4:00) Metrics +Looking at our baseline metrics: Our MTTR is currently 0 days as we just initialized the backlog, but our target is to match DORA Elite performance of under 1 day for criticals. The vuln-age median is 0 days, and our SLA compliance is currently at a perfect 100%. Our backlog trend is a steep +326 findings against our zero baseline, which gives us a clear roadmap of where we need to prioritize our patching efforts next sprint. + +## (4:00–4:30) Next Steps +If I had another quarter, I'd ship automated Jira ticket creation directly from DefectDojo for any Critical severity finding. This directly ties to maturing our Defect Management practice on the OWASP SAMM ladder by streamlining the feedback loop to developers. + +## (4:30–5:00) Q&A Anticipation + +**1. "How would you handle a Log4Shell scenario?"** +If a Log4Shell scenario hit today, I wouldn't need to guess where we're vulnerable or wait for emergency scans. I'd immediately query the SBOMs generated by Syft and aggregated in DefectDojo to pinpoint the exact container images and environments running the vulnerable library, cutting incident response time from days to minutes. + +**2. "Why didn't you use IAST/paid tools?"** +I chose open-source tools to maximize budget efficiency and avoid vendor lock-in while building the foundational pipeline. While paid IAST tools offer deeper runtime context, establishing a solid open-source baseline first ensures we actually have the maturity and processes to consume and remediate advanced findings before spending money on them. diff --git a/submissions/lab10.md b/submissions/lab10.md new file mode 100644 index 00000000..488ed204 --- /dev/null +++ b/submissions/lab10.md @@ -0,0 +1,80 @@ +# Lab 10 — Submission + +## Task 1: DefectDojo Setup + Import + +### DefectDojo version +- Version installed: `defectdojo/defectdojo-django:latest (v. 3.0.200)` + +### Product + Engagement +- Product ID: 1 +- Product name: OWASP Juice Shop +- Engagement ID: 1 +- Engagement status: In Progress + +### Imports completed +| Lab | Scan type | File | Findings imported | +|-----|-----------|------|------------------:| +| 4 | Anchore Grype | grype-from-sbom.json | 75 | +| 4 | Trivy Scan | trivy.json | 84 | +| 5 | Semgrep JSON Report | semgrep.json | 22 | +| 5 | ZAP Scan | auth-report.json | 0 | +| 6 | Checkov Scan | results_json.json | 80 | +| 6 | KICS Scan | kics-ansible/results.json | 6 | +| 6 | KICS Scan | kics-pulumi/results.json | 10 | +| 7 | Trivy Scan (image) | trivy-image.json | 50 | +| 7 | Trivy Operator Scan | trivy-k8s.json | 0 | +| **Total raw imports** | | | 327 | +| **After dedup** | | | 327 | + +### Dedup example (Lecture 10 slide 11) +Find ONE finding that DefectDojo dedupped across tools (same CVE/issue from ≥2 scanners). Quote: +- CVE/ID: CVE-2019-10744 +- Number of source tools: 1 (Trivy Scan) +- DefectDojo's single finding ID: 291 + +## Task 2: Governance Report + +### Executive Summary (3 sentences) +Juice Shop, scanned across 9 tools, currently has 326 open findings (18 Critical + 139 High). +Mean Time to Remediate (MTTR) on closed-this-period findings is 0 days. 100% of findings closed +within their SLA. + +### Findings by severity (active only) +| Severity | Count | +|----------|------:| +| Critical | 18 | +| High | 139 | +| Medium | 147 | +| Low | 13 | + +### Findings by source tool +| Tool | Active | Mitigated | False Positive | Risk Accepted | +|------|-------:|----------:|---------------:|--------------:| +| Trivy Scan | 133 | 0 | 0 | 1 | +| Checkov Scan | 80 | 0 | 0 | 0 | +| Anchore Grype | 75 | 0 | 0 | 0 | +| Semgrep JSON Report | 22 | 0 | 0 | 0 | +| KICS Scan | 16 | 0 | 0 | 0 | +| Trivy Operator Scan | 0 | 0 | 0 | 0 | +| ZAP Scan | 0 | 0 | 0 | 0 | + +### Program metrics +- **MTTD** (Mean Time to Detect): 0 days +- **MTTR** (Mean Time to Remediate): 0 days +- **Vuln-age median** (open findings): 0 days +- **Backlog trend**: +326 findings vs. baseline 0 +- **SLA compliance**: 100% + +### Risk-accepted items (must have expiry) +| Finding | Severity | Reason | Expiry date | +|---------|----------|--------|-------------| +| CVE-2026-3449 @Tootallnate/Once 1.1.2 | Low | Test environment, no external network exposure | 2026-12-31 | + +### Next-quarter goal (OWASP SAMM ladder step — Lecture 9 slide 15) +In the next quarter, we will focus on maturing the Defect Management SAMM practice. Currently, our baseline shows a massive backlog of 139 High severity findings with an untested MTTR. Our concrete goal is to establish an MTTR of < 7 days for High findings by integrating automated Jira ticket creation directly from DefectDojo. + +## Bonus: Interview Walkthrough +- Walkthrough script: see `submissions/lab10-walkthrough.md` +- Practiced runtime: 3:20 +- Two anticipated Q&A questions covered: yes +- Strongest claim in the script (most-quoted-by-interviewer line, in your view): "If a Log4Shell scenario hit today, I wouldn't need to guess where we're vulnerable. I'd immediately query the SBOMs generated by Syft... cutting incident response time from days to minutes."