security-foundations
Security Foundations
The cross-cutting base every engineer needs to reason about security: threat modeling, cryptography you can actually use, identity, network security, and access-control models.
Start track →Start here
What the cybersecurity cluster covers and the path from engineer to security-competent.Threat modeling
Find design-level security problems before code exists, by reasoning about what you're building, what can go wrong, and what to do about it.Cryptography for engineers
Use crypto correctly without inventing it: hashing vs encryption vs signing, AEAD, key management, TLS and PKI.Authentication and identity
Prove who a user is and keep that proof: passwords to MFA to passkeys, sessions vs tokens, SSO and federation.Network security
Defend data in motion and the network itself: TLS depth, mTLS, segmentation, DNS security, zero-trust.Access control models
Decide who may do what to which resource: RBAC, ABAC, ReBAC, least privilege, and authz at scale.Build with this track
Guided projects that exercise what you learn here.
Authorized Recon-to-Remediation Lab
Stand up an intentionally-vulnerable target you own — a deliberately-broken app in a local container or a CTF box on your own machine — and run a full offensive engagement against it, end to end, on a scope you signed off yourself. You recon the box, pick one class of vulnerability, prove it with a working exploit in the lab, and then turn around and write the fix and the detection. The point isn't to 'pop a box'; it's to live the whole loop a real engagement runs — scope, evidence, impact, remediation — on a target where nobody gets hurt.
Cloud Hardening Lab
Take a cloud account you own and drag it from 'it works' to 'it's defensible'. You'll measure the posture you actually have, tighten IAM to least privilege without breaking the app, lock down the network and secrets, and prove every change with a before/after diff. This is the core of cloud security work: not adding features, but removing the standing access and quiet misconfigurations that an attacker would have used.
Homelab Secure Stack
Stand up a self-hosted media and home-server stack on nas01.example where five services share a single VPN container's network namespace — the kill-switch drops all traffic the moment the tunnel dies, a split-tunnel whitelist carves out LAN access, and three layered access rings (localhost / LAN 10.0.0.0/24 / mesh-VPN 100.64.0.30) keep the right doors open to the right people. Harden the host with SSH key-only auth, fail2ban, and unattended security upgrades; write a rotating, age-encrypted off-site backup; and walk away knowing the stack stays dark if anything breaks.
Threat-Model and Harden a Small App
Take a small app you fully own and run it through the loop a real security engineer lives in: first map how an attacker would actually break it, then close those paths one by one. You build an attack tree against your own service, then fix authentication, authorization, secrets handling, security headers, and input validation — and write down which fix kills which branch of the tree. This is the whole craft of defensive security in miniature: not a checklist, but a chain from threat to mitigation you can defend out loud.
Offensive Security
How attacks actually work, lab-framed and ethics-first: recon, web and infrastructure exploitation, and pentest methodology — so you can defend and read a findings report.