Software Engineer → Security Engineer → AI Security Engineer

Build deep software and systems knowledge, learn how systems fail, and apply that knowledge to secure applications, infrastructure, and AI-enabled systems.

Primary goal

Become a capable security engineer who can design, build, test, and secure real systems, including AI applications and agents.

Career strategy

Pursue Software Engineering, Application Security, Cloud Security, Security Engineering, and AI Security opportunities as your skills and evidence support them.

Operating principle

Learn a concept → implement it → test it → attack it → fix it → document it → publish the evidence.

1. The rules that keep you focused

These rules are part of the plan, not optional extras.

1. One primary learning phase at a time. You can maintain your existing software engineering responsibilities, but don't run several major courses in parallel.

2. Every phase produces evidence. A course completion certificate is not the definition of progress.

3. Books are references, not obligations. Read the sections needed to understand and implement the work.

4. Labs beat passive consumption. Spend substantial time writing code, debugging, testing, and investigating failures.

5. Don't collect technologies. Learn a tool when it helps you understand a principle, build a project, or meet a real job requirement.

6. Apply for opportunities before you finish the curriculum. You do not need to wait 18 months to start applying.

7. Don't restart the plan because of a new idea. Put new ideas in a backlog and review them at a scheduled checkpoint.

8. Use AI as an accelerator, not a substitute for understanding. You must be able to explain, debug, test, and defend the code you ship.

Definition of done for every phase

• Explain the central concepts without relying on notes.

• Implement something that uses them.

• Test normal cases and failure cases.

• Identify and investigate security weaknesses where relevant.

• Fix the problems you find.

• Document the design, limitations, tests, and lessons.

• Publish appropriate evidence in GitHub or your technical archive.

2. The complete 18-month curriculum

Stage 1 — Programming and computer systems

Months 1–3 · C, memory, operating systems, Linux

Establish the foundations that make you better at understanding software failures and security boundaries.

Stage 2 — Automation and infrastructure programming

Months 4–5 · Python and Go

Build practical tools, network services, automation, and security infrastructure.

Stage 3 — Networking, identity and cryptography

Months 6–7 · Protocols, authentication, authorization

Understand how applications communicate, establish trust, and enforce access.

Stage 4 — Application and systems security

Months 8–10 · Web security, vulnerability research

Learn to find, explain, reproduce, and remediate real vulnerabilities.

Stage 5 — Cloud, DevSecOps and threat modeling

Months 11–12 · AWS, containers, CI/CD

Learn to deploy and operate systems with defensible security controls.

Stage 6 — AI engineering and AI security

Months 13–16 · LLMs, RAG, agents, security controls

Build AI systems and learn how to test and secure their data flows, tools, and permissions.

Stage 7 — AI red teaming, research and portfolio

Months 17–18 · Evaluation, reporting, professional evidence

Demonstrate that you can evaluate AI security problems methodically and communicate defensible findings.

3. Phase-by-phase plan

Phase 0 — Environment and workflow

Week 1

Foundation

Objective: establish a repeatable learning and engineering workflow without wasting time configuring tools you already know.

Resources

• The Missing Semester of Your CS Education — official course

• Git documentation — git-scm.com/docs

• Linux manual pages — man7.org

Work to complete

• Establish a security-learning repository or workspace

• Create notes, labs, projects, scripts, and a README

• Verify your compiler, debugger, Git, test tools, and development environment-2

• Create a standard template for recording experiments and security findings

Deliverable: a usable workspace and a short document describing your workflow.

Since you already have Linux, Git, and Neovim experience, don't spend the week relearning basic tooling. Finish the setup quickly and move on.

Phase 1 — C and computer science fundamentals

Weeks 2–8

Current main learning phase

Objective: understand memory, data representation, pointers, processes, and the programming mistakes that create security vulnerabilities.

Primary resources

• CS50 — official course

• The C Programming Language — reference

• Beej's Guide to C Programming — guide

Use the C-focused material from CS50, particularly its work on algorithms, memory, data structures, and debugging. Do not feel obliged to complete unrelated material merely to claim completion.

Learn

• Variables, types, control flow, functions, arrays, pointers and structs

• Strings, memory allocation, stack versus heap-2

• Algorithms, complexity, and common data

• Compilation, linking, debugging and undefined behavior

• File descriptors, system calls and basic process management

Tools

• GCC

• GDB

• Valgrind

