Security Engineering Roadmap

The vocabulary every later level uses. What you are protecting, the three questions of the CIA triad, what a trust boundary is and why an assumption must be re-validated at every crossing, and a repeatable threat-modeling process. Nothing here is a vulnerability yet; it is how you decide which vulnerabilities matter.

Before moving on: Name the assets, actors and entry points of a small system, draw its trust boundaries, and list its top threats in STRIDE terms.

• What Security Engineering Actually IsNot startedLearningPracticingMastered
• Confidentiality, Integrity, Availability — PracticallyNot startedLearningPracticingMastered
• Trust BoundariesNot startedLearningPracticingMastered
• Threat Modeling: The ProcessNot startedLearningPracticingMastered

The first boundary a request crosses is "who is this?" and the second is "what may they do?". Authentication and authorization are separated on purpose, then each is built: password storage that survives a stolen table, sessions that can be inspected and revoked, and authorization models layered in the right order. Broken access control closes the level because it is the most common serious bug in real APIs.

Before moving on: Explain why an authenticated GET /invoices/101 still needs an ownership check, choose a password hash and session design, and pick the authorization model a feature calls for.

• Authentication vs AuthorizationNot startedLearningPracticingMastered
• Password StorageNot startedLearningPracticingMastered
• SessionsNot startedLearningPracticingMastered
• Authorization ModelsNot startedLearningPracticingMastered
• Broken Access Control (IDOR / BOLA)Not startedLearningPracticingMastered

The same failure in several costumes: data crossing a boundary and being interpreted as instructions. The browser origin model first, then XSS, CSRF and SQL injection as boundary failures rather than trivia, then the API pipeline of parse → validate → authenticate → authorize → process. Sessions and authorization from Level 2 are what CSRF and IDOR abuse.

Before moving on: Trace one request from browser to database, say at which hop XSS, CSRF and SQL injection happen, and put output encoding, parameterization and validation at the right hop.

• Web Security: Browser to DatabaseNot startedLearningPracticingMastered
• Cross-Site Scripting (XSS)Not startedLearningPracticingMastered
• Cross-Site Request Forgery (CSRF)Not startedLearningPracticingMastered
• SQL Injection and ParameterizationNot startedLearningPracticingMastered
• API Security as a BoundaryNot startedLearningPracticingMastered
• Parse, Validate, Authorize, ProcessNot startedLearningPracticingMastered

Enough cryptography to use it correctly: hashes, MACs, signatures, keys, nonces, and the rule to use established protocols instead of your own. TLS is treated as a boundary with a precise guarantee for one hop, so you can say what "we use HTTPS" does not cover after Level 3. Secrets management and the secret lifecycle turn credentials into something with a scope, an owner and a rotation.

Before moving on: Choose hash versus MAC versus signature for a given need, state what TLS guarantees and what it does not, and describe a secret from creation through rotation to revocation.

• Cryptography FundamentalsNot startedLearningPracticingMastered
• TLS as a Security BoundaryNot startedLearningPracticingMastered
• Secrets ManagementNot startedLearningPracticingMastered
• The Secret LifecycleNot startedLearningPracticingMastered

Assume the application is compromised and ask what the attacker reaches next. Database privileges, network segmentation with explicit narrow crossings, privilege separation between setup and request handling, and what a container does and does not isolate. It comes after application and secret controls because these layers are what catch the failures those controls miss.

Before moving on: Given a compromised web process, list what it can reach in the database, the network and the host, and name the control that shrinks each reach.

• Database Security PropertiesNot startedLearningPracticingMastered
• Network SegmentationNot startedLearningPracticingMastered
• Privilege SeparationNot startedLearningPracticingMastered
• Container Security and Its LimitsNot startedLearningPracticingMastered

The same identity and privilege thinking applied to machines and pipelines. IAM as principal → action → resource → condition, short-lived credentials that replace stored secrets, and the supply chain and CI/CD paths through which code you did not write runs with your authority. Needs the secret lifecycle from Level 4 and the blast-radius habit from Level 5.

Before moving on: Write a least-privilege IAM policy for one workload, replace a long-lived key with a short-lived credential, and point at where a pull request from a fork must lose trust in CI.

• Identity and Access Management (IAM)Not startedLearningPracticingMastered
• Short-Lived CredentialsNot startedLearningPracticingMastered
• Software Supply Chain SecurityNot startedLearningPracticingMastered
• CI/CD SecurityNot startedLearningPracticingMastered

Prevention fails, so the rest of the loop matters: which tests find which class of bug, how telemetry becomes a detection with an owner, how to prioritise vulnerabilities by exposure instead of CVSS, and the incident lifecycle from containment to learning. It sits here because you need the earlier controls to know what a signal or a finding means.

Before moving on: Pick the security test that finds a given bug class, write one detection with its response path, and order the first hour of an incident response.

• Security Testing PortfolioNot startedLearningPracticingMastered
• Detection EngineeringNot startedLearningPracticingMastered
• Vulnerability Management by ExposureNot startedLearningPracticingMastered
• Incident Response LifecycleNot startedLearningPracticingMastered

Put the levels together on whole systems. The ten-question security review turns the threat-modeling process from Level 1 into something you can run on any diagram in an hour, defense in depth asks what the next layer does when a control fails, and secure design principles make the safe path the default. Practise on the threat-model case studies and in Secure This Architecture.

Before moving on: Review an unfamiliar architecture diagram and produce specific findings, each naming the boundary, the missing control and the layer that would catch its failure.

• Security Review Mode: Any Architecture, Ten QuestionsNot startedLearningPracticingMastered
• Defense in DepthNot startedLearningPracticingMastered
• Secure Software Design PrinciplesNot startedLearningPracticingMastered

Agents add untrusted language, retrieved documents and memory to the input side and tools to the output side. Prompt injection is Level 3's boundary failure in a new costume, the model is never the authorization layer from Level 2, and sandboxing is Level 5's blast-radius question applied to code execution. Last because it reuses every earlier level.

Before moving on: Design an agent so that a prompt injection in a retrieved document cannot trigger a privileged action, with the policy check, the approval step and the sandbox each named.

• AI and Agent SecurityNot startedLearningPracticingMastered
• Direct and Indirect Prompt InjectionNot startedLearningPracticingMastered
• The Model Is Not the Authorization LayerNot startedLearningPracticingMastered
• Agent SandboxingNot startedLearningPracticingMastered