How to run a plan

  • Each week, everyone does the listed work on their own: read the guides, repair the browser labs and open the fix card for the stack the team uses. The time shown is for the guides, labs and projects; fix cards and capstones add more.
  • Then meet for about an hour. Start with the discussion prompts, applied to your own systems, then do the exercises together or in pairs. Keep what each exercise produces: the paths list the evidence to keep at every step.
  • After a capstone, have pairs score each other with its rubric before anyone opens the worked assessment. Capstone workbooks can be downloaded from each path page.
  • Progress stays in each person’s browser. At the end of a plan, ask everyone to export it from any learning page and combine the files below to see where the team stands.

Completion is a personal bookmark, not a certification: it records that someone marked a step complete on their device, not what they can do. Use the capstone rubrics and the exercises’ work products to judge skill.

Six-week plan: web and API teams

Developer foundations, then Browser and API boundaries: the core defects of web applications and APIs, with a browser lab and fix cards most weeks and a capstone after each path.

For
Application developers, and the AppSec engineer who supports them
Sessions
One 60-minute session a week, after individual work.

Week 1: Keep data out of queries, and check every object

Developer foundations · about 1–1.5 hours of individual work

Work

Goals

  • Explain why a bound parameter cannot become SQL syntax, and show it with an ordinary and a hostile input.
  • Decide access from the caller and the stored object, never from an ID or tenant the request supplies.

Discussion prompts

  • Where in our code is a query, command or filter still assembled from strings, and which test would catch it?
  • For one endpoint we own, where do the actor, tenant and owner come from: the session, the route, the body or the stored row?
  • What does a passing authorization test have to show besides "the owner can read it"?

Exercises

  • Each person repairs the authorization lab and brings its result summary to the session.
  • Together, fill in a permission matrix (owner, same-tenant non-owner, other tenant) for one real endpoint, and open the SQL injection fix card for your stack to compare its vulnerable, fixed and wrong versions.

Week 2: Files, secrets and webhooks

Developer foundations · about 2 hours of individual work

Work

Goals

  • Trace an uploaded file from receipt to download and name who can move it between states.
  • Tell removing, rotating and revoking a credential apart, and verify a webhook before acting on it only once.

Discussion prompts

  • If one of our API keys leaked today, which copies and consumers would we have to find before rotation counts as done?
  • When an uploaded file becomes reachable by other users, what has checked it, and could a renamed file skip that check?
  • Our payment or source-control webhooks are delivered at least once: what stops a retry from repeating the effect?

Exercises

  • Each person repairs the webhook lab, then writes the five-boundary decision table from the webhook guide for one webhook the team receives.
  • Pairs write a credential lifecycle record for one real secret (its owner, consumers and revocation steps, never its value).

Week 3: Carry the repairs into a real API, then the first capstone

Developer foundations · about 1 hours of individual work

Work

Goals

  • Run a real HTTP API test suite and repair invoice authorization and the profile update.
  • Produce release evidence for a change that combines query safety, tenancy, file state and webhooks.

Discussion prompts

  • Which request fields does our own profile or settings update accept, and which should it ignore?
  • In the capstone, which problems are independent, and which fix would a reviewer most likely miss?
  • What evidence would we accept before releasing a change like this one?

Exercises

  • Each person runs the Express project until its tests pass and keeps the failing and passing output.
  • Work the Developer foundations capstone in pairs before opening the worked assessment, then score each other with its rubric.

Week 4: Browser boundaries: request forgery, CORS, CSP and rich text

Browser and API boundaries · about 1.5–2 hours of individual work

Work

Goals

  • State which origins may cause a state change, and enforce it on the server.
  • Keep CORS, Content Security Policy and output handling apart: each permits and blocks different things.

Discussion prompts

  • Which of our state-changing requests rely on cookies, and what does the server check about where they come from?
  • Do we allow credentialed cross-origin requests anywhere, and from which origins exactly?
  • Where do we render user-supplied rich text, and what does the renderer allow?

Exercises

  • Each person repairs the CSRF lab and records an ordinary and a forged request outcome.
  • Together, list one page that renders user content and write its renderer contract: allowed elements, URLs and network effects.

Week 5: Operations, fields and concurrent requests

Browser and API boundaries · about 1.5–2 hours of individual work

Work

Goals

  • Authorize privileged operations and writable fields separately from object access.
  • Hold a business invariant, such as a balance or stock count, when two requests arrive together.

Discussion prompts

  • Which of our update endpoints bind a request body straight onto a model?
  • Name one place where we check a value and then write it in separate steps. What happens if two requests interleave?
  • How would we test a race in CI rather than by luck?

Exercises

  • Each person repairs the checkout race lab and compares the final balance with the invariant.
  • Pairs build a function and property permission matrix for one admin or update operation the team owns.

Week 6: Frameworks and file paths, then the second capstone

Browser and API boundaries · about 1 hours of individual work

