Security engineer roadmap
Every stage in order: threat modelling, cryptography, identity, application and API security, infrastructure and cloud, then detection, incident response and offensive testing. The other two paths are subsets of this one.
Core and recommended topics. Optional ones stay hidden until you have some real work behind you.
- Core: needed for most jobs of this kind
- Recommended: worth learning early
- Optional: learn it when your work needs it
Stage 1
Foundations and threat modelling
Security work starts by listing what can go wrong. Before choosing controls, you should be able to draw the trust boundaries in a system, list the threats that cross them, and rank them by what an attacker would gain. Later stages respond to threats identified here.
Core: The CIA triad and security properties
Confidentiality, integrity and availability, plus authenticity and non-repudiation. Each control protects one or more of these, and knowing which helps you pick the right one.
CodexSecurity fundamentals Outside linkNIST glossary: security terms
Core: Threat modelling with STRIDE
Spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. Checking each data flow against these six produces a concrete list of threats to address.
Outside linkOWASP Threat Modeling cheat sheet Outside linkMicrosoft: Threat Modeling CodexSecurity
Core: Trust boundaries and attack surface
A trust boundary is anywhere data passes from a less trusted part of the system to a more trusted one. Keep the attack surface small, validate input at every boundary, and treat anything from outside as potentially hostile.
Outside linkOWASP: Attack Surface Analysis GuideHow reverse proxies work
Recommended: Defence in depth and least privilege
Use several independent controls so that one failing does not expose everything, and give each user and service only the access it needs.
Outside linkNIST SP 800-160: Engineering Trustworthy Systems
Stage 2
Cryptography basics
You will rarely design cryptography, but you will often choose and configure it. Know what each primitive guarantees and the common ways it is misused, such as ECB mode, reused IVs and plain SHA hashes for passwords.
Core: Symmetric, asymmetric and authenticated encryption
Symmetric encryption is fast but both sides need the same key; asymmetric encryption solves key distribution at a higher cost. Use an authenticated mode such as AES-GCM or ChaCha20-Poly1305 so tampering with the ciphertext is detected.
Outside linkCrypto 101 Outside linkNIST SP 800-38D: GCM CodexSecurity
Core: Hashing, encryption and encoding
Encoding is reversible and secret-free, encryption is reversible with a key, and hashing is one-way. Mixing them up causes many crypto bugs. Base64 is an encoding and protects nothing.
Outside linkOWASP: Cryptographic Storage cheat sheet Outside linkCrypto 101
Core: Password hashing
Store passwords with a salted, deliberately slow function such as Argon2id, scrypt or bcrypt, never a plain hash. The work factor makes offline cracking expensive if the database leaks.
SimulatorPassword hashing Outside linkOWASP: Password Storage cheat sheet
Recommended: Digital signatures and MACs
A MAC lets anyone holding the shared key check that data was not changed. A signature can be checked by anyone with the public key and proves who signed it. Choose based on who needs to verify.
Outside linkNIST FIPS 186-5: Digital Signature Standard Outside linkCrypto 101
Stage 3
Authentication
Login is the part of a system attackers try first. Learn the main flows (passwords, MFA, OAuth and OpenID Connect) and how they fail: credential stuffing, token theft, and session hijacking or fixation.
Core: Sessions and tokens
Server-side sessions are easy to revoke but need shared storage. Stateless JWTs avoid the lookup but are hard to revoke before they expire. The choice shapes how logout and credential rotation work.
SimulatorJWT lifecycle Outside linkOWASP: Session Management cheat sheet CodexSecurity
Core: OAuth 2.0 with authorization code and PKCE
OAuth delegates access: it issues access tokens, and it is not a login protocol by itself. The authorization code flow with PKCE is the recommended default, and the implicit flow should no longer be used (RFC 9700).
GuideOAuth: how it works Outside linkoauth.net: OAuth 2.0 Outside linkRFC 6749: OAuth 2.0
Core: OpenID Connect
OpenID Connect adds identity on top of OAuth with an ID token that says who signed in. Use it for login rather than treating an OAuth access token as proof of identity.
Recommended: MFA and passkeys
Authenticator-app codes are better than SMS, and phishing-resistant WebAuthn passkeys are better than both. The goal is that a stolen password is not enough to get in.
Outside linkOWASP: MFA cheat sheet Outside linkWebAuthn: MDN
Stage 4
Authorization and access control
Broken access control is first in the OWASP Top 10 (2021) because it is a logic error that no library prevents for you. Choose a model (roles, attributes, ownership checks) and enforce it on the server for every request, since the client can send anything.
Core: RBAC and ABAC
Role-based access control is coarse and easy to reason about. Attribute-based control is finer-grained and more flexible. Many systems start with roles and add attribute checks for cases roles cannot express.
Outside linkNIST: Attribute Based Access Control CodexSecurity
Core: Broken access control and IDOR
Changing
/orders/123to/orders/124should not show someone else's order, but this bug is very common. Check ownership on the server for every object a request loads, whatever the UI shows.Outside linkOWASP: Broken Access Control (A01) Outside linkPortSwigger: Access control
Recommended: Privilege escalation and the confused deputy
Vertical escalation gains admin rights; horizontal escalation reaches another user's or tenant's data. A confused deputy is a trusted service tricked into using its own permissions on an attacker's behalf.
Stage 5
Network security
Requests travel over TCP, with DNS to find the server and TLS on top. Know how the TLS handshake establishes trust, how segmentation limits what an attacker can reach, and why encryption in transit is necessary but not enough on its own.
Core: TCP and the handshake
Connections open with SYN, SYN-ACK and ACK, and SYN floods and spoofing attacks target this step. Being able to trace a connection makes the rest of network security easier.
SimulatorTCP handshake GuideTCP: how it works CodexNetworking
Core: TLS and certificates
TLS provides confidentiality, integrity and server authentication, provided the certificate chain validates. Require TLS 1.2 or later and disable weak cipher suites.
GuideHTTPS: how it works Outside linkRFC 8446: TLS 1.3 Outside linkOWASP: TLS cheat sheet
Recommended: DNS security
Attackers poison caches and hijack records to send users to the wrong server. DNSSEC protects the integrity of answers, and DNS over HTTPS or TLS protects their privacy.
GuideDNS: how it works SimulatorDNS resolution Outside linkRFC 9364: DNSSEC
Recommended: Segmentation and firewalls
On a flat network, one compromised machine can reach everything. Split the network into zones by trust level, deny traffic between them by default, and review firewall rules like code.
Outside linkNIST SP 800-41: Firewall guidelines CodexNetworking
Stage 6
Web application security
Browsers run whatever script ends up on a page, and servers process whatever requests arrive. This stage covers the classic web vulnerabilities (injection, XSS, CSRF and SSRF) and the encoding, headers and same-origin rules that prevent them.
Core: OWASP Top 10
The OWASP list of the most common web application risks. If you can explain each category and the control that addresses it, you understand most real findings.
Outside linkOWASP Top 10 Outside linkPortSwigger Web Security Academy CodexSecurity
Core: Injection
Building a query or command by concatenating user input lets that input change the command. Parameterised queries prevent SQL injection without any need for clever escaping.
Outside linkOWASP: Injection (A03) Outside linkOWASP: SQL Injection Prevention Outside linkPortSwigger: SQL injection
Core: Cross-site scripting (XSS)
If attacker-controlled text is rendered as HTML, the browser runs any script in it. Encode output for its context and add a strict Content Security Policy. Blocklists of bad strings do not work.
Outside linkOWASP: XSS Prevention Outside linkContent Security Policy: MDN Outside linkPortSwigger: XSS
Recommended: CSRF and the same-origin policy
Cross-site request forgery uses the cookies a browser sends automatically to act as the user. SameSite cookies plus a token or Origin check prevent it, and the same-origin policy underlies most other browser defences.
Outside linkOWASP: CSRF Prevention SimulatorCORS preflight Outside linkSame-origin policy: MDN
Recommended: Server-side request forgery
If an attacker can make your server fetch a URL of their choosing, the server becomes a way into your internal network, including cloud metadata endpoints. Allowlist outbound destinations rather than only blocking localhost.
Outside linkOWASP: SSRF Prevention Outside linkPortSwigger: SSRF
Stage 7
API and service security
APIs expose the data model directly, so the common bugs are different: object-level authorization, mass assignment and resource abuse. Whether calls go through a gateway or a service mesh, each one needs an identity, an authorization check and limits.
Core: OWASP API Security Top 10
APIs fail in different ways from web pages, and broken object-level authorization (BOLA) is the most common. This list is the API counterpart to the main Top 10.
Core: API gateways and authentication at the edge
A gateway handles authentication, rate limits and request validation in one place, so each service does not implement them separately. Because everything passes through it, a misconfiguration there affects every service.
GuideAPI gateway: how it works GuideReverse proxy: how it works
Recommended: Rate limiting and abuse
Without limits, an API invites denial of service and scraping. Limit by user and by the cost of each request, not only by IP address, and return 429 before the database is overloaded.
Outside linkOWASP: Unrestricted Resource Consumption (API4) SimulatorRate limiter CodexSystem design
Recommended: Service identity with mutual TLS
Services inside your network still need to prove who they are. Mutual TLS with short-lived certificates that rotate automatically replaces shared secrets and makes it harder for an attacker to move between services.
Outside linkSPIFFE / SPIRE: workload identity SimulatorService mesh Outside linkRFC 8705: mTLS client auth
Stage 8
Secure development
A vulnerability that never gets merged costs nothing to fix. Build security into the development process with safe defaults, dependency management and automated scanning in CI, so the pipeline catches what code review misses.
Core: A secure development lifecycle
Security runs through requirements, design review, testing and response rather than being a final check. A class of bug removed at design time costs nothing later.
Core: Dependencies and the supply chain
Most of the code you ship was written by someone else. Pin versions, scan for known vulnerabilities, generate an SBOM, and treat transitive dependencies as part of your attack surface.
Outside linkOWASP: Vulnerable & Outdated Components (A06) Outside linkSLSA: supply-chain framework Outside linkOWASP Dependency-Check
Recommended: SAST, DAST and secret scanning
Static analysis reads the code, dynamic analysis tests the running application, and secret scanners catch credentials before they are committed. Run all three in CI and tune them so the results are worth reading.
Outside linkOWASP: DevSecOps Guideline Outside linkOWASP ASVS
Stage 9
Secrets and key management
A secret committed to a repository is available to anyone who clones it. Keep secrets in a dedicated manager, rotate them automatically, and use a KMS so encryption keys are never stored in plain text on a disk.
Core: Secrets management
Keep credentials out of environment files and configuration. A secrets manager provides central storage, access control and an audit log of who read what, and makes rotation routine.
Outside linkOWASP: Secrets Management cheat sheet CodexCloud
Core: Key management and KMS
With envelope encryption, data keys are encrypted under a master key that never leaves the KMS. Decide the key hierarchy, how keys rotate, and who can use a key versus manage it.
Outside linkAWS KMS concepts Outside linkCloud KMS: Google Outside linkNIST SP 800-57: Key Management
Recommended: Secret rotation and leaks
A leaked secret is dangerous for as long as it stays valid. Short lifetimes and automatic rotation reduce that window. Write the revoke-and-rotate runbook before you need it.
Outside linkAWS: rotating secrets Outside linkOWASP: Secrets Management cheat sheet
Stage 10
Cloud security
The cloud provider secures its infrastructure and you secure what you build on it. Most cloud breaches come from misconfiguration, such as over-broad IAM roles, public buckets and open security groups. This stage covers the model and the guardrails that prevent those mistakes.
Core: Shared responsibility and IAM
IAM decides what every user and service can do in the cloud, and one over-permissive role can be enough for a breach. Grant least privilege and audit who can assume which roles.
Outside linkAWS IAM best practices Outside linkAWS shared responsibility model CodexCloud
Core: Cloud misconfiguration
Public storage buckets and open security groups expose far more data than new exploits do. Deny by default, scan continuously, and treat a misconfiguration as a vulnerability.
Outside linkGoogle Cloud security best practices Outside linkAWS Security best practices
Recommended: Network isolation and private access
VPCs, private subnets and private endpoints keep traffic off the public internet. Combined with security groups, they control which resources can reach which.
Outside linkAWS VPC security Outside linkAzure network security
Recommended: Encryption at rest and in transit
Turn on default encryption wherever the provider offers it, and use customer-managed keys where you need control over key lifecycle. Encrypt unless there is a written reason not to.
Outside linkGCP: encryption at rest Outside linkAWS: data protection
Stage 11
Container and Kubernetes security
Containers share the host kernel, so they are less isolated than virtual machines. Secure the image you build, the runtime it runs in, and the Kubernetes control plane that schedules it.
Core: How containers are isolated
Namespaces and cgroups isolate containers, but less strongly than a virtual machine isolates guests. Knowing what a container shares with the host tells you what an attacker gains by escaping it.
GuideContainers: how it works SimulatorDocker internals CodexKubernetes
Core: Image hardening and scanning
Start from a minimal or distroless base image, run as a non-root user, and scan for known vulnerabilities before pushing. Every shell and package manager left in the image is something an attacker can use.
Outside linkKubernetes: Pod Security Standards SimulatorContainer layers Outside linkDocker: build best practices
Core: Pod security and admission control
Privileged containers, host mounts and
hostNetworkin a pod spec give a container access to the node. Enforce Pod Security Standards and admission policies so such pods are rejected.GuidePod creation: how it works Outside linkKubernetes: Security overview
Recommended: Kubernetes RBAC and network policies
RBAC decides who can do what through the Kubernetes API; network policies decide which pods can talk to each other. Deny by default for both and open only what each workload needs.
Outside linkKubernetes: RBAC authorization Outside linkKubernetes: Network Policies
Stage 12
Logging, monitoring and detection
Good detection is the difference between an incident you contain and a breach you hear about from someone else. Log security-relevant events, collect and protect the logs, and write detections for behaviour attackers find hard to avoid.
Core: Security logging
Log sign-ins, authorization failures and admin actions with enough context to rebuild a timeline, and keep secrets out of the logs. Events you do not log cannot be investigated.
Core: Detection and SIEM
Collect logs centrally and write detections for attacker behaviour, not only known signatures. MITRE ATT&CK catalogues the techniques to look for.
Outside linkMITRE ATT&CK Outside linkOWASP: Logging & Monitoring failures (A09)
Recommended: Tamper-resistant audit trails
Attackers often delete logs once they get in. Send logs off the host to append-only storage so the evidence survives even if the host is compromised.
Outside linkAWS CloudTrail: best practices Outside linkNIST SP 800-92: Log Management
Stage 13
Incident response and forensics
Most organisations are breached at some point, and what matters is the response. Learn the phases (prepare, detect, contain, eradicate, recover, learn), how to preserve evidence under pressure, and how to turn each incident into a control that prevents the next one.
Core: The incident response lifecycle
Prepare, detect, contain, eradicate, recover and learn (NIST SP 800-61). The steps are easy to forget in the middle of the night, which is why teams rehearse them.
Outside linkNIST SP 800-61: Incident Handling Guide CodexSecurity
Core: Containment and eradication
Stop the damage without destroying evidence: isolate a compromised machine rather than switching it off. Then remove any persistence the attacker left behind, which often outlasts the alert that found them.
Outside linkSANS: Incident Handler's Handbook Outside linkNIST SP 800-61: Incident Handling Guide
Recommended: Forensics and evidence
Capture memory and other volatile state first, hash everything you collect, and keep a chain of custody. An investigation can only use the evidence preserved before someone rebooted the machine.
Outside linkNIST SP 800-86: Forensic Techniques Outside linkMITRE ATT&CK
Stage 14
Offensive security and red teaming
Defenders who know how attacks work make better decisions. Learn the attacker's process, practise it legally through labs, penetration tests and red team exercises, and turn each finding into a fix or a detection.
Core: Attacker methodology
Reconnaissance, initial access, privilege escalation, lateral movement and exfiltration. MITRE ATT&CK maps each step to documented techniques, which makes it a useful checklist for defence.
Outside linkMITRE ATT&CK Outside linkPortSwigger Web Security Academy CodexSecurity
Core: Web exploitation practice
Hands-on labs such as the PortSwigger Web Security Academy and OWASP Juice Shop show where web bugs hide far better than reading about them.
Outside linkPortSwigger Web Security Academy Outside linkOWASP Juice Shop Outside linkOWASP WSTG
Recommended: Penetration testing
A penetration test is a scoped, time-limited attack followed by a report. Know the method well enough to run one, scope one, or judge the findings in one.
Outside linkOWASP Web Security Testing Guide Outside linkPTES: Penetration Testing Standard
After this roadmap
- SimulatorsJWT lifecycles, password hashing, CORS preflight and the TCP handshake, as models that run in the browser.
- How it worksGuides to HTTPS, OAuth, OpenID Connect, DNS and reverse proxies.
- Security in the CodexLonger study pages on cryptography, authentication and application security.