Rework

Author: olivomarco

modules/ghas/challenges/00-environment-setup/COACH.md

@@ -2,7 +2,7 @@
 
 ## Objectives
 
-- Facilitate a governed GHAS baseline in `modules/ghas/resources/ghas-governance-practice.template.md`, not merely a completed setup.
+- Facilitate a GHAS configuration and ownership record in `modules/ghas/resources/ghas-governance-practice.template.md`, not merely a completed setup.
 - Help the delivery team select a real repository or service, or explicitly use Juice Shop as the fallback practice target.
 - Ensure the baseline records scope and criticality, enabled and missing GHAS capabilities, and the repository or service owner, security partner, and delivery team.
 - Ensure the baseline records least privilege, human accountability for approval and merge, and normal GHAS and PR validation for agent-originated changes.
@@ -15,14 +15,14 @@
 ## Facilitation Hints
 
 - **Push Codespaces first.** If local setup consumes more than 10 minutes, redirect to Codespaces.
-- Start with the governed baseline. Ask which real repository or service is in scope, why its criticality matters, and whether Juice Shop is only the fallback practice target.
-- Ask for a show-of-hands "green terminal + accountable baseline" check after the first 10 minutes.
+- Start with the GHAS configuration and ownership record. Ask which real repository or service is in scope, why its criticality matters, and whether Juice Shop is only the fallback practice target.
+- Ask for a show-of-hands check after the first 10 minutes: successful commands and a completed record with named owners.
 - Pair any blocked participant with a working neighbor; one blocker should not stall the group.
 - Start by having the responsible participant, team lead, or organizer run:
   `./setup.sh provision ghas-00 --org <org>` or `./setup.ps1 provision ghas-00 -Org <org>`.
 - Verify that **Codespaces is enabled for the org** before the event starts (org Settings → Codespaces → Allow for all members). If not enabled, participants see no Codespace option.
 - If Copilot is not yet licensed for all participants, pair them so every team still practices the Copilot-assisted review loop in S01–S06.
-- Confirm **GHAS is enabled** on the provisioned org repo (Settings → Code security and analysis). CodeQL, secret scanning, Dependabot alerts, and push protection must all be on — these are the backbone of S01–S06.
+- Confirm **GHAS is enabled** on the provisioned org repo (Settings → Code security and analysis). CodeQL, secret scanning, Dependabot alerts, and push protection must all be on — S01–S06 depend on them.
 - Confirm the repository access list includes every participant or team that needs to push a branch. The script creates/configures the repo; it does not guess workshop roster membership.
 - Do not accept a feature toggle or a running storefront as completion by itself. Validate that enabled and missing GHAS capabilities, accountable roles, agentic delivery principles, and blocker ownership and dates are recorded in the baseline.
 - When discussing agentic delivery, keep the scope to the documented principles: least privilege; humans remain accountable for approval and merge; and agent-originated changes receive normal GHAS and PR validation.
@@ -54,7 +54,7 @@ delivery team:
 - [ ] `modules/ghas/resources/ghas-governance-practice.template.md` records the in-scope repository or service and its criticality
 - [ ] Enabled and missing GHAS capabilities are recorded
 - [ ] The repository or service owner, security partner, and delivery team are recorded as accountable roles
-- [ ] The baseline records least privilege, human accountability for approval and merge, and normal GHAS and PR validation for agent-originated changes
+- [ ] The GHAS configuration and ownership record includes least privilege, human accountability for approval and merge, and normal GHAS and PR validation for agent-originated changes
 - [ ] Access or licensing blockers are recorded with an owner and target date
 - [ ] The target repository is accessible, GHAS enablement is verified or recorded as missing, and the working branch is pushed
 - [ ] The delivery environment is usable: `gh auth status` and `gh repo view` succeed, and Juice Shop loads on port 3000 when using the fallback

modules/ghas/challenges/00-environment-setup/README.md

@@ -5,7 +5,7 @@
 By the end of this activity, the delivery team will have:
 
 - Selected a real repository or service to govern, or recorded OWASP Juice Shop as the fallback practice target
