Roadmap
Use one core operating method across all scopes, then develop each platform's security model. Equal coverage in a reference manual does not mean investigating eleven target families simultaneously. The proposed schedule is a 24-week breadth cycle at roughly 8–12 focused hours per week, followed by a specialization cycle. It is a planning estimate, not a mastery or income forecast; stretch device and native-code phases when their prerequisites require it.
Common prerequisites#
For an experienced engineer, test these prerequisites through tasks instead of restarting generic programming courses. You should be able to inspect raw HTTP and TLS behavior, trace a request across middleware and a datastore, explain authentication versus authorization, use Git and a debugger, read unfamiliar code with a hypothesis, and reproduce a failure in an isolated environment. Native-code work adds memory layout and debugging; cloud adds IAM evaluation; Web3 adds transaction semantics and financial invariants; hardware adds electronics and physical access constraints.
| Capability | Demonstration | If blocked |
|---|---|---|
| HTTP and sessions | Explain each request, token, redirect, cookie, and origin in a login workflow | Work through authentication and access-control labs |
| Source reasoning | Trace one attacker-controlled value to a privileged operation and identify all guards | Review a small open-source handler and its tests in a local copy |
| Evidence handling | Reproduce a bug after a clean reset using written steps alone | Replace screenshots-only notes with inputs, versions, and expected/actual results |
| Boundary thinking | Write an actor × action × resource × state matrix | Draw the data ownership model before selecting payloads |
| Scope handling | Distinguish an owned app from its external identity provider and hosting infrastructure | Complete the scope record before sending test traffic |
PortSwigger offers interactive web security labs; OWASP Juice Shop and crAPI provide intentionally vulnerable application environments. Use their published practice environments or your own isolated deployment, and do not infer permission for unrelated demo services. Web Security Academy, OWASP Juice Shop, OWASP crAPI.
The 24-week cycle#
| Weeks | Focus | Concrete work | Exit gate |
|---|---|---|---|
| 1–2 | Scope, lab, evidence, reporting | Complete two policy reviews; create isolated working environments; write a report from a lab finding | Another person could reproduce the lab report without a call |
| 3–4 | OSS and self-hosted applications | Build an eligible release; map routes and jobs; follow three source-to-sink hypotheses; reproduce one historical fixed bug locally | Explain the root cause, required deployment conditions, vulnerable range, and fix |
| 5–6 | Web, API and network | Map a permitted application; use two accounts and tenants; compare REST/GraphQL/WebSocket paths and relevant service configuration | Finish a coverage matrix that distinguishes tested, blocked, and untested behavior |
| 7–8 | Mobile | Analyze Android and iOS artifacts; map deep links, IPC, storage, network trust, and backend dependencies | Demonstrate one local boundary failure or a well-supported negative result on a release-relevant setup |
| 9–10 | Desktop and browser extensions | Map privileged helpers, IPC, updater trust, extension messages, and untrusted documents | Separate user-level behavior from a genuine cross-process or privilege boundary |
| 11–12 | Cloud and containers | Use a dedicated lab account; model IAM and tenant identities; inspect storage, workload identity, and Kubernetes authorization | Prove what each principal can access and identify the exact policy or application decision responsible |
| 13–14 | AI, agents and MCP | Build a synthetic multi-tenant RAG/tool scenario; map content trust and tool authority; pin protocol versions | Show a prohibited data or action boundary with complete traces and controls |
| 15–16 | Web3 | Learn the chosen chain/toolchain; run a local fork; write accounting, access, and signature invariants | Produce a deterministic local test with exact block/address/source alignment |
| 17–18 | Hardware, firmware and embedded | Use an owned device or permitted firmware artifact; map boot/update/data paths and physical assumptions | Reproduce a trust failure without changing unrelated devices or production services |
| 19–20 | Supply chain and cross-surface chains | Trace source→build→package→runtime; connect a client input to its backend authorization; analyze one patch | Explain each boundary in a chain without silently extending scope |
| 21–22 | Live investigation sprint | Pick one eligible primary program plus one fallback; pursue the highest-value bounded hypotheses | Submit only if evidence clears the reporting gate; otherwise preserve disproven hypotheses and blockers |
| 23–24 | Triage, retest and specialization | Respond to questions, reproduce fixes where invited, review research efficiency, select the next deep branch | A sustainable backlog and a decision to continue, rotate, or pause each target |
Do not treat completing a lab exploit as permission to try the same procedure against production. A lab proves a technique can work under known conditions; a bounty finding must establish applicable conditions on the eligible asset.
Scope-specific learning ladders#
| Branch | Foundation | Intermediate | Advanced research | Durable output |
|---|---|---|---|---|
| OSS/self-hosted | Build system, versions, security policy | Data flow, auth gates, parsers, config | Variant analysis, cross-package reachability, fuzz harnesses | Reproducible source-linked PoC |
| Web/API/network | HTTP, DNS, TLS, identity | Object/property/function authorization, workflows | Cross-protocol state, cache boundaries, parsing discrepancies | Auth matrix and minimal request sequence |
| Mobile | Package identity, sandbox, lifecycle | Exported components, deep links, storage, trust | Native surfaces, cross-app chains, platform-version differences | Artifact hashes and device reproduction |
| Desktop/extensions | Process identity, files, ACLs | IPC, helpers, extension messages, updates | Sandbox escapes, unsafe document parsing, trust transitions | Lower-privilege-to-higher-privilege evidence |
| Cloud/containers | IAM and resource hierarchy | Cross-account/tenant policies, workload identity | Delegation chains, controller trust, isolation | Principal/action/resource decision record |
| AI/MCP | Model, retrieval, tools, identities | Direct/indirect injection, connector authorization | Multi-step authority confusion, model artifacts, state boundaries | Synthetic canary and tool trace |
| Web3 | Chain execution, Solidity or ecosystem language | Invariants, math, signatures, proxies | Economic state interactions, bridges, upgrade safety | Forked test and before/after balances |
| Hardware/firmware | Electronics, firmware layout, serial interfaces | Boot/update/auth/storage and protocol state | Trust chain failure, native parsing, cross-device boundaries | Revision-specific non-destructive reproduction |
This ladder is a capability model. Hardware, browser engines, operating-system kernels, cryptographic implementations, industrial control, vehicles, and distributed consensus can require much longer specialist preparation. Scope breadth is not a reason to skip those prerequisites.
A weekly operating rhythm#
Use approximately two 90-minute learning/reproduction sessions, two 2-hour target sessions, one 90-minute evidence and report session, and a short weekly review. Adjust hours to fit capacity. Keep one written next action so each session resumes at a code location or hypothesis rather than restarting reconnaissance.
During the first cycle, preserve one continuing target while rotating lab topics. During specialization, a reasonable starting allocation is 60% hypothesis-driven target work, 20% source reading or lab reproduction, and 20% evidence, reports, and retests. Change the allocation when a specific blocker emerges; these percentages are planning suggestions.
A target sprint#
Day 1: admission. Check eligibility and current policy. Build the scope record, obtain permitted accounts, and list blocked prerequisites. If the essential test cannot be performed under the policy, move the candidate to a blocked queue.
Days 2–3: model. Read product documentation and observe normal use. Identify valuable resources, roles, trust boundaries, asynchronous jobs, import/export paths, and integrations. Prioritize hypotheses rather than endpoint counts.
Days 4–7: investigate. Start from one high-value workflow. Compare roles, identities, object owners, resource states, and alternate protocols. Use source review where available, bounded dynamic tests where permitted, and control observations throughout.
Days 8–10: resolve. Minimize promising findings, eliminate false positives, draft a report, and record negative evidence. Continue only when an unresolved hypothesis has a specific next test. A time-box prevents indefinite collection without analysis; it does not require abandoning a productive target on day ten.
Progress toward private programs#
Build a record of reproducible, valid reports in a narrow surface area. Explain impact clearly, answer triage questions efficiently, follow disclosure restrictions, and retest when requested. A small number of technically strong reports can be a better portfolio than large volumes of low-confidence submissions. Invitations remain platform/program decisions; no number of reports, CVEs, points, or hours guarantees admission.
Before accepting an invitation, check the permitted collaboration rules, confidentiality obligations, testing windows, credential issuance, and whether the new program actually fits your skills. A private program can still have mature coverage, duplicates, narrow scope, or no accessible account path. The platform chapter describes the current participation routes.
Metrics that improve decisions#
| Metric | Definition | Interpretation |
|---|---|---|
| Hypothesis resolution | Confirmed or disproved hypotheses divided by hypotheses attempted | A research throughput measure; do not optimize by choosing only trivial tests |
| Evidence completeness | Candidates with version, preconditions, controls, impact, and repeatable steps | Readiness for review |
| Accepted validity | Reports the program accepts as valid divided by resolved reports | Report quality; a duplicate may still be technically valid |
| Duplicate share | Duplicates divided by technically valid resolved reports | Helps assess target overlap and differentiation |
| Blocked time | Hours lost to inaccessible labs/accounts/unclear scope | Signals when to ask the program or rotate |
| Coverage confidence | Boundary cells supported by recorded tests, with scope restrictions visible | A bounded coverage claim, never proof of absence |
| Return on effort | Rewards actually received divided by recorded research hours | A retrospective personal measure, not a forecast |
Avoid raw hostname, payload, request, or alert counts as success targets. They measure activity, and can rise while the quality of investigation falls. Keep a separate learning log so a month without rewards can still show whether your method improved.
Rotation and exit rules#
Continue when there is a reachable boundary, a fresh lead, and a testable next step. Rotate when the same blockers persist, all prioritized hypotheses have been resolved, or the required environment is unavailable. Pause immediately when scope changes, permission expires, service health degrades, or you encounter data you do not need to establish the issue. Record why you stopped and what would justify resuming.
References#
- PortSwigger. Web Security Academy. Live training catalog; undated; accessed 11 September 2026. Used for the lab resource recommendation.
- OWASP Foundation. Juice Shop. Live project documentation; accessed 11 September 2026. Used for intentionally vulnerable application practice.
- OWASP Foundation. crAPI. Undated project documentation; accessed 11 September 2026. Used for API-specific practice.