• AddressSanitizer and compiler warnings

Build: Unix utilities and a mini shell

Implement simplified versions of:

• mycat

• mycp

• mywc

• mygrep

• myhead

• mytail

Then build a small shell that supports commands, arguments, cd, pipes, redirection, and eventually background processes.

Understand fork(), exec(), wait(), pipe() and dup2() rather than merely copying an implementation.

Security exercises

• Test empty inputs, large inputs, malformed arguments and file errors.

• Investigate buffer boundaries, memory leaks, use-after-free, and incorrect error handling.

• Compile with sanitizers and explain the bugs they detect.

Deliverable: a tested C repository with a mini shell, design notes, debugging examples, and a security lessons document.

Definition of done: you can explain pointers and memory ownership, debug a crash, and trace how a shell launches a process.

Phase 2 — Operating systems and Linux internals

Weeks 9–12

Objective: understand what happens below an application and how operating-system boundaries affect security.

Primary resources

• MIT 6.1810 Operating System Engineering — course materials

• Operating Systems: Three Easy Pieces — free online book

Study in this order

1. Processes, system calls, and context switching.

2. Virtual memory and page tables.

3. Traps, interrupts, and privilege boundaries.

4. Copy-on-write and memory isolation.

5. Locks, concurrency, and race conditions.

6. File systems and file permissions.

Practical work

• Build and trace a small program that makes system calls.

• Run selected xv6 labs.

• Write notes explaining a syscall from user space into the kernel and back.

• Investigate a race condition or access-control mistake in a controlled lab.

Deliverable: a systems notebook containing diagrams, experiments, and explanations of process isolation, memory protection, and synchronization.

Do not publish course solutions as your own portfolio work. Your original experiments and explanations are the evidence.

Phase 3 — Python for security automation

Month 4

Objective: become productive at automating investigations, testing, and repetitive security work.

Resources

• Official Python tutorial

• Automate the Boring Stuff with Python — online edition

Learn

• Functions, modules, packages, exceptions and classes.

• Files, JSON, subprocesses and command-line interfaces.

• HTTP requests, sockets, DNS, and TLS certificate inspection.

• Type hints, unit tests, logging and structured output.

• Async programming where it genuinely helps.

Build a sec-toolkit

1. TCP port scanner for authorized targets.

2. DNS lookup and enumeration tool.

3. HTTP security-header checker.

4. TLS certificate inspection tool.

5. Log analyzer.

6. Report generator.

Quality requirements

• Clear command-line interface.

• Input validation and useful errors.

• Automated tests.

• Timeouts and bounded concurrency.

• Structured logs and documented limitations.

Deliverable: a reusable Python toolkit with tests and example reports.

Phase 4 — Go for security infrastructure

Month 5

Objective: write maintainable, concurrent tools and services suitable for infrastructure and security engineering.

Resources

• A Tour of Go

• Official Go tutorials

• Learning Go — reference

Learn

• Structs, interfaces, pointers and error handling.

• Goroutines, channels, context cancellation and concurrency.

• HTTP servers, TCP services and JSON APIs.

• Modules, testing, fuzzing and dependency vulnerability checks.

• Database access and graceful shutdown.

Build

• Concurrent port scanner.

• Small HTTP proxy.

• REST API.

• TCP service.

• Basic policy engine.

Security emphasis: timeouts, cancellation, resource limits, input validation, race detection, fuzzing, and safe error handling.

Deliverable: a tested Go service and a separate concurrent tool, with benchmarks or profiling where useful.

Don't learn Go merely to add another language to your CV. Learn to use it to build software whose behavior you understand under concurrency and failure.

Phase 5 — Networking and protocol security

Month 6

Objective: understand the communication paths attackers exploit and defenders must protect.

Primary resource

• Computer Networking: A Top-Down Approach — publisher information

Learn

• IP, subnetting, routing, NAT and ARP.

• TCP, UDP, ports and connection state.

• DNS, HTTP, HTTPS and TLS.

• Certificates, trust chains and public-key infrastructure.

• Proxies, firewalls, sockets and network segmentation.

Tools

Wireshark, tcpdump, curl, dig, ss, ip, and netcat.

Build: a client-server service using TLS, authentication, authorization and audit logging.

Experiments

• Capture and explain a TCP connection.

• Inspect a TLS handshake and certificate chain.

• Compare HTTP and HTTPS traffic.

• Diagnose DNS and connection failures.

