docs: update 'Reporting page' references to 'Vulnerability Triage'

Updated all human-readable references in documentation to reflect the
page rename. File path citations in security-audit-2026-04-01.md
(ReportingPage.js:51) are left unchanged as the file itself was not
renamed.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

docs/security-posture-workflow-diagrams.md

@@ -9,7 +9,7 @@ Renders natively in GitHub, GitLab, and most modern documentation tools.
 
 ```mermaid
 flowchart TD
-    START([Open Reporting Page]) --> SYNC
+    START([Open Vulnerability Triage Page]) --> SYNC
 
     SYNC["① Sync & Sort<br/>Click Sync · Sort Due Date ascending"]
     SYNC --> DUE{Overdue<br/>findings?}
@@ -94,11 +94,11 @@ flowchart TD
 
 ## Diagram 2 — FP Workflow Badge Status Decision Tree
 
-What to do when a finding already has a workflow badge in the Reporting page.
+What to do when a finding already has a workflow badge in the Vulnerability Triage page.
 
 ```mermaid
 flowchart LR
-    A([Finding in<br/>Reporting Page]) --> B{"Check<br/>Workflow column"}
+    A([Finding in<br/>Vulnerability Triage]) --> B{"Check<br/>Workflow column"}
 
     B -->|No badge| C["UNTRIAGED<br/>No action on record"]
     C --> C1(["Follow the<br/>Step 1–5 triage workflow ↑"])

docs/team-training-agenda.md