-- Recorded a governed GHAS baseline in `modules/ghas/resources/ghas-governance-practice.template.md`
+- Recorded GHAS configuration, scope, and ownership in `modules/ghas/resources/ghas-governance-practice.template.md`
 - Defined the in-scope repository or service, its criticality, enabled and missing GHAS capabilities, and accountable roles
 - Recorded the repository or service owner, security partner, and delivery team accountable for the baseline
 - Recorded initial agentic delivery principles: least privilege; humans remain accountable for approval and merge; and agent-originated changes receive normal GHAS and PR validation
@@ -35,11 +35,11 @@ By the end of this activity, the delivery team will have:
 
 ---
 
-## Establish the Governed GHAS Baseline
+## Record GHAS Configuration and Ownership
 
 Before treating setup as complete, create the first governance record in
 `modules/ghas/resources/ghas-governance-practice.template.md`. This is delivery
-evidence, not a setup checklist. Record:
+record, not a setup checklist. Record:
 
 - the real repository or service selected for this work, or Juice Shop as the fallback;
 - the in-scope repository or service and its criticality;
@@ -50,7 +50,7 @@ evidence, not a setup checklist. Record:
   validation; and
 - every access or licensing blocker, its owner, and its target date.
 
-Use the rest of this activity to substantiate that baseline. If the selected real
+Use the rest of this activity to complete that record. If the selected real
 repository is not ready for hands-on work, use the Juice Shop repository below as the
 practice fallback and keep the real repository or service recorded as the delivery
 scope.
@@ -191,7 +191,7 @@ See [`modules/ghas/setup.md`](../../setup.md) for details on how these two envir
 
 ## Verify Your Setup
 
-Run each command and use the results to update the governed baseline:
+Run each command and use the results to update the GHAS configuration and ownership record:
 
 ```bash
 # 1. CLI version
@@ -211,16 +211,16 @@ git log --oneline -1
 Then open `http://localhost:3000` (or the Codespaces-forwarded URL) and confirm the
 Juice Shop homepage loads.
 
-> Do not let a green terminal close this activity. Before moving on, confirm the
-> governed baseline names the target and criticality, captures GHAS capability status
+> Successful commands alone do not complete this activity. Before moving on, confirm the
+> GHAS configuration and ownership record names the target and criticality, captures GHAS capability status
 > and accountable roles, records the agentic delivery principles, and assigns every
 > access or licensing blocker an owner and target date. See **Common Blockers** in the
 > coach guide when setup cannot yet be completed.
 
 ## Success Criteria
 
 - [ ] A real repository or service is selected, or Juice Shop is recorded as the fallback practice target
-- [ ] The governed baseline in `modules/ghas/resources/ghas-governance-practice.template.md` records the in-scope repository or service and its criticality
+- [ ] The GHAS configuration and ownership record in `modules/ghas/resources/ghas-governance-practice.template.md` records the in-scope repository or service and its criticality
 - [ ] Enabled and missing GHAS capabilities are recorded
 - [ ] The repository or service owner, security partner, and delivery team are recorded as accountable roles
 - [ ] The baseline records least privilege, human accountability for approval and merge, and normal GHAS and PR validation for agent-originated changes

modules/ghas/challenges/00-environment-setup/meta.yml

@@ -12,7 +12,7 @@ prerequisite_capabilities:
   - GitHub Advanced Security available for the repository visibility you choose
   - GitHub Copilot license assigned
 description: >
-  Establish a governed GHAS baseline for a real repository or service, or use OWASP
+  Document GHAS configuration, scope, and ownership for a real repository or service, or use OWASP
   Juice Shop as the fallback practice target. Record scope, criticality, enabled and
   missing GHAS capabilities, accountable roles, agentic delivery principles, and
   access or licensing blockers with owners and target dates in
@@ -21,7 +21,7 @@ description: >
   Activity S01.
 success_criteria:
   - "A real repository or service is selected, or Juice Shop is recorded as the fallback practice target"
-  - "The governed baseline in `modules/ghas/resources/ghas-governance-practice.template.md` records the in-scope repository or service and its criticality"
+  - "The GHAS configuration and ownership record in `modules/ghas/resources/ghas-governance-practice.template.md` records the in-scope repository or service and its criticality"
   - "Enabled and missing GHAS capabilities are recorded"
   - "The repository or service owner, security partner, and delivery team are recorded as accountable roles"
   - "The baseline records least privilege, human accountability for approval and merge, and normal GHAS and PR validation for agent-originated changes"

