From 871d2fb9cedadd756e4fa1944bba6ba36d08ccce Mon Sep 17 00:00:00 2001 From: m1d0rfeed Date: Thu, 9 Jul 2026 16:13:00 +0300 Subject: [PATCH] docs: add lab 10 DefectDojo report --- submissions/lab10-walkthrough.md | 53 ++++++++++ submissions/lab10.md | 165 +++++++++++++++++++++++++++++++ 2 files changed, 218 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..bb95120f --- /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 an end-to-end DevSecOps program around OWASP Juice Shop. The goal was to connect prevention, build-time analysis, deployment controls, runtime detection and vulnerability governance. + +The final DefectDojo engagement contains 382 raw records. Cross-tool correlation reduced them to 380 canonical findings, and one Low finding entered a time-bound Risk Acceptance, leaving 379 active canonical findings. + +## (0:30–2:00) Security layers + +Before code reaches the repository, Gitleaks prevents secrets from being committed, while SSH-signed commits provide developer-authenticity evidence. + +During the build stage, Syft generates CycloneDX and SPDX SBOMs. Grype and Trivy use those artifacts and the container image to identify vulnerable dependencies. Semgrep adds source-level SAST coverage for injection, unsafe file access, hard-coded credentials and insecure workflow interpolation. + +Before deployment, Checkov and KICS scan Terraform, Ansible and Pulumi. Cosign signs and verifies the image, and policy checks act as a deployment gate. The pipeline therefore evaluates not only whether an image exists, but whether it is trusted and supported by evidence. + +At runtime, Falco provides eBPF-based behavioral detection. Its alerts were retained as evidence. The raw Falco format was not directly compatible with installed DefectDojo parsers, so I documented the limitation rather than claiming a false import. + +DefectDojo aggregates the supported reports into one Product and Engagement and applies targets of 24 hours for Critical, seven days for High, 30 days for Medium and 90 days for Low findings. + +## (2:00–3:00) Findings, correlation and treatment + +The imports produced 17 Critical, 163 High, 166 Medium, 27 Low and nine Informational raw records. + +The strongest correlation example is CVE-2026-5079 in multer 1.4.5-lts.2. It appeared in one Grype result and two Trivy scan sources. Scanner-specific titles and descriptions produced different fingerprints, so automatic deduplication did not merge them. After confirming the same CVE, component and version, I used DefectDojo's native duplicate relationship. Finding 70 is canonical, while Findings 180 and 363 reference it as duplicates. + +I also created one controlled Risk Acceptance for the Low-severity finding “Supply-Chain: Unpinned Package Version.” It is limited to the isolated training environment and expires on September 30, 2026. Expiration reactivates the finding and restarts its SLA. + +## (3:00–4:00) Metrics and governance + +The active canonical backlog is 379 findings: 17 Critical, 161 High, 166 Medium, 26 Low and nine Informational. + +The MTTD proxy is zero days because scan execution and DefectDojo ingestion occurred on the same UTC day. The median age is also zero days because this is the first measurement period. + +MTTR is not measurable because no finding has been marked as mitigated. This vulnerability-remediation metric is not the same as DORA Time to Restore Service, which measures recovery from a production failure. + +The backlog delta is minus three: two records became duplicates and one finding entered Risk Acceptance. All 370 active non-Informational findings remain within SLA deadlines, so current open-backlog compliance is 100 percent. + +## (4:00–4:30) Next steps + +The next-quarter goal is to mature OWASP SAMM Defect Management. I would assign owners, connect findings to remediation tickets, verify fixes through re-imports and calculate real severity-specific MTTR. + +The target is to remediate every Critical finding within 24 hours and every High finding within seven days. I would also normalize Falco output so runtime detections enter the same governance workflow. + +## (4:30–5:00) Q&A anticipation + +### How would you handle Log4Shell? + +I would query the SBOM for log4j-core, validate affected versions with Grype and Trivy, block affected builds, upgrade the dependency, rebuild the image and generate a new SBOM. The replacement image would be signed, pass the policy gate and be re-scanned. DefectDojo would track the canonical finding through remediation. + +### Why did you not use IAST or paid tools? + +The program had to be reproducible locally without licenses or external services. Open-source SCA, SAST, IaC, signing and runtime tools provided broad coverage. IAST would be a useful next step after reliable authenticated integration tests and realistic traffic are available. diff --git a/submissions/lab10.md b/submissions/lab10.md new file mode 100644 index 00000000..908880f5 --- /dev/null +++ b/submissions/lab10.md @@ -0,0 +1,165 @@ +# Lab 10 — Vulnerability Management with DefectDojo + +## Task 1: DefectDojo Setup + Import + +### DefectDojo version + +- Version installed: `2.58.4` +- Deployment: local Docker Compose development environment +- URL: `http://localhost:8080` +- Local development administrator: `admin` +- Local development password: `admin` +- The API token is intentionally excluded from this submission. + +### Product + Engagement + +- Product ID: `1` +- Product name: `OWASP Juice Shop` +- Product type: `Research and Development` +- Engagement ID: `1` +- Engagement name: `Course Semester Run` +- Engagement status: `In Progress` +- Engagement type: `CI/CD` +- Target period: `2026-09-01` — `2026-12-15` + +### Imports completed + +| Lab | Scan type | File | Result | Findings imported | +|-----|-----------|------|--------|------------------:| +| 4 | Anchore Grype | `grype-from-sbom.json` | Successful | 105 | +| 4 | Trivy Scan | `trivy.json` | Successful | 109 | +| 5 | Semgrep JSON Report | `semgrep.json` | Successful | 22 | +| 5 | ZAP Scan | `auth-report.json` | Rejected: this parser expects XML, while the available report is JSON | 0 | +| 6 | Checkov Scan | `checkov-terraform/results_json.json` | Successful | 80 | +| 6 | KICS Scan | `kics-ansible/results.json` | Successful | 10 | +| 6 | KICS Scan | `kics-pulumi/results.json` | Successful | 6 | +| 7 | Trivy Scan | `trivy-image.json` | Successful | 50 | +| 7 | Trivy Operator Scan | `trivy-k8s.json` | Successful, valid empty result | 0 | +| 8 | Cosign verification | `verify-original.json` | Evidence artifact, not a vulnerability-report format | 0 | +| 9 | Falco runtime alerts | `falco/logs/falco.log` | Custom format; documented instead of imported | 0 | +| **Total raw findings** | | | | **382** | +| **After cross-tool deduplication** | | | | **380 canonical findings** | +| **Active after risk acceptance** | | | | **379** | + +Six distinct DefectDojo scan types were successfully exercised: + +1. Anchore Grype +2. Trivy Scan +3. Semgrep JSON Report +4. Checkov Scan +5. KICS Scan +6. Trivy Operator Scan + +The ZAP JSON report was preserved but not misrepresented as a successful import. The installed `ZAP Scan` parser expects an XML report. The Lab 8 Cosign output is supply-chain verification evidence rather than a vulnerability scan. The Lab 9 Falco log requires a custom parser or normalized intermediary format. + +### Dedup example + +A concrete cross-tool correlation was completed for: + +- CVE: `CVE-2026-5079` +- Affected component: `multer 1.4.5-lts.2` +- Number of source scans: `3` — Anchore Grype, Trivy Lab 4 and Trivy image Lab 7 +- Scanner families: `2` — Grype and Trivy +- Canonical DefectDojo Finding ID: `70` +- Duplicate Finding IDs: `180`, `363` + +Source records: + +| Finding ID | Scanner/source | Final status | +|-----------:|----------------|--------------| +| 70 | Anchore Grype, Lab 4 SBOM scan | Canonical finding | +| 180 | Trivy Scan, Lab 4 scan | Duplicate of Finding 70 | +| 363 | Trivy Scan, Lab 7 image scan | Duplicate of Finding 70 | + +DefectDojo's automatic scanner-specific fingerprinting did not initially merge these records because Grype and Trivy produced different titles, descriptions and hash inputs. After confirming that the CVE, package and affected version represented the same underlying issue, the records were correlated through DefectDojo's native duplicate relationship. Findings 180 and 363 are inactive and reference Finding 70 through `duplicate_finding`. + +## Task 2: Governance Report + +### Executive Summary + +OWASP Juice Shop was assessed through six successfully exercised DefectDojo scan types, producing 382 raw finding records and 380 canonical findings after cross-tool correlation. The current active canonical backlog is 379 findings, including 17 Critical and 161 High findings. No finding has yet been recorded as mitigated, so remediation-based MTTR and closed-finding SLA performance are not measurable; however, all 370 active non-Informational findings currently remain within their assigned SLA deadlines. + +### Findings by severity — active canonical findings + +| Severity | Count | +|----------|------:| +| Critical | 17 | +| High | 161 | +| Medium | 166 | +| Low | 26 | +| Info | 9 | +| **Total** | **379** | + +### Findings by source tool + +Counts below exclude records marked as duplicates. + +| Tool | Active | Mitigated | False Positive | Risk Accepted | Canonical total | +|------|-------:|----------:|---------------:|--------------:|----------------:| +| Anchore Grype | 105 | 0 | 0 | 0 | 105 | +| Trivy Scan | 157 | 0 | 0 | 0 | 157 | +| Semgrep JSON Report | 22 | 0 | 0 | 0 | 22 | +| Checkov Scan | 80 | 0 | 0 | 0 | 80 | +| KICS Scan | 15 | 0 | 0 | 1 | 16 | +| Trivy Operator Scan | 0 | 0 | 0 | 0 | 0 | +| **Total** | **379** | **0** | **0** | **1** | **380** | + +### Program metrics + +- **MTTD proxy:** `0 days` + - Finding dates and the corresponding scanner Test execution occurred on the same UTC day. + - This measures ingestion latency in the laboratory, not the age of vulnerabilities before scanning. +- **MTTR:** `N/A` + - There are currently zero findings with `is_mitigated=true`. + - Duplicate correlation and Risk Acceptance are not counted as remediation. + - Because no remediation events have been recorded, vulnerability-remediation MTTR cannot yet be calculated. This metric is not the same as DORA Time to Restore Service, which measures recovery from a production failure. +- **Vulnerability-age median for active findings:** `0 days` + - Findings were imported and measured on the same day. +- **Raw import baseline:** `382 records` +- **Current active canonical backlog:** `379 findings` +- **Backlog delta:** `-3` + - Two records became duplicates. + - One Low finding was placed under a time-bound Risk Acceptance. +- **SLA-eligible active findings:** `370` + - Informational findings are excluded. +- **Within current SLA deadline:** `370` +- **SLA breached:** `0` +- **Current open-backlog SLA compliance:** `100%` +- **Closed-finding SLA compliance:** `N/A` + - There are no completed remediation events yet. + +Applied SLA matrix: + +| Severity | Remediation target | +|----------|-------------------:| +| Critical | 24 hours | +| High | 7 days | +| Medium | 30 days | +| Low | 90 days | + +### Risk-accepted items + +| Finding | ID | Severity | Source | Reason | Expiry date | +|---------|---:|----------|--------|--------|-------------| +| Supply-Chain: Unpinned Package Version | 326 | Low | KICS Scan | Temporarily accepted for the isolated and ephemeral local training environment. It contains no production data and is not operated as a production service. The finding must be reviewed during the next IaC hardening iteration. | 2026-09-30 | + +Risk Acceptance details: + +- Risk Acceptance ID: `1` +- Decision: Accept +- Security recommendation: Mitigate +- Reactivate finding after expiration: enabled +- Restart SLA after expiration: enabled +- All risk-accepted findings have an explicit expiration date. + +### Next-quarter goal — OWASP SAMM Defect Management + +The next-quarter priority is to mature the OWASP SAMM **Implementation / Defect Management** practice. The current program aggregates and prioritizes findings, but it has 379 active findings and zero recorded remediations, leaving MTTR unmeasurable. The next maturity step is to assign owners, create severity-based remediation tickets, verify fixes through re-imports, and target closure of every Critical finding within 24 hours and every High finding within seven days. + +## Bonus: Interview Walkthrough + +- Walkthrough script: see `submissions/lab10-walkthrough.md` +- Estimated runtime from word count: approximately `4:20–4:50` +- Practiced read-aloud runtime: `4:36` +- Two anticipated Q&A questions covered: yes +- Strongest claim: “I converted 382 scanner records into a governed backlog with cross-tool correlation, explicit SLA deadlines and expiring risk acceptance rather than treating every scanner result as an independent vulnerability.”