@@ -0,0 +1,158 @@
+# STEAM Security Dashboard — Team Training Agenda
+
+**Session length:** 30–40 minutes
+**Format:** Live walkthrough (share your screen on the dashboard)
+**Reference docs:** `security-posture-workflow.md` for full detail on anything covered here
+
+---
+
+## Pre-meeting prep
+
+- Have the dashboard open and logged in before the meeting starts
+- Sync Vulnerability Triage page so data is fresh when you get there
+- Print or share `security-posture-workflow.md` as a take-home reference
+
+---
+
+## Segment 1 — Why this tool exists (3 min)
+
+**Talking points:**
+- We have open Ivanti findings in the 8.5–9.9 VRR range — these are the ones we own and are accountable for
+- Every finding needs a documented action within **60 days of detection** (the SLA rule)
+- Findings that age past their Due Date make a device non-compliant in AEO posture reporting
+- This dashboard is how we track, triage, and prove we've actioned everything — replaces manual spreadsheet tracking
+
+---
+
+## Segment 2 — Dashboard orientation (4 min)
+
+**Show on screen:** Navigate through each page in the nav drawer
+
+- **Home (CVE Management)** — our CVE research library; this is where we store screenshots, advisories, and Archer EXC numbers against each CVE/vendor pair
+- **Vulnerability Triage (Host Findings)** — the daily operational page; this is where you spend most of your time
+- **Compliance** — AEO posture data uploaded from the NTS_AEO xlsx; shows metric health per team
+- **Knowledge Base** — internal docs, runbooks, advisories
+- **Exports** — bulk data extracts when needed
+
+> Tell the team: *"The Vulnerability Triage page is what we'll focus on today — that's where the workflow lives."*
+
+---
+
+## Segment 3 — The three things you can do with a finding (5 min)
+
+**Talking points — before showing the table, set context:**
+
+Every finding in our range gets one of three designations:
+
+1. **Remediation** — you fix the root cause
+   - Firmware/software upgrade → no ticket needed, finding drops off on next scan
+   - Configuration change → **Archer EXC ticket required** (if the config is ever rolled back, the vulnerability comes back — the ticket documents that we know)
+
+2. **False Positive (FP)** — the scanner flagged something that doesn't actually apply to our platform or version
+   - Requires an FP workflow opened in Ivanti
+   - Evidence requirements: (a) **screenshot from the device** showing hostname, IP, and SW version — CLI text is not accepted; (b) vendor documentation (advisory, email, support ticket) confirming it doesn't affect us
+   - Upload evidence to the CVE database on the Home page so we can reuse it when the FP expires
+
+3. **Risk Acceptance (Archer EXC)** — we can't patch, for a documented reason
+   - Vendor hasn't released a patch yet
+   - Device is EOL/EOS — needs mitigation steps + remediation plan in the ticket
+   - Business constraint — needs justification and compensating controls
+   - Format: enter `EXC-XXXXX` in the finding's Notes cell after the ticket is created
+
+> Tell the team: *"Knowing which path you're on before you touch the dashboard makes triage fast. The workflow is just deciding which of these three it is."*
+
+---
+
+## Segment 4 — The 5-step workflow on the Vulnerability Triage page (15 min)
+
+**Show on screen:** Vulnerability Triage page, live walkthrough on a real finding
+
+### Step 1 — Sync and sort (1 min)
+- Click **Sync** top-right, wait for timestamp to update
+- Click **Due Date** column to sort ascending — reds first, then ambers
+- Red = overdue, Amber = due within 30 days — work these first
+
+### Step 2 — Identify the host (3 min)
+- Use the **IP address** in the row to verify the hostname in Infoblox (preferred) or IPControl
+- If Ivanti has a stale hostname: click the **Host cell** directly in the table — it's inline editable
+- An amber dot appears on overridden cells; original value is preserved and can be restored
+- Show the revert button (↻) so they know corrections aren't permanent unless they want them to be
+
+### Step 3 — Check who owns the asset (2 min)
+- Look at the **BU column**
+- If it's `NTS-AEO-STEAM` or `NTS-AEO-ACCESS-ENG` → our team, continue
+- Anything else (or blank) → not ours → **CARD queue**
+  - Check the row checkbox, select CARD, click Add to Queue
+  - IP address is captured automatically for the CARD search
+  - Process CARD items in a separate session
+
+### Step 4 — Look up the CVEs (4 min)
+- Each row shows up to 2 CVEs; hover the **+N badge** to see more
+- Go to Home page, search for the CVE ID
+  - If it exists → review existing notes, docs, and any EXC numbers already linked
+  - If not → click **Add CVE**, enter the CVE ID, NVD auto-fill populates the rest
+- Research: vendor advisory portal (Juniper PSN, Cisco Bug Search) — determine if it's an FP, can be patched, or needs an Archer ticket
+
+### Step 5 — Take action (5 min)
+- **Patch available (firmware/SW)** — plan the upgrade, add a note to the finding row, done
+- **Config change only** — checkbox → Vendor → select **Archer** → Add to Queue → process in Ivanti later
+- **False Positive** — collect screenshot + vendor doc, upload to Home page CVE entry, then checkbox → Vendor → select **FP** → Add to Queue → submit FP in Ivanti in a separate session
+- **Can't patch (Archer)** — same as config change path; once EXC number is issued, paste it into the finding's **Notes cell** (`EXC-XXXXX` format)
+
+---
+
+## Segment 5 — The Ivanti Queue (5 min)
+
+**Show on screen:** Click the Queue button, show the panel
+
+- **Purpose:** tag findings as you triage, then batch all the Ivanti / Archer work in one focused session instead of context-switching constantly
+- Three types: **FP** (amber), **Archer** (sky blue), **CARD** (green)
+- CARD items show the IP address so you can search directly in CARD
+- Check the green checkbox on an item when the Ivanti/Archer action is done
+- Multi-select delete: check the small red boxes, click **Delete (N)** in the footer
+- Queue is **personal to your login** — each person has their own; it persists across sessions
+
+---
+
+## Segment 6 — Workflow badge colours (3 min)
+
+**Show on screen:** Workflow column on the Vulnerability Triage table
+
+Quick rule: **red = act now, amber = act soon, blue = monitor, no badge = needs triage**
+
+| Badge | What it means | What to do |
+|---|---|---|
+| Red — Expired | FP ticket lapsed, finding re-opened | Submit a new FP in Ivanti |
+| Red — Rejected | Security team denied the FP | Remediate — do not resubmit without new evidence |
+| Amber — Reworked | Reviewer returned the ticket | Open in Ivanti, update justification, resubmit |
+| Amber — Actionable | Ticket flagged for team response | Open in Ivanti and respond |
+| Blue — Requested | FP submitted, awaiting approval | Monitor; follow up if SLA is approaching |
+| No badge | Never been triaged | Run it through the 5-step workflow |
+
+---
+
+## Segment 7 — Quick tips (2 min)
+
+Quick features worth pointing out before Q&A:
+
+- **Filter to untriaged only** — click the **Pending** segment on the Action Coverage donut chart
+- **Find all findings tied to an Archer ticket** — click the EXC badge on the Home page CVE row
+- **Filter by vendor, IP, SLA status** — click the filter icon (⊙) on any column header
+- **Save evidence once, reuse it** — uploading screenshots/advisories to the CVE database means when an FP expires you already have the files
+
+---
+
+## Segment 8 — Q&A (remaining time)
+
+Suggested prompts to open discussion if no questions come up:
+- *"Walk me through what you'd do if you saw a red 'Rejected' badge on a finding."*
+- *"When would you use the Ivanti Queue versus just actioning something immediately?"*
+- *"What's the difference between Path B (config change) and Path D (risk acceptance) — when does each apply?"*
+
+---
+
+## Takeaway for the team
+
+Point them to:
+- `docs/security-posture-workflow.md` — the full process guide with all the steps, evidence requirements, and decision matrix
+- `docs/security-posture-workflow-diagrams.md` — the Mermaid flowcharts if they're visual learners