« All Roles

Security Engineer - 24-Month Engineering and Research Curriculum

Target roles:

• Senior Security Engineer / Security Consultant
• Product and Application Security Engineer
• Cloud and Kubernetes Security Engineer
• Android Platform or Mobile Application Security Engineer
• Vulnerability Researcher / Security Research Engineer
• Detection Engineer / Incident Responder
• AI and Agent Security Engineer

Reference role: the senior, client-facing security profile in jd.md
Duration: 104 weeks (24 months), 15-20 focused hours per week
Starting point: a strong software engineer who can already build and debug production software
Operating boundary: owned systems, purpose-built labs, CTFs, explicitly authorized programs, and coordinated open-source disclosure only

1. Executive Summary

This is not a collection of hacking tutorials. It is a two-year engineering apprenticeship built around four abilities that elite security teams repeatedly hire for:

1. Understand the system deeply enough to identify where trust is misplaced.
2. Prove the risk safely with reproducible evidence inside an authorized environment.
3. Engineer the control and verify that the fix survives regression, scale, and operational use.
4. Communicate the decision to developers, responders, executives, auditors, and customers.

The curriculum moves from systems and protocol foundations through product security, mobile, cross-platform internals, isolation, cloud, vulnerability research, incident response, OT, and AI security. Every phase produces code, tests, diagrams, evidence, and two reports: one technical and one executive-facing.

The breadth is deliberate, but "broad" does not mean shallow. Four specialization lanes run through the second year: cloud provider security, Android vulnerability research, sandboxing and isolation, and AI/agent security. ICS/OT is offered as a fifth lane for infrastructure roles. Choose one primary lane and one secondary lane by Month 12.

The proof-of-work rule

Reading does not complete a phase. A phase is complete only when:

• its flagship build runs from a clean checkout;
• security properties have automated tests or repeatable verification steps;
• failures and limitations are documented;
• a peer can reproduce the result from the README;
• findings distinguish observation, inference, exploitability, impact, and remediation;
• the portfolio artifact contains no secrets, personal data, proprietary material, or unsafe weaponization.

2. Target Role Mapping

Reference JD alignment

Certifications are checkpoints, not substitutes for evidence. For this JD, prioritize one foundational credential only if needed, then a role-aligned advanced credential after the matching labs. Never postpone practical work to collect badges.

3. Skill Matrix

Score each capability quarterly: 0 unfamiliar, 1 explain, 2 perform with guidance, 3 perform independently, 4 design/review/teach.

* depends on the chosen specialization.

4. The 24-Month Roadmap

Quarterly gates

5. Curriculum Structure

Every phase guide contains objectives, theory, programming work, exact labs, capstone, tools, readings, evaluation, mistakes, interview questions, portfolio artifacts, and stretch goals. Runnable labs follow LAB-STANDARD.md: learner TODOs, complete references, adversarial tests, attack evidence, mitigation, regression, teardown, and communication outputs. See LAB-CATALOG.md for requirements traceability and platform extension work.

6. Weekly Study Structure

Use a repeatable 15-20 hour week:

The four-week phase rhythm

1. Model: learn the system and draw trust boundaries.
2. Break safely: reproduce a known weakness in an owned lab.
3. Fix and detect: implement controls and negative tests.
4. Operate and explain: inject failure, collect evidence, write reports, present decisions.

Longer phases repeat this rhythm with increasingly realistic systems.

7. Lab Environment

Reference architecture

                         Management network
                   Git, artifact store, documentation
                                |
                    [router/firewall + deny-by-default]
                      /          |             \
             attack range    victim range     telemetry range
             Kali/Ubuntu     Win/Linux/macOS   Wazuh/OpenSearch
             test tools      Android emulator  Zeek/Suricata
                    \             |             /
                     \------ isolated switch --/
                                |
                       optional OT simulation

            Separate accounts/projects: AWS | Azure | Google Cloud
            Separate local cluster: kind/k3d + private container registry

Hard rules

