Security and Compliance Learning Path
Six stages from the trust model through identity, secrets, egress, and supply chain, ending in the regulatory work - ordered so policy arrives after the mechanism that has to enforce it
A route through existing material. Every entry is a page on this site; the value here is the order and the reason for it.
Who This Is For
This path is built on one ordering principle: mechanism before policy. Compliance material is deliberately last, because a control written before you understand what the platform can actually enforce becomes an exception register instead of a control. The regulatory stage lands better when you already know which of its requirements you can evidence and which you cannot.
By the end you should be able to describe the trust boundary around a workspace, distinguish a human identity from an agent identity and scope each one, say where a credential is resolved and who can read it, defend or reject TLS interception on your own traffic, and map a specific regulatory obligation to a specific mechanism rather than to a paragraph of intent.
Stage One: the Trust Model
Ends with you able to say what you are assuming is hostile, and therefore what every later control is protecting against.
First, because it is the assumption the rest of this path is built on: the workspace is not trusted, including by you.
The full threat surface in one place, so the specialist pages that follow have somewhere to attach.
Shared vocabulary with the platform team. Skip it and you will spend a review meeting discovering you meant different things by workspace.
Where the components sit. You cannot draw a trust boundary across a system whose shape you have not seen.
The isolation primitive itself, read before any policy page so you know what the platform can actually contain.
Stage Two: Identity, for People and for Agents
Ends with you able to scope a credential to a single unit of work and explain why a shared service account is not that.
Human identity first - single sign-on, provisioning, roles. It is the model the agent material then deliberately departs from.
Immediately after, so the contrast is sharp: attestation instead of a bootstrap secret, and a credential that names one run.
Where the credential lives once it exists. Reading it here connects storage to the scoping decision you just made.
Who authorizes a grant and who reviews it. Access control without an owner decays into whatever was convenient.
The identity naming scheme and scoped token shape as copyable artifacts, with their caveats attached.
Stage Three: the Network Boundary
Ends with you able to decide, on your own traffic, whether to terminate TLS - and to defend the answer either way.
The general model - segmentation, ingress, and what a default-deny posture actually implies operationally.
The specific case, and the honest trade: path-level rules require decryption, and the proxy that does it becomes your most valuable target.
The stronger containment option, read once you know what you are trying to contain and what escaping would cost you.
How the previous three pages combine on the substrate most teams are already running.
The extreme end of the same spectrum. Useful as a reference point even when it is not your requirement.
Stage Four: Threats Specific to Agents
Ends with you able to explain why instructions in a file are not a control, and what you put in place instead.
The threat model for an autonomous occupant, which is different in kind rather than in degree from a human one.
The attack that makes stages two and three load-bearing rather than theoretical. Read it after both, not before.
Included here specifically for its limits: it is advisory context, not a permission boundary, and teams routinely treat it as one.
What you do when a control fails, including the containment-before-evidence ordering that is easy to get backwards.
The organizational layer over all of it, and the bridge into the regulatory stage that follows.
Stage Five: Supply Chain and Provenance
Ends with you able to say where a given artifact came from and who or what produced the change inside it.
Dependencies, build integrity, and the attestation vocabulary that the regulatory stage will assume you know.
Attribution once an agent is a contributor. This is the question auditors have started asking and few teams can answer.
The distribution point for every workspace image, and therefore a control surface rather than plumbing.
The ongoing obligation, which the Cyber Resilience Act material in the next stage turns from good practice into a duty.
The strongest available answer to reproducibility, and the cost of getting there. Last, because it reframes everything above.
Stage Six: Regulation and Evidence
Ends with you able to map an obligation to a mechanism from the previous five stages, or to name the gap honestly.
The framework overview, now readable as a set of claims you can check against real controls rather than aspire to.
Where code and state physically sit, which is usually the first question and often the one that eliminates vendors.
Obligations that attach to agent use specifically, which is why it comes after the agent stages rather than with compliance.
The product-security counterpart, which lands directly on the supply chain work from stage five.
The index into sector-specific requirements, so you can go straight to yours.
Read only the one that applies to you. Each takes the general controls above and states which are non-negotiable in that sector.
Last, and shared with the engineering manager path: the register where the gaps you could not close get an owner and a date.
Where To Go Next
The two gaps this path deliberately leaves open
Platform Engineer
Policy you cannot implement is policy you will grant exceptions to. That path covers how the platform is actually built and run.
Engineering Manager
Where the vendor questions and the pilot design live, both of which decide what you will be asked to sign off.
All Learning Paths
Back to the index, including the shorter reading order written for individual developers.