Work

Goals

  • Check that a new route keeps the framework’s protections from registration to response.
  • Treat an archive entry name as untrusted input to the file system.

Discussion prompts

  • Which of our routes are registered outside the usual middleware chain, and what do they lose?
  • Where do we extract archives or join user input to a path?
  • What did the six weeks change in how we review a pull request?

Exercises

  • Each person repairs the archive paths lab.
  • Work the Browser and API boundaries capstone in pairs, score it with its rubric, and combine the team’s progress files below to see who has finished which steps.

Twelve-week plan: product security for a cross-functional team

The six-week plan, then AppSec in practice and From source to trusted release: design review, finding-to-release evidence, SBOMs, CI, signatures, provenance and VEX.

For
Developers, AppSec engineers and the platform or build engineers who ship with them
Sessions
One 60-minute session a week; weeks 1 to 6 are the six-week plan.

Weeks 1 to 6: follow the six-week plan.

Week 7: Threat model a tenant boundary

AppSec in practice · about 0.5 hours of individual work

Work

Goals

  • Trace one tenant operation through every service, worker and store, including the paths a happy-path diagram leaves out.
  • Turn a trust-boundary concern into an abuse case with a test that can fail.

Discussion prompts

  • Where does tenant identity enter our system, and where could a worker or cache lose it?
  • Which of our features have a background job, export or admin path that reads across tenants?
  • What makes an abuse case testable rather than a worry?

Exercises

  • Run the Review a design workflow on one real feature and fill in its blank work product.
  • Each person writes one abuse case with preconditions, asset, forbidden effect and test oracle.

Week 8: From finding to verified release

AppSec in practice · about 1 hours of individual work

Work

Goals

  • Judge a dependency advisory by installed version, deployed artifact and reachable behavior.
  • Tie the tests that passed to the artifact that ships.

Discussion prompts

  • For our last dependency alert, how did we decide whether we were exposed, and what closed it?
  • Could the artifact we deploy differ from the one CI tested? How would we know?
  • What is the smallest evidence packet a reviewer needs to approve a security fix?

Exercises

  • Take one open scanner finding through the Fix a finding workflow and keep its work product.
  • Work the AppSec in practice capstone in pairs and score it with the rubric.

Week 9: Know what you ship: SBOMs

From source to trusted release · about 2 hours of individual work

Work

Goals

  • Generate an SBOM for the artifact that ships, not only for the source tree.
  • Explain every difference between two releases’ inventories.

Discussion prompts

  • Which of our components would a source-only SBOM miss?
  • Who would read our SBOM, and what would they need it to say?
  • What changed in our last release that an inventory diff would have shown?

Exercises

  • Each person repairs the SBOM inventory lab.
  • Generate an SBOM for one of the team’s release artifacts and inspect it with the SBOM checker; list what it does not say.

Week 10: Dependency risk and untrusted CI input

From source to trusted release · about 1.5 hours of individual work

Work

Goals

  • Prioritize a dependency finding with exploitation evidence and reachability, not severity alone.
  • Find where output from untrusted contributions reaches a privileged workflow.

Discussion prompts

  • Which of our workflows run on events from forks, and what can they read or write?
  • In the tj-actions compromise, which control would have stopped our pipelines from running the changed code?
  • How do we pin third-party actions today, and who reviews the updates?

Exercises

  • Triage one real dependency finding with the guide’s closure table.
  • Review the team’s CI workflows for third-party actions pinned by tag and for privileged steps that consume artifacts from untrusted runs.

Week 11: Signatures, provenance and VEX

From source to trusted release · about 2 hours of individual work

Work

Goals

  • Accept an artifact only from the expected signer for the expected subject.
  • Read provenance and VEX as scoped claims whose evidence can be checked.

Discussion prompts

  • If an attacker signed a release with a valid key of their own, would our verification reject it?
  • What does our provenance actually prove, and what does it leave out?
  • When a supplier says "not affected", what evidence do we ask for?

Exercises

  • Each person repairs the artifact policy lab with the expected producer, wrong producer and altered subject cases.
  • Write the signer and subject policy the team would enforce at promotion.

Week 12: Release decision capstone and retrospective

From source to trusted release · about 0.5 hours of individual work

Work

Goals

  • Reject a release whose documents are each valid but describe different things.
  • Agree what the team will keep doing after the plan ends.

Discussion prompts

  • In the capstone, which document would you have trusted first, and why was that a mistake?
  • The xz Utils backdoor was in the release tarball, not the repository: do we build from tracked source?
  • Which three practices from the twelve weeks will we make part of review or CI?

Exercises

  • Work the From source to trusted release capstone in pairs and score it with the rubric.
  • Combine the team’s progress files below and agree a follow-up path for each person.

Other roles

For platform, identity, AI and security-lead roles, the role tracksput the paths in order with their total time. Plan one path every two to three weeks, with the same weekly session.