• No bridging a malware-analysis or vulnerable-target network to home, corporate, or public networks.
• No real credentials or personal data in fixtures, screenshots, packets, commits, or reports.
• Default cloud budgets, quotas, alerts, and teardown automation before the first deployment.
• Snapshot before risky work; destroy and rebuild after it.
• Hash evidence at collection; record source, time, collector, timezone, and transformation.
• Treat model weights, containers, APKs, binaries, and packet captures as untrusted inputs.
• Never test a target because it is internet-accessible. Test only when ownership and authorization are documented.

Baseline equipment

• Host with 32 GB RAM preferred, 16 GB workable; 200+ GB free SSD
• Virtualization: UTM/VMware/VirtualBox/Hyper-V as appropriate
• Ubuntu engineering VM, isolated security-testing VM, Windows evaluation VM
• Android Studio emulator; physical test device only if dedicated and resettable
• macOS host or authorized macOS VM for Apple labs; iOS simulator for non-jailbreak fundamentals
• Docker/Podman, kind or k3d, Terraform/OpenTofu, Git, task runner
• Wazuh or OpenSearch stack, Zeek, Suricata, osquery, Sysmon, auditd

See templates/lab-acceptance-checklist.md before running any offensive or malware-adjacent exercise.

8. Programming Languages and Why

Quality bar: typed interfaces where supported, linting, tests, dependency locking, threat model, structured logs, no embedded secrets, and a documented least-privilege execution model.

9. Core Books, Papers, and Primary Sources

Read current vendor documentation alongside these durable foundations. Prefer original standards, project documentation, and peer-reviewed or conference work over tool-list blogs.

Systems and vulnerability research

• Computer Systems: A Programmer's Perspective - Bryant and O'Hallaron
• Operating Systems: Three Easy Pieces - Arpaci-Dusseau and Arpaci-Dusseau
• The Art of Software Security Assessment - Dowd, McDonald, and Schuh
• Practical Binary Analysis - Andriesse
• The Fuzzing Book - Zeller et al.
• ELF, PE/COFF, Mach-O, DWARF, x86-64, and Arm architecture specifications

Application, identity, and crypto

• Security Engineering - Ross Anderson
• Real-World Cryptography - David Wong
• OWASP ASVS, MASVS, MSTG, API Security Top 10, SAMM, and threat-modeling resources
• RFCs for HTTP, TLS 1.3, OAuth 2.0, PKCE, OIDC, JWT/JWS/JWE, SCIM, DNS, and WebAuthn
• NIST SSDF and Secure Software Development Framework materials

Platform, cloud, and response

• Android Security documentation and Android Open Source Project source/docs
• Apple Platform Security; Microsoft Windows security and Sysinternals documentation
• Linux kernel, seccomp, namespaces, cgroups, LSM, eBPF, OCI, runc, gVisor, and Firecracker docs
• Kubernetes security documentation and NSA/CISA Kubernetes hardening guidance
• Cloud-provider architecture, IAM, KMS, logging, and incident-response documentation
• NIST SP 800-61, 800-86, 800-207; MITRE ATT&CK; Sigma specification

OT and AI security

• NIST SP 800-82 and CISA ICS guidance
• ISA/IEC 62443 concepts and vendor protocol documentation
• OWASP Top 10 for LLM Applications and Agentic Application Security materials
• MITRE ATLAS, NIST AI RMF, Google SAIF, and model/provider system cards
• Foundational papers on indirect prompt injection, tool-use risks, RAG poisoning, and agent evals

Each phase guide narrows this list to the exact chapters and documentation needed.

10. Tooling Map

Tools never define the method. Every assessment must still state scope, assumptions, evidence, false-positive handling, impact, remediation, and retest result.

11. Capstone Portfolio

The 13 phase capstones form one coherent fictional company, Aegis Transit Cloud: a multi-tenant SaaS and mobile operations platform with cloud services, Android field clients, isolated job execution, OT telemetry, and an AI operations assistant. Reusing one system forces you to manage changing assumptions and cross-domain risk.

Runnable lab portfolio

Every phase includes three learner implementations, reference solutions, adversarial pytest suites, and detailed lab READMEs: 47 runnable labs across the track, including compiled C/C++, Rust, Go, Java/JVM, Kotlin/JNI, and provider-specific AWS, Google Cloud, and Azure work.

