Module 04 · When it happens · 60 min · You are: Platform team
Capstone: team-catalog
In this module
- You learn: Audit a second team hand-over and defend your path analysis.
- You do: Identify fourteen seeded gaps across seven surfaces, rank the cheapest path, test a harmless canary, close two independent boundaries and update both evidence files.
- You end with: Team-catalog has a covered register, an attacker notebook and an evidence-backed hand-over.
A checklist is not a threat model. A defensible audit connects an objective to accepted trust, a pivot, an observable signal and controls.
Open this module in the interactive course to track progress.
Change journey practised: Surface → Test → Measure → Prove
Concepts
- Surface: a second team delivery path
- The capstone fixture contains decoys and controls that already work.
- Trust boundary
- Choose evidence that can falsify a hypothesis before editing controls.
- Evidence
- A valid signature can still represent a build from untrusted input.
Files to know
Open them in your editor or on GitHub; the bullets say what to look at.
start/docs/capstone/team-catalog.yaml(reference): Reference file for the runtime surface.- This line shows the trust boundary or the evidence shape. L1
start/docs/capstone/team-catalog.yaml(reference): Bounded lab fixture for this module.- Use this fixture to test the hypothesis safely. L3
Steps
1. Challenge: hand over the platform to team-catalog (Challenge)
Work from the repository evidence without step-by-step edits. The fixture has fourteen findings across seven surfaces, four decoys, and one control that already works. Update the register and notebook as you investigate.
Done when:
- Rank a falsifiable objective-to-pivot path and explain four decoys.
- Use a fake canary only in the local lab and cite commit, run and policy evidence.
- Close two independent boundaries and rerun the original hypothesis.
- Add surfaces.X01 for the second-team path and set it to covered with a test and evidence.
- Complete docs/attack-path.md, docs/timeline.csv and docs/capstone/team-catalog.yaml; set the capstone status to complete.
- Record residual risk, owner, signal and retest in both evidence files.
Hint 1
Start from the useful capability and work backward to the cheapest input.
Hint 2
Use the timeline to distinguish a cause from a control that already worked.
One solution
A passing configuration check without a defensible path is incomplete.
Compare the selected path against source, workflow, artifact, package, image, admission, runtime and trust evidence. The exact repairs depend on the scenario and should be justified by the evidence.
Simplified for the workshop
The metadata service is a local mock, and its sample credentials open nothing. The CI token verifier uses claims supplied by the workflow and does not contact a cloud provider.
The lab checks parse files only. They never run code from the learner repository.
Break it on purpose: Break it: one of the existing controls is a decoy
A change appears to work because the easiest test is blocked by another control. Lift only the named lab control for one test and isolate the boundary under study.
You practise: You practise separating controls, predicting signals and restoring the runtime to its safe default.
1. Break it
cd devsecops-lab && git diff -- deploy/ infra/
2. What you see
Expected: the tested path stops at this control. You get a request or identity accepted that should have been denied. Compare the observed log with the pre-test prediction.
3. Fix it yourself
Restore the control and prove the same path is denied. Done when the register names the result, owner, evidence and retest date.
Hint 1
Trace the request from application to destination, including the network path.
Hint 2
Test each independent control alone, then restore all of them.
The fix
Follow the module policy files and reapply the default deny before continuing.
cd devsecops-lab && ./scripts/validate.sh
After you fixed it: the five questions
- What failed?
- A runtime or identity boundary allowed an unintended pivot.
- How was it detected?
- The bounded request or verifier returned an unexpected success.
- Who responds?
- The owning team in the register: product for the app, platform for cluster and cloud policy.
- How is it corrected?
- Close the specific boundary and repeat the request or identity test.
- How is it prevented?
- Keep an exact parse-only rule and a dated retest in the shared evidence register.
Quiz
- Why does the metadata mock belong in this lab?
- It provides a bounded local target whose sample credentials open no cloud account.
- It proves that real cloud credentials are safe to expose.
- It removes the need to inspect network policy.
- What does an exact OIDC subject condition do?
- Limits which repository or environment identity may assume the role.
- Encrypts credentials in GitHub logs.
- Proves that every commit is reviewed.
- What is the first response to an unexpected workflow?
- Preserve run and commit evidence, disable the path, and rotate exposed credentials.
- Delete every workflow and erase the repository history.
- Wait until a scanner confirms data was stolen.
Answers
- It provides a bounded local target whose sample credentials open no cloud account. The target must be contained and disposable.
- Limits which repository or environment identity may assume the role. Trust conditions define eligible identities.
- Preserve run and commit evidence, disable the path, and rotate exposed credentials. Containment and evidence both matter; rotate credentials that could be exposed.
Field note
I test the same hypothesis after each control. That shows which layer stopped the path and whether another layer still works.