• Test how your service behaves when clients disconnect or send malformed input.

Deliverable: a networked application, packet captures, and a protocol explanation.

You can start using these networking concepts during earlier phases; this month consolidates them rather than prohibiting earlier exposure.

Phase 6 — Authentication, authorization and cryptography

Months 6–7

Objective: understand how systems establish identity, decide what identities can do, and protect data.

Resources

• Real-World Cryptography

• Serious Cryptography — supplementary reference

Authentication

• Password storage and password verification.

• Sessions, cookies, JWTs and token handling.

• OAuth 2.0, OpenID Connect, MFA and passkeys.

• Session expiry, revocation, and recovery flows.

Authorization

• Role-based and attribute-based access control.

• Object-level and function-level authorization.

• Tenant isolation and privilege escalation.

• Default-deny behavior and least privilege.

Cryptography

• Hashing, HMAC, symmetric encryption and asymmetric cryptography.

• RSA and elliptic-curve cryptography.

• Digital signatures, certificates and TLS.

• Key generation, storage, rotation, revocation and recovery.

Build: a small application with registration, secure sessions, role-based access, object-level authorization, digital signatures, and audit logs.

Then attack your own implementation.

Deliverable: working software plus an authentication and authorization test suite and a cryptography design note.

Never invent your own production cryptographic protocol. Learn the underlying concepts, then use established libraries and vetted protocols.

Phase 7 — Application security

Months 8–9

First major security specialization

Objective: learn to assess real web applications and APIs systematically.

Primary resource

• PortSwigger Web Security Academy

Study priority

1. HTTP, Burp Suite, encoding, and request manipulation.

2. SQL injection.

3. Authentication and session weaknesses.

4. Access control, IDOR/BOLA, and privilege escalation.

5. Path traversal, command injection, and information disclosure.

6. File-upload security, SSRF, and XXE.

7. Business logic flaws and API security.

8. XSS, CSRF, CORS and browser security.

9. JWT and OAuth weaknesses, race conditions, and more advanced topics.

Use these references alongside the labs:

• OWASP Web Security Testing Guide

• OWASP API Security Top 10

Main project: VeriDoc security assessment

VeriDoc is an existing project in your software engineering portfolio. Instead of immediately building another generic application, use it to demonstrate that you can review a real system from both an engineering and security perspective.

Create a dedicated assessment repository or directory containing:

• threat-model.md

• attack-surface.md

• auth-review.md

• authorization-review.md

• api-review.md

• crypto-review.md

• findings/

• remediation.md

• final-report.md

Investigate

• Broken object-level authorization and IDOR.

• Privilege escalation and organization-role enforcement.

• Authentication and session behavior.

• Tenant isolation.

• Document uploads and PDF processing.

• QR-code manipulation and signature verification.

• API abuse, rate limits, secrets, and sensitive information in logs.

• Key management and revocation behavior.

Important: verify each finding through tests or reproducible evidence. A suspected weakness is not a confirmed vulnerability. Record the impact, reproduction steps, remediation, and retest results.

Deliverable: a professional security assessment with prioritized findings, remediation patches, regression tests, and a clear account of the assessment's scope and limitations.

This is where your software engineering background starts producing security-specific evidence. It does not replace the C, operating-systems, or networking phases.

Phase 8 — Systems security and vulnerability research

Months 9–10

Objective: develop a deeper understanding of how implementation errors become exploitable behavior.

Resources

• pwn.college

• Hacking: The Art of Exploitation

• Computer Systems: A Programmer's Perspective — selected sections

Prioritize

• Linux permissions and process boundaries.

• Program memory layout and binary behavior.

• Debugging and reverse engineering.

• Stack overflows, integer overflows, format-string vulnerabilities, and use-after-free.

• Mitigations such as ASLR, stack canaries, and non-executable memory.

Build: a controlled vulnerability lab containing small vulnerable programs, reproduction steps, root-cause explanations, mitigations, and fixed versions.

Deliverable: several complete vulnerability case studies following this sequence:

Vulnerable code → Reproduction → Root cause → Impact → Mitigation → Regression test

Keep the experiments in controlled environments. The goal is understanding vulnerability mechanics and defenses, not accumulating exploit tricks.

Phase 9 — Cloud security

Month 11

Objective: deploy and secure a real application in the cloud.

Start with AWS only. Do not divide your attention across multiple cloud providers at this stage.

Learn