modules/ghas/challenges/01-explore-attack-surface/COACH.md

@@ -2,7 +2,7 @@
 
 > Audience: facilitators and coaches. Pair with the delivery team member `README.md`.
 
-## Grounding conversation (you will be called)
+## Required coach check-in
 
 **Required coach check-in:** before completion, ask the customer practitioner to connect the exercise to work they actually own.
 
@@ -12,13 +12,13 @@ should its next action and target date be?
 
 Use these follow-ups to steer the conversation:
 - Which specific repo or service in your work would have the most GHAS alerts today — name it, then describe what kind of code lives there and who owns it.
-- For that repo, which alert category — code scanning, Dependabot, or secret scanning — do you think carries the highest real-world blast radius if an attacker found it first?
+- For that repo, which alert category — code scanning, Dependabot, or secret scanning — would affect the most systems or data if an attacker found it first?
 - Is remediation the right route, or is accepted risk appropriate? Who has authority to own that decision?
 - What one concrete action could you take this week to start reducing the security debt you just described?
 
 ## Facilitation objectives
 - Reinforce how customer delivery team members navigate CodeQL, Dependabot, and secret scanning alerts in the shared repository.
-- Help customer delivery team members create an owned security-debt inventory in `modules/ghas/resources/ghas-governance-practice.template.md`, using their application first and Juice Shop only as the fallback.
+- Help customer delivery team members create a security findings register with named owners in `modules/ghas/resources/ghas-governance-practice.template.md`, using their application first and Juice Shop only as the fallback.
 - Guide impact, remediation route, accountable ownership, target date, current disposition, and prioritization rationale—not vulnerability labels alone.
 - Encourage customer delivery team members to use Copilot Chat to explain exploitability, then verify each explanation against the alert and actual code path.
 
@@ -40,7 +40,7 @@ Verify each success criterion from the customer delivery team guide:
 - [ ] A real application repository or service is used first, or Juice Shop is recorded as the fallback practice target
 - [ ] At least 5 alerts are reviewed with full alert detail read and used as evidence for the inventory
 - [ ] Each reviewed alert has a Copilot explanation of the vulnerability, attacker outcome, and code location that a human verifies against the alert and code path
-- [ ] The security-debt inventory in `modules/ghas/resources/ghas-governance-practice.template.md` records alert category or class, affected repository, service, or component, business or security impact, remediation route, accountable owner or team, target date, current disposition, and prioritization rationale for each item
+- [ ] The security findings register in `modules/ghas/resources/ghas-governance-practice.template.md` records alert category or class, affected repository, service, or component, business or security impact, remediation route, accountable owner or team, target date, current disposition, and prioritization rationale for each item
 - [ ] Each inventory item has a current disposition of open, in progress, or accepted risk and a prioritization rationale
 - [ ] Dependabot alerts are reviewed and any critical or high-severity dependency vulnerabilities are recorded in the inventory
 - [ ] Coach conversation connects the inventory to a real project, accountable ownership, risk, and next action
@@ -52,4 +52,4 @@ Verify each success criterion from the customer delivery team guide:
 | Operable inventory | 25 | Recorded all required fields, including impact, route, owner, date, disposition, and rationale. |
 | Copilot-assisted reasoning | 20 | Used Copilot to explain exploitability, then verified the explanation against alert traces and code. |
 | Prioritization and risk | 15 | Chose a disposition and priority based on business or security impact, ownership, and remediation route. |
-| Grounding conversation | 15 | Connected inventory items to a real team repo or service, accountable ownership, risk, and next action. |
+| Coach check-in | 15 | Connected findings to a real team repo or service, accountable ownership, risk, and next action. |

modules/ghas/challenges/01-explore-attack-surface/README.md

@@ -7,7 +7,7 @@ Before you fix anything, you need to understand what you're dealing with. GHAS i
 Juice Shop is intentionally vulnerable. The alerts you'll see aren't theoretical — they're real exploitable flaws in real code. SQL injection that lets attackers bypass authentication. XSS that can hijack user sessions. Broken access control that exposes data it shouldn't. Your job in this activity is to read those alerts, open the affected files, and use Copilot to understand exactly what the code is doing wrong.
 
 This is your reconnaissance phase. Turn the alerts into an owned security-debt
