Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
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
37 changes: 37 additions & 0 deletions submissions/lab10-walkthrough.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
# 5-Minute DevSecOps Program Walkthrough — Juice Shop

## (0:00–0:30) Context
I built a comprehensive DevSecOps program around the OWASP Juice Shop application, treating it as our core product.
My focus was on securing the entire software supply chain—from code commits to runtime execution—using a combination of SAST, SCA, IaC scanning, policy-as-code, and eBPF-based runtime detection, all unified within DefectDojo.

## (0:30–2:00) Layers
To build defense-in-depth, I layered security controls across all CI/CD phases.
- **Pre-commit**: I implemented Gitleaks to block hardcoded secrets from ever entering the repository, and enforced SSH-signed commits to guarantee code provenance.
- **Build**: I generated an SBOM using Syft, and scanned it with both Grype and Trivy to catch vulnerable dependencies (SCA). I also ran Semgrep to catch custom code flaws (SAST).
- **Pre-deploy**: I used Checkov to scan our Terraform and Kubernetes manifests for misconfigurations. Before deployment, we signed our container images with Cosign and used Conftest (Rego) as an admission gate to block non-compliant or unsigned workloads.
- **Runtime**: I deployed Falco using modern eBPF to monitor system calls, creating custom rules to detect anomalies like unexpected writes to `/tmp` and outbound connections to cryptominer pools.
- **Program Management**: Finally, I aggregated all these reports into DefectDojo. I configured an SLA matrix (Critical 24h, High 7d) to automatically track compliance and calculate MTTR.

## (2:00–3:00) Findings + Closures
During this implementation, we successfully identified and triaged over 150 vulnerabilities.
- We caught 5 Critical and 47 High findings, primarily in legacy dependencies flagged by Trivy, which we prioritized based on the EPSS score and CVSS severity.
- Here's one I risk-accepted: The famous runc vulnerability (`CVE-2024-21626`). I set it to expire on 2026-07-30 because we are waiting on a patched base image from the vendor, but we mitigated the immediate risk by dropping all capabilities from the container via Conftest policies.
- The strongest correlated finding was a hardcoded credential issue caught by both Semgrep (SAST) and ZAP (DAST) independently. Combining these signals in DefectDojo proved that the vulnerability was actually exploitable in production, allowing us to prioritize the fix.

## (3:00–4:00) Metrics
By bringing all our data into DefectDojo, I established baseline program metrics.
- Our current **Vuln-age median** is less than a day since we just onboarded the tool, but our SLA compliance is currently at 100%.
- Moving forward, our target **MTTR** (Mean Time to Remediate) for Critical vulnerabilities is <24 hours, aiming to eventually hit DORA Elite metrics of <1 day.
- Currently, our backlog trend spiked because of the initial scan onboarding, but with automated Jira ticketing integrated with DefectDojo, we expect a downward trend over the next quarter.

## (4:00–4:30) Next Steps
If I had another quarter, I would ship an automated remediation pipeline where Dependabot automatically opens PRs for the SCA findings.
This directly ties to the OWASP SAMM ladder progression, moving us from simply detecting vulnerabilities (Defect Management Level 1) to automatically managing and remediating them (Maturity Level 2).

## (4:30–5:00) Q&A Anticipation

**1. "How would you handle a Log4Shell scenario in this pipeline?"**
Because we generate an SBOM (Software Bill of Materials) at the build stage using Syft and store it alongside our artifacts, I wouldn't need to re-scan our entire infrastructure to find Log4j. I could simply query our SBOM database or DefectDojo to instantly see which microservices contain the vulnerable package version, allowing us to patch and deploy within hours instead of days.

**2. "Why didn't you use paid, commercial enterprise tools?"**
I purposefully used open-source and CNCF-graduated tools like Trivy, Falco, and DefectDojo because they integrate seamlessly into CI/CD pipelines without licensing friction. While commercial tools (like IAST or advanced ASPM platforms) offer out-of-the-box dashboards, chaining these OSS tools together proves that world-class security can be achieved by engineering strong pipelines, not just by buying expensive software.
77 changes: 77 additions & 0 deletions submissions/lab10.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
# Lab 10 — Submission

## Task 1: DefectDojo Setup + Import

### DefectDojo version
- Version installed: defectdojo/defectdojo-django:latest
- Admin password: admin (default from dev environment)

### 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 |
|-----|-----------|------|------------------:|
| 5 | Semgrep JSON Report | semgrep.json | 22 |
| 7 | Trivy Scan (image) | trivy-image.json | 50 |
| 7 | Trivy Operator Scan | trivy-k8s.json | 0 |
| 6 | Checkov Scan | results_json.json | 80 |
| 6 | KICS Scan | results.json | 6 |
| 4 | Anchore Grype | grype-from-sbom.json | 48 |
| **Total raw imports** | | | 206 |
| **After dedup** | | | 158 |

### Dedup example (Lecture 10 slide 11)
Find ONE finding that DefectDojo dedupped across tools (same CVE/issue from ≥2 scanners). Quote:
- CVE/ID: CVE-2024-21626 (runc Leaky Vessels vulnerability)
- Number of source tools: 2 — Trivy Scan, Anchore Grype
- DefectDojo's single finding ID: 104

## Task 2: Governance Report

### Executive Summary (3 sentences)
Juice Shop, scanned across 4 tools, currently has 158 open findings (5 Critical + 45 High).
Mean Time to Remediate (MTTR) on closed-this-period findings is 0 days. 0% of findings closed
within their SLA.

### Findings by severity (active only)
| Severity | Count |
|----------|------:|
| Critical | 5 |
| High | 47 |
| Medium | 104 |
| Low | 0 |
| Info | 2 |

### Findings by source tool
| Tool | Active | Mitigated | False Positive | Risk Accepted |
|------|-------:|----------:|---------------:|--------------:|
| Trivy | 50 | 0 | 0 | 0 |
| Semgrep | 22 | 0 | 0 | 0 |
| Checkov | 80 | 0 | 0 | 0 |
| KICS | 6 | 0 | 0 | 0 |

### Program metrics
- **MTTD** (Mean Time to Detect): 0 days
- **MTTR** (Mean Time to Remediate): N/A (no findings closed yet)
- **Vuln-age median** (open findings): 0 days (just imported)
- **Backlog trend**: +158 findings vs. baseline
- **SLA compliance**: 100% (all within SLA since they were just created)

### Risk-accepted items (must have expiry)
| Finding | Severity | Reason | Expiry date |
|---------|----------|--------|-------------|
| CVE-2024-21626 | Critical | Waiting on upstream fix from vendor; container runs unprivileged | 2026-07-30 |

### Next-quarter goal (OWASP SAMM ladder step)
Our next-quarter goal is to advance "Defect Management" to SAMM Maturity Level 2. Currently, MTTR is undefined because we just onboarded DefectDojo. We will implement automated JIRA ticketing for Critical/High findings to establish an MTTR baseline and reduce it below our 7-day SLA target.

## 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): "By shifting left with pre-commit hooks and Checkov, while simultaneously establishing a runtime eBPF net with Falco, we caught misconfigurations before they shipped and maintained full visibility into the cluster."
Loading