• IAM policies, roles, least privilege and trust relationships.

• VPCs, subnets, routing, security groups and network boundaries.

• EC2, S3, RDS and Lambda.

• CloudTrail, CloudWatch, KMS and Secrets Manager.

• Encryption, logging, monitoring, and incident investigation.

Build: deploy an application with:

• Least-privilege identities.

• Private networking where appropriate.

• Secure secrets handling.

• Encryption in transit and at rest.

• Centralized logs and monitoring.

• Documented threat model and recovery assumptions.

Deliverable: deployment documentation, architecture diagram, IAM policy review, threat model, and evidence that the controls work.

Use a budget limit and clean up unused resources. Cloud experiments can create unexpected charges.

Phase 10 — Docker, CI/CD and DevSecOps

Month 12

Objective: incorporate security checks into the software delivery process.

Learn

• Docker images, layers and container configuration.

• Linux namespaces, cgroups, capabilities and isolation.

• Rootless containers and non-root execution.

• CI/CD workflows, artifact provenance and deployment controls.

• Software composition analysis, secrets scanning, SAST and DAST.

Tools to become familiar with

• Semgrep

• Gitleaks

• Trivy

• OWASP ZAP

• Syft

• Grype

Build: a GitHub Actions pipeline that runs tests, static analysis, dependency checks, secret scanning, container builds, and image scanning before deployment.

Deliverable: a working CI pipeline with documented failure conditions and examples of vulnerabilities the checks can catch.

Do not treat green pipeline badges as proof that an application is secure. Explain the coverage and limitations of each check.

Phase 11 — Threat modeling

Month 12

Objective: reason about security before implementation and testing.

Learn

• STRIDE.

• Data-flow diagrams and trust boundaries.

• Attack trees and abuse cases.

• Security requirements and attack-surface analysis.

• Risk prioritization and mitigation tradeoffs.

Create threat models for

1. VeriDoc.

2. Your cloud-hosted application.

3. A retrieval-augmented generation (RAG) application.

4. A tool-using AI agent.

For each, document assets, trust boundaries, threats, existing controls, gaps, mitigations, and residual risk.

Deliverable: four threat models that demonstrate how the same security reasoning applies to conventional software and AI-enabled systems.

Phase 12 — AI engineering fundamentals

Months 13–14

Objective: understand enough AI engineering to build and test the systems you eventually want to secure.

Primary resource

• Hugging Face LLM Course

Learn

• Tokens, context windows, embeddings and transformers.

• Model inference, model APIs and evaluation.

• Datasets and basic fine-tuning concepts.

• RAG: document ingestion, chunking, embeddings, retrieval, prompting and generation.

• Tool calling and agent workflows.

• Evaluation, observability, latency, and failure behavior.

You do not need to become a machine-learning researcher before starting AI security. Learn the mathematical and ML concepts needed to understand the behavior and limitations of the systems you build.

Build: a secured RAG application with:

• Authentication and authorization.

• Document-level permissions.

• Tenant isolation.

• Input and output handling.

• Rate limits and audit logs.

• Tests for cross-user data leakage.

Deliverable: a working application, architecture diagram, threat model, test suite, and security evaluation.

Avoid spending this phase building yet another generic chat-with-PDF demo. The permissions, retrieval behavior, and security testing are what make this project relevant to your target specialization.

Phase 13 — AI and LLM security

Months 14–15

Core specialization

Objective: understand how AI-specific failure modes interact with ordinary software and infrastructure vulnerabilities.

Reference material

• OWASP Top 10 for LLM Applications

• OWASP Top 10 for Agentic Applications

• OWASP Agentic Security Initiative

Use the relevant current editions when you begin this phase; these resources evolve, so do not freeze the curriculum around an older list.

Learn and test

• Direct and indirect prompt injection.

• Malicious documents and untrusted retrieved content.

• Sensitive-data disclosure and cross-tenant leakage.

• Tool permissions and unauthorized tool calls.

• Excessive agency and privilege escalation.

• Insecure tool chaining and unsafe output handling.

• AI supply-chain risks.

• Sandboxing, network restrictions, and filesystem access controls.

• Policy enforcement outside the model.

Build: a deliberately vulnerable AI agent that uses tools in a controlled environment. Give it a limited set of capabilities, such as reading files, querying a test database, or making restricted HTTP requests.

Then test whether adversarial inputs can cause unauthorized actions or data disclosure.

