dashboard

# Vulnetix Vulnerability Dashboard ## Use when - You want a single view of every vulnerability tracked in this repo, grouped by status and decision. - Someone asks "where did we leave triage last week?". - Onboarding to a repo and you want to see prior security decisions before duplicating work. - You want to spot stale `under_investigation` items that need re-triaging. - Pre-release: confirm no high-severity entries remain open before tagging. ## Don't use for - Fetching new vulnerability data — use `repo-impact` for whether an advisory reaches this repository, or `vulnetix_vuln` / `vulnetix vdb vuln <id>` for the advisory itself. - Applying fixes — use `fix`. - Cross-repo dashboards — this skill reads only the current repo's memory file. ## Conventions Follows `skills/_lib/contract.md`. In short: use the `vulnetix_*` MCP tools when the agent has them and the CLI otherwise — both shape their own output, so there is no jq step any more. Independent calls go out as concurrent Bash tool calls in one message. One trailing suggestion, not a playbook. See the contract for surface selection, output style and memory writes. This skill reads `.vulnetix/memory.yaml` and displays a comprehensive vulnerability status report. It is read-only and does not modify any files. ## Workflow ### Step 1: Load Memory 1. Use **Glob** to check if `.vulnetix/memory.yaml` exists in the repo root 2. If it does not exist, display: **"No vulnerability data found. Run `repo-impact <CVE-…>` or `vulnetix_exploits` (MCP) to start tracking."** and stop. 3. Use **Read** to load the full contents of `.vulnetix/memory.yaml` ### Step 2: Parse and Categorize From the `vulnerabilities:` section, categorize each entry: **Open (unresolved):** - `status: affected` -- "Vulnerable" - `status: under_investigation` -- "Investigating" **Resolved:** - `status: fixed` -- "Fixed" - `status: not_affected` -- "Not affected" - Entries with `decision.choice: risk-accepted` -- "Risk accepted" - Entries with `decision.choice: deferred` -- "Deferred" From the `manifests:` section, collect manifest tracking info. ### Step 3: Display Summary Header ``` Vulnetix Security Dashboard ============================ Open: <N> (<X> vulnerable, <Y> investigating) Resolved: <N> (<X> fixed, <Y> not affected, <Z> risk-accepted, <W> deferred) Manifests tracked: <N> (last scan: <timestamp>) ``` If there are zero vulnerabilities and zero manifests, display: **"Clean slate -- no vulnerabilities tracked yet."** ### Step 4: Open Vulnerabilities Table If there are open vulnerabilities, display them sorted by CWSS priority (P1 first), then by severity: ``` Open Vulnerabilities -------------------- | ID | Package | Severity | Status | Priority | Decision | |----|---------|----------|--------|----------|----------| | CVE-2021-44228 | log4j-core | critical | Vulnerable | P1 (87.5) | investigating | | GHSA-xxxx-yyyy | express | high | Investigating | P2 (62.0) | investigating | ``` For each column: - **ID**: Primary vulnerability key - **Package**: `package` field - **Severity**: `severity` field - **Status**: Developer-friendly status (see VEX mapping above) - **Priority**: `cwss.priority` and `cwss.score` if available, otherwise "--" - **Decision**: `decision.choice` if available, otherwise "--" ### Step 5: Resolved Vulnerabilities Table If there are resolved vulnerabilities, display them: ``` Resolved Vulnerabilities ------------------------ | ID | Package | Severity | Resolution | Decision | Date | |----|---------|----------|------------|----------|------| | CVE-2023-1234 | lodash | high | Fixed | fix-applied | 2024-01-15 | ``` For the **Date** column, use the most recent `history` entry timestamp, or `discovery.date` as fallback. ### Step 6: Manifest Tracking If manifests are tracked, display: ``` Tracked Manifests ----------------- | Manifest | Ecosystem | Last Scanned | Vulns Found | |----------|-----------|--------------|-------------| | package.json | npm | 2024-01-15T10:30:00Z | 3 | | go.mod | go | 2024-01-15T10:31:00Z | 0 | ``` ### Step 7: Suggested Actions For each open vulnerability (up to 5), suggest a next action based on its state: - Has no `threat_model` or `cwss`: `"vulnetix vdb exploits <id>"` -- get exploit analysis and priority scoring - Has `cwss` but no fix applied: `"fix <id>"` -- get fix intelligence - Has decision `risk-accepted`, `deferred`, or `mitigated` (non-patch): `"vulnetix vdb traffic-filters <id>"` -- get Snort rules for network-level mitigation - General: `"fix <id>"` -- get a full remediation plan If there are more than 5 open vulns, add: `"Use vulnetix vdb exploits to find exploited vulnerabilities across your ecosystem."` Always end with: `"Use vulnetix vdb vuln <id> for detailed info on any vulnerability."` ## Edge cases & gotchas - Reads `.vulnetix/memory.yaml` only. If the file is missing, the skill exits silently — run `repo-impact` or `vulnetix_vuln` (MCP) or `vulnetix vdb vuln <id>` first to populate. - `decision.choice` is a closed enum; entries with arbitrary strings render under "Unknown decision". - Mermaid pie chart of decisions is auto-skipped if the total is < 3 (avoids rendering near-empty visuals). - For repos with > 200 tracked vulns, the dashboard caps the table at 50 rows sorted by CWSS — full list is in `memory.yaml`. - CWSS scores can be missing for entries that were created by `vulnetix_vuln` (MCP) or `vulnetix vdb vuln <id>` lookup-only mode; the dashboard sorts those to the bottom.