Dashboard

---
name: dashboard
description: 'Show what this repository has already decided about its vulnerabilities, read from the durable record rather than by scanning again — open versus resolved, the decision taken on each, and what is still waiting. Use when picking up triage after a break, auditing past decisions, onboarding to a repository with security history, or checking nothing high-severity is open before a release.'
license: Apache-2.0
allowed-tools: Bash(vulnetix:*) Read Grep Glob
user-invocable: true
model: haiku
metadata:
  outputBudget: medium
  cooldown: per-session
  chain: "repo-impact"
---
# 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.