Deliverable: a set of reproducible attack cases, security tests, mitigations, and an evaluation report.

The central principle: a model's instruction-following behavior is not an authorization boundary. Enforce permissions and security policy in ordinary software.

Phase 14 — Agent Security Gateway

Months 15–16

Objective: turn your AI security knowledge into a concrete security engineering project.

Build an Agent Security Gateway, preferably in Go, that mediates between an AI agent and its tools.

AI agent

Requests a tool action

Identity and policy engine

Checks identity, tool, arguments, permissions and context

Allow

Execute an authorized action

Deny

Reject and record the request

Conceptual architecture; implementation and enforcement tests are part of the project.

Implement

• Agent and tenant identity.

• Tool allowlists and explicit permissions.

• Policy rules and argument validation.

• Approval for sensitive actions.

• Rate limits and resource limits.

• Audit logs.

• Tenant isolation.

• Policy evaluation and deterministic deny behavior.

Test

• Requests for unauthorized tools.

• Malformed arguments.

• Attempts to access another tenant's data.

• Prompt injection that attempts to trigger a privileged action.

• Timeouts, service failures, and concurrent requests.

• Attempts to bypass the gateway.

Deliverable: a working gateway, policy tests, a threat model, architecture documentation, and a demonstration of attacks blocked and allowed actions correctly executed.

Be precise about the claim: the gateway enforces specific controls and reduces defined risks. It does not eliminate prompt injection or guarantee that an AI agent is safe.

Phase 15 — AI red teaming and security evaluation

Month 16–17

Objective: build a repeatable framework for testing AI-enabled systems rather than relying on a handful of manual prompts.

Resource

• PortSwigger Web LLM attacks learning materials

Build a test framework with

• Attack-case definitions.

• A controlled test runner.

• Expected behavior and policy assertions.

• Result collection and reporting.

• Regression tests for previously discovered failures.

• Reproducible test configuration.

Test direct and indirect prompt injection, unauthorized tool use, data disclosure, malicious retrieved content, and policy bypass attempts.

Deliverable: a red-team test suite that can run against both the vulnerable agent and the protected version.

Measure results and document the test environment, assumptions, limitations, false positives, and false negatives. A test suite is evidence of evaluation coverage, not proof that all possible attacks have been prevented.

Phase 16 — AI security research

Month 17

Objective: demonstrate that you can investigate a narrow security question with a defensible methodology.

Resource

• MITRE ATLAS

Choose one small research question, such as:

How effectively do different controls reduce indirect prompt-injection attacks against tool-using agents in a defined test environment?

Research process

1. Define the question and scope.

2. Establish a baseline system.

3. Build a repeatable attack dataset.

4. Implement one or more defensive controls.

5. Run the same tests against each configuration.

6. Record results and analyze failures.

7. Explain limitations and threats to validity.

8. Publish the methodology, test cases, and findings.

Deliverable: a concise research report and reproducible code.

Do not begin with a broad claim such as “solving prompt injection.” A narrow question with clear experiments is more credible than an ambitious claim without convincing evidence.

Phase 17 — Portfolio consolidation and job search

Month 18

Ship

Objective: turn your work into professional evidence and use it to pursue opportunities.

Your portfolio should tell one coherent story: a software engineer who understands systems, builds tools, assesses security, and can test and secure AI-enabled applications.

Target portfolio

1. VeriDoc security assessment

Demonstrates application security, threat modeling, access-control testing, cryptographic reasoning, remediation, and regression tests.

2. Python security toolkit

Demonstrates scripting, network analysis, automation, testing, and report generation.

3. Go security infrastructure

Demonstrates concurrency, network services, policy enforcement, and systems engineering.

4. Cloud and DevSecOps system

Demonstrates least privilege, secure deployment, CI/CD checks, monitoring, and operational security.

5. AI security platform

Demonstrates a vulnerable agent, a security gateway, red-team tests, and a documented evaluation.

These are five connected projects, not five unrelated applications. Some are extensions of the same system, and that is intentional.

Each major repository should include

• A precise README explaining the problem and what the project demonstrates.

• Architecture and data-flow diagrams.

• Reproducible setup instructions.

• Tests and test results from a recent run.

• Security assumptions and threat model.

• Findings, fixes, and known limitations.

• Screenshots or a short demonstration where useful.

• Clear separation between implemented controls and future work.

