|
| 1 | +# WrongSecrets Challenge Roadmap (Post-62) |
| 2 | + |
| 3 | +This roadmap proposes new challenges that complement existing coverage in WrongSecrets. |
| 4 | + |
| 5 | +Goal: |
| 6 | +- Add realistic, high-impact secrets misuse cases that are common in modern SDLCs. |
| 7 | +- Keep challenges educational, reproducible, and aligned with current project patterns. |
| 8 | +- Implement incrementally and co-create each challenge from design to tests. |
| 9 | + |
| 10 | +## Guiding Principles |
| 11 | + |
| 12 | +- Favor real-world attack paths over contrived puzzles. |
| 13 | +- Reuse existing patterns: `FixedAnswerChallenge` for static answers, `Challenge` for dynamic behavior. |
| 14 | +- Keep challenge runtime support explicit (Docker first, then K8s/Cloud where relevant). |
| 15 | +- Add tests and explanation/hint/reason files with each challenge. |
| 16 | +- Avoid duplicate coverage with existing challenges (0-62). |
| 17 | + |
| 18 | +## Proposed Backlog (Candidate Challenges 63-72) |
| 19 | + |
| 20 | +## Phase 1: Quick Wins (High Value, Lower Complexity) |
| 21 | + |
| 22 | +1. Challenge 63: CI Artifact Secret Leak |
| 23 | +- Misuse: CI workflow uploads artifacts containing `.env` or test output with credentials. |
| 24 | +- Learner path: inspect CI artifacts/logs and extract secret. |
| 25 | +- Suggested category: CI/CD. |
| 26 | +- Runtime: Docker. |
| 27 | +- Why now: very common in GitHub Actions and easy to teach. |
| 28 | + |
| 29 | +2. Challenge 64: Package Manager Token in Config |
| 30 | +- Misuse: leaked registry credentials in `.npmrc` / `settings.xml` / similar config. |
| 31 | +- Learner path: inspect repo/build config for token-bearing auth stanza. |
| 32 | +- Suggested category: CI/CD or Intro. |
| 33 | +- Runtime: Docker. |
| 34 | +- Why now: widespread and highly actionable for attackers. |
| 35 | + |
| 36 | +3. Challenge 65: Frontend Source Map Exposure |
| 37 | +- Misuse: production sourcemap reveals API keys/internal endpoints. |
| 38 | +- Learner path: retrieve source map, inspect reconstructed source, find secret. |
| 39 | +- Suggested category: Front-end. |
| 40 | +- Runtime: Docker. |
| 41 | +- Why now: complements existing frontend challenges with a distinct failure mode. |
| 42 | + |
| 43 | +4. Challenge 66: OAuth Refresh Token Stored Insecurely |
| 44 | +- Misuse: long-lived refresh token persisted in browser storage. |
| 45 | +- Learner path: inspect storage/exported session artifacts and recover token. |
| 46 | +- Suggested category: Front-end/Auth. |
| 47 | +- Runtime: Docker. |
| 48 | +- Why now: common in SPA implementations. |
| 49 | + |
| 50 | +## Phase 2: Cloud and Platform Depth |
| 51 | + |
| 52 | +5. Challenge 67: Over-Permissive Signed URL/SAS Token |
| 53 | +- Misuse: leaked signed URL with broad scope and long TTL. |
| 54 | +- Learner path: find URL in logs/docs/chat mock and use it to retrieve secret object. |
| 55 | +- Suggested category: Cloud. |
| 56 | +- Runtime: Docker + optional cloud variant. |
| 57 | +- Why now: modern cloud-heavy teams often misuse signed links. |
| 58 | + |
| 59 | +6. Challenge 68: Terraform State Leakage |
| 60 | +- Misuse: secrets exposed in `tfstate` or plan output. |
| 61 | +- Learner path: discover state file or CI plan log and extract secret. |
| 62 | +- Suggested category: Terraform. |
| 63 | +- Runtime: Docker/Cloud. |
| 64 | +- Why now: high prevalence in IaC workflows. |
| 65 | + |
| 66 | +7. Challenge 69: K8s ServiceAccount Token to RBAC Escalation |
| 67 | +- Misuse: mounted SA token plus overbroad RBAC allows secret listing. |
| 68 | +- Learner path: use in-cluster token to query API and enumerate secrets. |
| 69 | +- Suggested category: Kubernetes/Secrets. |
| 70 | +- Runtime: K8s. |
| 71 | +- Why now: teaches realistic post-compromise movement. |
| 72 | + |
| 73 | +## Phase 3: Advanced Operational Pitfalls |
| 74 | + |
| 75 | +8. Challenge 70: Backup/Snapshot Exposure |
| 76 | +- Misuse: backup dump or snapshot in accessible storage contains credentials. |
| 77 | +- Learner path: find backup artifact and recover secret from dump. |
| 78 | +- Suggested category: Operations. |
| 79 | +- Runtime: Docker + optional cloud variant. |
| 80 | +- Why now: backup hygiene is a major blind spot. |
| 81 | + |
| 82 | +9. Challenge 71: Observability Pipeline Secret Exfiltration |
| 83 | +- Misuse: logs/traces export auth headers/env vars to telemetry backend. |
| 84 | +- Learner path: inspect mock telemetry payloads/index and recover secret. |
| 85 | +- Suggested category: Logging. |
| 86 | +- Runtime: Docker. |
| 87 | +- Why now: aligns with modern APM/OTel adoption. |
| 88 | + |
| 89 | +10. Challenge 72: KMS Misuse Despite Encryption At Rest |
| 90 | +- Misuse: static data key and broad decrypt permissions undermine KMS controls. |
| 91 | +- Learner path: combine exposed config/IAM assumptions to decrypt protected value. |
| 92 | +- Suggested category: Cryptography/IAM. |
| 93 | +- Runtime: Docker + cloud variant. |
| 94 | +- Why now: teaches that "using KMS" alone is not enough. |
| 95 | + |
| 96 | +## Prioritization Matrix |
| 97 | + |
| 98 | +- Highest implementation priority: |
| 99 | + - 63 CI Artifact Secret Leak |
| 100 | + - 64 Package Manager Token in Config |
| 101 | + - 65 Frontend Source Map Exposure |
| 102 | + - 68 Terraform State Leakage |
| 103 | +- Highest educational impact for advanced learners: |
| 104 | + - 69 K8s SA Token + RBAC Escalation |
| 105 | + - 71 Observability Exfiltration |
| 106 | + - 72 KMS Misuse |
| 107 | + |
| 108 | +## Suggested Delivery Order |
| 109 | + |
| 110 | +1. 63 CI Artifact Secret Leak |
| 111 | +2. 64 Package Manager Token in Config |
| 112 | +3. 65 Frontend Source Map Exposure |
| 113 | +4. 68 Terraform State Leakage |
| 114 | +5. 66 OAuth Refresh Token Stored Insecurely |
| 115 | +6. 69 K8s SA Token + RBAC Escalation |
| 116 | +7. 67 Over-Permissive Signed URL/SAS Token |
| 117 | +8. 70 Backup/Snapshot Exposure |
| 118 | +9. 71 Observability Pipeline Exfiltration |
| 119 | +10. 72 KMS Misuse |
| 120 | + |
| 121 | +Reasoning: |
| 122 | +- Start with Docker-first challenges that are easy to test and review. |
| 123 | +- Introduce platform-specific complexity after establishing momentum. |
| 124 | +- End with deep cloud/KMS design pitfalls. |
| 125 | + |
| 126 | +## Per-Challenge Implementation Checklist |
| 127 | + |
| 128 | +For each challenge N: |
| 129 | + |
| 130 | +1. Design |
| 131 | +- Define exact misuse pattern and attacker path. |
| 132 | +- Define expected answer and solvability constraints. |
| 133 | +- Decide `FixedAnswerChallenge` vs `Challenge`. |
| 134 | +- Select supported runtime environments. |
| 135 | + |
| 136 | +2. Code |
| 137 | +- Add challenge class under the appropriate package: |
| 138 | + - `src/main/java/org/owasp/wrongsecrets/challenges/docker/` |
| 139 | + - `src/main/java/org/owasp/wrongsecrets/challenges/kubernetes/` |
| 140 | + - `src/main/java/org/owasp/wrongsecrets/challenges/cloud/` |
| 141 | +- Add any support components/controllers if needed. |
| 142 | + |
| 143 | +3. Metadata and Content |
| 144 | +- Register challenge in `src/main/resources/wrong-secrets-configuration.yaml`. |
| 145 | +- Add explanation files: |
| 146 | + - `src/main/resources/explanations/challengeN.adoc` |
| 147 | + - `src/main/resources/explanations/challengeN_hint.adoc` |
| 148 | + - `src/main/resources/explanations/challengeN_reason.adoc` |
| 149 | + |
| 150 | +4. Tests |
| 151 | +- Add unit test mirroring current naming patterns: |
| 152 | + - `src/test/java/.../ChallengeNTest.java` |
| 153 | +- Add integration tests only when challenge behavior needs endpoint or environment integration. |
| 154 | + |
| 155 | +5. Validation |
| 156 | +- Run focused tests for challenge N. |
| 157 | +- Run broader suite if challenge touches shared code paths. |
| 158 | +- Ensure CTF behavior and environment gating are correct. |
| 159 | + |
| 160 | +6. Documentation |
| 161 | +- Update README challenge availability lists if environment-specific. |
| 162 | +- Add setup docs if external services are needed. |
| 163 | + |
| 164 | +## Definition of Done (Per Challenge) |
| 165 | + |
| 166 | +- Challenge implementation merged with tests passing. |
| 167 | +- Explanation, hint, and reason files present and review-ready. |
| 168 | +- Registered in challenge configuration and visible in UI. |
| 169 | +- No regressions in existing challenge behavior. |
| 170 | +- Security educational intent clearly stated in explanation/reason. |
| 171 | + |
| 172 | +## Co-Creation Workflow (1 by 1) |
| 173 | + |
| 174 | +For each new challenge we will do: |
| 175 | + |
| 176 | +1. Confirm scope in one short design pass. |
| 177 | +2. Implement minimal viable challenge. |
| 178 | +3. Add tests and explanation/hint/reason. |
| 179 | +4. Validate behavior in the intended environment. |
| 180 | +5. Refine difficulty and hints based on review feedback. |
| 181 | + |
| 182 | +## First Candidate To Build Next |
| 183 | + |
| 184 | +Start with Challenge 63 (CI Artifact Secret Leak). |
| 185 | + |
| 186 | +Why: |
| 187 | +- High relevance. |
| 188 | +- Low infra overhead. |
| 189 | +- Fast feedback loop for design and testing. |
| 190 | + |
| 191 | +--- |
| 192 | + |
| 193 | +If this roadmap is approved, we can start immediately with Challenge 63 design and implementation in the next iteration. |
0 commit comments