agent-bom-vulnerability-intel

# agent-bom-vulnerability-intel

Use this skill to answer vulnerability-intelligence questions through
agent-bom's existing scanners and canonical evidence model. Do not create
one-off OSV, GHSA, NVD, EPSS, or KEV clients in the agent session; route through
agent-bom so advisory provenance, aliases, severity gates, cache behavior,
redaction, and output schemas stay consistent.

## Modes

Start with the smallest mode that answers the user:

| Mode | Use When | Data Boundary |
|------|----------|---------------|
| `explain-only` | User wants to know what would be queried | No advisory calls |
| `check-package` | User names one package/version/ecosystem | Only that package identifier is queried |
| `scan-local` | User wants findings from local agents or a local inventory file | Local parse first; advisory calls use package identifiers only |
| `offline-review` | Private package names cannot leave the environment | Use local/cache-approved data only; disclose reduced coverage |
| `export` | User wants PR gate, SARIF, JSON, or audit evidence | Write only to an operator-selected path |

## Guardrails

- Ask before scanning a broad filesystem path or local agent configs.
- Do not paste or reveal `NVD_API_KEY`, `GITHUB_TOKEN`, package-registry
  credentials, cloud credentials, or env values.
- Do not send full source files, lockfiles, config contents, secrets, or scan
  reports to advisory providers. agent-bom extracts package identifiers first.
- Treat unknown or unresolvable versions as coverage gaps, not clean results.
- Preserve advisory provenance. Do not collapse OSV, GHSA, NVD, EPSS, and KEV
  into a single unlabelled severity.
- Do not modify dependencies or install fixes unless the user explicitly asks
  for a remediation workflow.

## Workflows

### Explain the Boundary

When the user asks "what leaves my environment?", answer before running:

```text
This lookup sends package identifiers (name, version, ecosystem/PURL) and CVE
IDs to public advisory databases. It does not send source code, raw configs,
secrets, env values, credentials, or full scan reports. Use offline-review if
private package names are sensitive.
```

### Check One Package

```bash
agent-bom check flask==2.0.0 --ecosystem pypi
```

Use this for quick triage and fix-version checks. If the package name belongs
to a private registry or internal project, use `explain-only` first and let the
operator decide whether the identifier may be queried externally.

### Scan a Canonical Inventory

```bash
agent-bom agents --inventory inventory.json --format json --output findings.json
```

Use this after an operator-pull adapter or discovery skill emits canonical
inventory. The inventory can stop at the file boundary; scanning is an explicit
operator handoff.

### Export for a PR Gate

```bash
agent-bom agents --inventory inventory.json --format sarif --output agent-bom.sarif
```

Use SARIF only when the user wants GitHub code-scanning or AppSec PR-gate
evidence. Keep JSON for local analysis and audit trails.

### Offline Review

If external advisory calls are not allowed, run with the project's offline or
cache-approved mode and say clearly that coverage depends on the locally
available vulnerability database. Do not call a clean offline result equivalent
to a fresh OSV/GHSA/NVD lookup.

## Output Rules

- Show CVE/GHSA/PYSEC aliases together when available.
- Include severity source, fix version, EPSS, KEV status, CWE, and advisory
  source chain when present.
- Separate "no vulnerabilities found" from "not enough data to evaluate."
- Keep raw credentials and credential-bearing URLs out of output, logs, prompts,
  SARIF locations, and exported reports.