At this stage, update your CV, GitHub, LinkedIn, and adnanilyas.dev to reflect demonstrated capability. Don't wait until Month 18 to begin applying.

4. The 18-month execution calendar

This is the month-by-month sequence. Use it to determine your current phase, not as a reason to rush through material you do not understand.

Reality check: the timeline assumes consistent effort and is not a promise that mastery arrives on schedule. Some phases may take longer. Do not move on simply because the calendar says so; move on when you can meet the phase's definition of done. If you have a relevant job opportunity earlier, prioritize the skills and evidence needed for that opportunity.

5. Your weekly operating schedule

Target 15–20 focused hours per week if your other responsibilities allow it.

Monday

2 hours

Course or textbook

Understand one defined concept

Tuesday

2 hours

Labs and experiments

Reproduce the concept in practice

Wednesday

2 hours

Programming

Implement a working component

Thursday

2 hours

Testing and security

Find failures and explain them

Friday

2 hours

Project integration

Make the project more complete

Saturday

4–6 hours

Deep work

Finish a substantial feature or experiment

Sunday

1–2 hours

Review and documentation

Record evidence and choose next week's task

You do not need to follow these exact days if your schedule differs. Preserve the balance between learning, implementation, testing, and documentation.

Your weekly review

Answer these questions every Sunday:

• Which skill improved through visible output?

• What did I build or change?

• What did I test, break, or debug?

• What did I misunderstand?

• What evidence did I publish or improve?

• What is the single most important outcome for next week?

• Did I spend time on something that should be postponed or removed?

If you cannot point to an artifact, test, implementation, or written explanation, be honest about whether the week produced meaningful progress.

6. What you should deliberately postpone

These are not necessarily bad technologies or activities. They are lower priority for your current plan.

Terraform, Kubernetes, MCP, additional cloud platforms, and certifications can enter the plan when a project or a credible job requirement justifies them.

7. Career strategy: don't wait until the curriculum ends

Your target is AI Security / Security Engineering, but you should keep adjacent roles open. Job titles vary, and the best entry point depends on your demonstrated skills and available opportunities.

Start reviewing actual job postings early. Track the recurring requirements, then compare them with your current evidence. Adjust your CV and build work that closes important gaps; do not assume every advertised requirement deserves equal study time.

Your strongest professional positioning will come from connecting your software engineering ability to demonstrable security work—not from claiming expertise in every area before you have evidence.

8. What to do right now

The immediate plan is intentionally much smaller than the entire curriculum.

Your current execution checklist

0 of 6

Freeze the master roadmap

Save this plan as the current version. Record new ideas in a backlog instead of changing phases.

Complete the Phase 0 setup

Verify your development environment and create your learning workspace. Skip tooling you already know.

Start the C-focused CS50 material

Begin with fundamentals and work through the exercises yourself.

Practice C outside the lectures

Write small programs, compile with warnings, debug failures, and use sanitizers.

Start the Unix utilities project

Begin with mycat, then add tests and error handling before moving to the next utility.

Write a weekly progress note

Record what you implemented, what failed, what you learned, and the next concrete task.

Your first 90 days

Days 1–30: finish the necessary environment setup, work through C fundamentals, and build small programs.

Days 31–60: focus on pointers, memory, algorithms, data structures, debugging, and the Unix utilities project.

Days 61–90: focus on operating systems and xv6, deepen your understanding of processes and system calls, and complete the mini shell to a reasonable standard.

These are targets, not excuses to rush. If you are struggling with memory management or process behavior, spend the time to understand them.

9. The standing rule for future decisions

When you encounter a new course, technology, project idea, security specialization, or career opportunity, ask:

1. Does it directly support the current phase or a real opportunity?

2. Will it improve a skill I can demonstrate?

3. Will it produce evidence that is stronger than what I already have?

4. What must I postpone to make room for it?

If the idea does not have a compelling answer, put it in the backlog.

We can revisit the roadmap at the end of each phase, or earlier when meaningful new evidence appears. We should not redesign it every time you read an interesting article or discover a new AI security tool.

The immediate priority is Phase 0 followed by Phase 1: C, memory, debugging, and the Unix utilities project. VeriDoc remains an important existing project to assess during the application-security phase. It is not a reason to abandon the curriculum or switch your primary focus today.

Your objective is to reach the end of these 18 months with substantially stronger engineering ability, credible security work, a coherent portfolio, and active professional opportunities—not merely a completed list of courses.