1. Engagement scope/evidence guard
2. Bounded binary parser and fuzz smoke target
3. Tenant-aware authorization engine
4. Security release gate
5. Android manifest exposure analyzer
6. Cross-platform service hardening evaluator
7. Sandbox policy compiler for container/gVisor/Firecracker modes
8. Cloud IAM attack-path analyzer
9. Crash triage, minimization, and parser patch
10. Cross-source detection correlation engine
11. Passive OT asset inventory
12. Least-privilege AI agent tool gateway
13. Security portfolio evidence linter

Each numbered item above is the first lab in its phase. Labs 02 and 03 add the adjacent attack, hardening, operations, or evidence layer so no phase is represented by a single exercise.

12. Portfolio Plan

Use this structure:

security-portfolio/
├── README.md
├── 00-operating-rules/
├── 01-tools/
├── 02-threat-models/
├── 03-design-reviews/
├── 04-mobile/
├── 05-cloud-and-isolation/
├── 06-vulnerability-research/
├── 07-detection-and-response/
├── 08-ot/
├── 09-ai-security/
├── 10-talks-and-writing/
└── evidence-private/          # never publish raw sensitive evidence

Every public project needs:

• one-sentence problem and explicit authorization boundary;
• architecture and threat model;
• reproducible setup and teardown;
• tests and expected output;
• known limitations and non-goals;
• secure implementation or remediation;
• sanitized evidence;
• 3-minute demo script;
• one truthful resume bullet with numbers you can defend.

Publish fewer, stronger artifacts. The final portfolio should contain 6-8 flagship projects, not 100 unfinished tool screenshots.

13. Interview Preparation

Interview work starts in Month 2, not Month 24:

• weekly: explain one concept without notes in five minutes;
• biweekly: code or debug a security-relevant component;
• monthly: threat-model a new architecture in 45 minutes;
• quarterly: run a mock incident or design review with an executive summary;
• final quarter: two full loops per specialization.

Use interview-prep/README.md for question banks, system-design prompts, incident scenarios, and behavioral evidence.

The answer standard is: define assets and trust boundaries, state assumptions, prioritize abuse cases, choose controls with tradeoffs, describe validation and telemetry, and communicate residual risk. Tool names alone are not an answer.

14. VRP and Responsible Disclosure

VRP work is optional and begins only after Phase 08 readiness.

1. Select programs with clear scope, safe-harbor language, testing rules, and reporting channels.
2. Build a target matrix from the written policy; ambiguous assets are out of scope.
3. Set request-rate, data-access, account, and cost limits below program maxima.
4. Stop at minimum proof. Do not access unrelated data, establish persistence, evade controls, pivot, degrade service, or test other users.
5. Encrypt notes, redact personal data, preserve timestamps, and report promptly.
6. Follow disclosure timelines and do not publish without authorization.
7. Track duplicates and invalid findings as methodology feedback, not as permission to test harder.

Use templates/rules-of-engagement.md and templates/responsible-disclosure-report.md.

15. AI/LLM Security Specialization

Choose this lane if targeting AI platform, product security, or agent-infrastructure teams.

• Deepen Phases 02, 03, 06, 07, 09, and 11.
• Build a typed tool gateway that separates model intent from authorization.
• Maintain injection, exfiltration, confused-deputy, excessive-agency, and RAG-poisoning eval sets.
• Evaluate capability and safety separately; a refusal rate is not a security metric by itself.
• Treat prompts and filters as defense in depth, never as the authorization boundary.
• Final research question: how does the system contain a compromised model or retrieved document?

Flagship proof: an agent platform where untrusted content cannot directly cause privileged tool execution, with policy tests, approval gates, tamper-evident audit events, and red-team evals.

16. Cloud-Provider Security Specialization

Choose this lane for cloud security, infrastructure security, or security consulting.

• Deepen Phases 02, 03, 05, 06, 07, and 09.
• Implement the same workload in AWS, Azure, and Google Cloud at architecture level; deploy one provider fully to control cost.
• Build IAM graph analysis, organization guardrails, workload identity, private networking, centralized logs, break-glass controls, and incident playbooks.
• Map controls to one regulated baseline in depth; map the others at a comparison level.
• Final research question: how do identity, tenant, and control-plane failures propagate?

