New: Roadmaps ordered paths through our cheat sheets and flashcards, so you always know what to study next.
Explore themSee what's new on GitHubFrom a scanned container image to a release pipeline that only ships what's signed and policy-approved.
A 14-step learning path. Follow it in order, or jump to what you need.
This path is for engineers ready to lock down everything a release pipeline touches: what ships, how it's proven safe, and who can change it. Plan on about 8 to 9 weeks at 3 to 5 hours a week, moving from a shift-left pipeline model through software bills of materials, artifact signing, and policy-as-code enforcement to a fully policy-gated GitOps release flow. It stays on the pipeline and supply-chain side: for the OWASP-level secure coding and auth work inside application code itself, see the Web & Application Security path, and for container and Kubernetes fundamentals, see Docker to Kubernetes. By the end you can generate and verify a software bill of materials, sign container images and enforce that signature at admission with policy as code, and gate a GitOps release so only scanned, signed, policy-compliant artifacts reach production.
Expected: comfort running a CI/CD pipeline and containerized workloads (see the DevOps Engineer or Docker to Kubernetes paths), plus baseline security literacy such as the OWASP Top 10 and secure coding basics (see the Web & Application Security path). Helpful but not required: hands-on experience with a cloud provider's IAM console or Terraform.
Read this today and you can see where security actually lives in a pipeline, the shift-left model this entire path fills in one stage at a time, from the SBOM in step 3 to the GitOps gate that closes it out.
Every scanner from here on hands you a CVE and a severity score, so learning to read CVSS and EPSS now means step 4's scan results tell you what to fix first instead of just what exists.
You can see where DevSecOps actually sits in a pipeline and read a CVE's real urgency instead of chasing every CVSS score you find. Next up: proving what's actually inside the artifacts you scan.
Finish this section to unlock.
+100 XP
Once you can triage a finding, the next question is what's actually in your software: an SBOM turns that guess into a queryable inventory, and it's the format the scanning and signing tools in the next two steps both produce and consume.
Puts the CVSS vocabulary from step 2 and the SBOM format from step 3 into one command: Trivy generates the bill of materials and scores its vulnerabilities in the same pass, right inside your existing pipeline.
This is where supply-chain trust actually clicks: instead of hoping the image step 4 just scanned is the one that ships, Cosign cryptographically proves it, and expect to revisit its SLSA levels as your provenance needs grow.
You can generate a software bill of materials, scan it for real vulnerabilities, and sign the result so a tampered image can't pass for the real one. Next up: keeping what's running as disciplined as what you signed.
Finish this section to unlock.
+100 XP
A signed, scanned image is still worthless if its database password sits in a plaintext environment variable, so this step moves secrets out of pipeline YAML and into a system built to lease and rotate them.
Shifts the focus from what ships to what runs: namespaces, capabilities, and seccomp are the kernel-level controls that keep a compromised container from touching the host it shares with everything else.
Takes the runtime controls from step 7 and turns them into cluster-wide policy: Pod Security Admission enforces the same non-root, no-privilege-escalation rules on every workload instead of trusting each Dockerfile author to remember them.
The declarative shift lands here: instead of reviewing manifests by hand, Kyverno blocks anything that skips step 8's pod security rules or ships an image step 5 never signed, automatically, at admission.
Take this if your org already writes Rego elsewhere: OPA and Gatekeeper enforce the same admission-time checks as step 9 through a general-purpose policy language instead of Kyverno's YAML rules.
You can keep secrets out of your pipeline, lock a container down at the kernel level, and let Kyverno block anything that skips those rules before it reaches a cluster, and a few minutes of due flashcards keeps step 3's SBOM formats fresh while you build policy on top of them. Next up: catching the threats no policy predicted.
Finish this section to unlock.
+100 XP
Every control so far stops a known bad state before it happens; Falco watches for the ones nobody wrote a policy for, catching a shell spawned inside a container or a process reading secrets it never should.
Reach for this if you're architecting access across teams and clouds, not just one cluster: Zero Trust generalizes the least-privilege habits from step 6 and step 9 into identity and network rules that apply everywhere the pipeline can't reach.
Pick this if audits are part of your job: Security Compliance and Governance turns the regulatory drivers step 3's SBOM tables mentioned in passing, like PCI DSS and the EU Cyber Resilience Act, into the control mapping and evidence an auditor actually wants.
Everything up to now proves an artifact is safe in isolation; GitOps is what actually enforces it in production, pulling only the signed, policy-verified image step 9 approved instead of letting anyone deploy around the gate.
You can catch the runtime threats no policy predicted, extend least privilege into a full zero-trust posture, and gate every release through GitOps so only signed, scanned, policy-approved artifacts reach production. That's the Supply Chain Security Practitioner badge, earned.
Finish this section to unlock.
+100 XP
Finish every required step, at least 70% of them genuinely done (not skipped), to earn this badge and 500 XP.