Skip to content

feat(lab10): defectdojo governance report + capstone walkthrough #1433

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
chebudelphin wants to merge 1 commit into
base: main
Choose a base branch
from
Open

feat(lab10): defectdojo governance report + capstone walkthrough #1433

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions submissions/lab10-walkthrough.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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.
80 changes: 80 additions & 0 deletions submissions/lab10.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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."