-inventory that the delivery team can operate after the session, rather than a
+findings register that the delivery team can operate after the session, rather than a
 temporary mental model.
 
 > **Before this activity:** Make sure S00 is complete, the org repo exists, required participants have been added, GHAS features are enabled, and you've created your team branch. The Security tab is default-branch oriented. Your branch fixes will be validated later through PR CodeQL checks and code scanning annotations.
@@ -18,7 +18,7 @@ temporary mental model.
 - Navigate to the relevant GHAS alerts, including **Security → Code scanning alerts**, and review the open default-branch alerts
 - Review at least 5 alerts in full — location, description, and the code path that triggers each finding
 - For each reviewed alert, open the affected file in your editor, ask Copilot Chat: *"What does this code do wrong, and how could an attacker exploit it?"*, and verify the explanation against the alert and code path
-- Create an owned security-debt inventory in `modules/ghas/resources/ghas-governance-practice.template.md`
+- Create a security findings register with named owners in `modules/ghas/resources/ghas-governance-practice.template.md`
 - For every inventory item, record the alert category or class, affected repository, service, or component, business or security impact, remediation route, accountable owner or team, target date, current disposition (open, in progress, or accepted risk), and prioritization rationale
 - Use the five alert reviews as evidence supporting the inventory and its prioritization
 - Check **Security → Dependabot alerts** and record any critical or high-severity dependency vulnerabilities in the inventory
@@ -39,7 +39,7 @@ temporary mental model.
 - [ ] A real application repository or service is used first, or Juice Shop is recorded as the fallback practice target
 - [ ] At least 5 alerts are reviewed with full alert detail read and used as evidence for the inventory
 - [ ] Each reviewed alert has a Copilot explanation of the vulnerability, attacker outcome, and code location that a human verifies against the alert and code path
-- [ ] The security-debt inventory in `modules/ghas/resources/ghas-governance-practice.template.md` records alert category or class, affected repository, service, or component, business or security impact, remediation route, accountable owner or team, target date, current disposition, and prioritization rationale for each item
+- [ ] The security findings register in `modules/ghas/resources/ghas-governance-practice.template.md` records alert category or class, affected repository, service, or component, business or security impact, remediation route, accountable owner or team, target date, current disposition, and prioritization rationale for each item
 - [ ] Each inventory item has a current disposition of open, in progress, or accepted risk and a prioritization rationale
 - [ ] Dependabot alerts are reviewed and any critical or high-severity dependency vulnerabilities are recorded in the inventory
 - [ ] Coach conversation connects the inventory to a real project, accountable ownership, risk, and next action

modules/ghas/challenges/01-explore-attack-surface/meta.yml

@@ -14,13 +14,13 @@ description: >
   Use a real application repository or service first, with Juice Shop as the fallback
   practice target. Review GHAS alerts, verify Copilot explanations against the alert
   and code path, and turn at least five alert reviews into evidence for an owned
-  security-debt inventory in `modules/ghas/resources/ghas-governance-practice.template.md`
+  security findings register in `modules/ghas/resources/ghas-governance-practice.template.md`
   with impact, remediation, ownership, dates, disposition, and prioritization rationale.
 success_criteria:
   - A real application repository or service is used first, or Juice Shop is recorded as the fallback practice target
   - At least 5 alerts are reviewed with full alert detail read and used as evidence for the inventory
   - Each reviewed alert has a Copilot explanation of the vulnerability, attacker outcome, and code location that a human verifies against the alert and code path
-  - The security-debt inventory in `modules/ghas/resources/ghas-governance-practice.template.md` records alert category or class, affected repository, service, or component, business or security impact, remediation route, accountable owner or team, target date, current disposition, and prioritization rationale for each item
+  - The security findings register in `modules/ghas/resources/ghas-governance-practice.template.md` records alert category or class, affected repository, service, or component, business or security impact, remediation route, accountable owner or team, target date, current disposition, and prioritization rationale for each item
   - Each inventory item has a current disposition of open, in progress, or accepted risk and a prioritization rationale
   - Dependabot alerts are reviewed and any critical or high-severity dependency vulnerabilities are recorded in the inventory
   - Coach conversation connects the inventory to a real project, accountable ownership, risk, and next action