Flagship proof: a tested landing zone and Kubernetes platform with policy-as-code, attack-path analysis, detections, recovery exercise, and executive remediation roadmap.

17. Android Vulnerability Research Specialization

Choose this lane for Android platform, mobile product security, or mobile VRP work.

• Deepen C/C++, ARM64, JNI, Binder, SELinux, ART, APK signing, WebView, Keystore, and fuzzing.
• Study AOSP source paths and monthly Android Security Bulletins; reproduce only public issues in compatible local builds or purpose-built apps.
• Maintain vulnerable and fixed app variants with instrumentation and regression tests.
• Final research question: which trust transition crosses Java/Kotlin, Binder, native code, kernel, hardware-backed services, or cloud APIs?

Flagship proof: an original lab-app finding or authorized open-source finding with minimized proof, root cause, patch, regression test, variant analysis, and conference-quality writeup.

18. Sandboxing and Isolation Specialization

Choose this lane for platform security, cloud workload isolation, or systems research.

• Deepen Linux internals, Rust/C/Go, namespaces, cgroups v2, seccomp-BPF, capabilities, LSMs, OCI/runc, KVM, virtio, gVisor, and Firecracker.
• Benchmark security and performance without claiming equivalence to production runtimes.
• Model malicious workloads, control-plane compromise, filesystem/device exposure, noisy-neighbor risks, side channels, and observability gaps.
• Final research question: what remains shared, and what happens when that shared component fails?

Flagship proof: a policy-driven workload runner with layered isolation, negative tests, telemetry, resource controls, and an honest limitations analysis.

19. ICS/OT Specialization

Choose this lane for critical infrastructure, industrial cloud, or public-sector security.

• Deepen Phase 10 plus network, Windows, cloud, IR, and executive communication.
• Use only simulation and vendor-provided training systems.
• Prioritize safety, availability, deterministic operations, passive discovery, and recovery.
• Never transpose IT playbooks blindly into OT; containment can create physical consequences.
• Final research question: which cyber control can alter process safety, and who authorizes it?

Flagship proof: a safety-reviewed architecture and incident exercise connecting an OT simulation to a cloud analytics platform without active probing of real industrial equipment.

20. Assessment Rubrics

Score every capstone from 0-4 in each category. A phase passes at 24/32, with no zero and no score below 2 in safety or reproducibility.

Staff-level distinction

A staff-level submission explains why the organization should choose a control, how it will be adopted, what it costs, how it fails, who owns it, and how success will be measured. Technical cleverness without organizational viability does not score a 4.

21. Final Job-Readiness Checklist

You are ready to apply when you can provide evidence for all of the following:

• I can define authorization, stop conditions, evidence handling, and disclosure workflow.
• I can review C/C++, Rust, Go, Python, Java/Kotlin, and shell code at security boundaries.
• I can explain a request from DNS through TLS, identity, authorization, service, and storage.
• I have led at least six threat models and three full secure design reviews.
• I can test web, API, Android, cloud, container, and endpoint controls in owned labs.
• I can explain Linux, Windows, macOS/iOS, and Android security architecture and limits.
• I built and threat-modeled a sandbox, not merely ran a container.
• I can design IAM, network, key, logging, Kubernetes, CI/CD, and policy controls.
• I can fuzz, minimize, triage, patch, retest, and report a vulnerability.
• I can preserve evidence, build a timeline, lead containment, and write a post-incident review.
• I can explain OT safety constraints and avoid unsafe IT assumptions.
• I can secure an LLM agent with real authorization, isolation, approvals, audit, and evals.
• I have six to eight polished artifacts and can defend every metric on my resume.
• I can brief the same risk to engineers, executives, customers, and auditors.
• I have eight STAR stories showing judgment, conflict handling, incident leadership, mentoring, ambiguity, customer trust, failed decisions, and measurable improvement.
• I can produce a credible 30/60/90-day plan for the target team.

Completing the calendar is not the finish line. Passing this evidence checklist is.