agent-bom vulnerability intel

Use agent-bom to check package, SBOM, inventory, and agent dependency exposure against OSV, GitHub Security Advisories, NVD, EPSS, and CISA KEV with explicit data-boundary choices. Use when a user asks for CVE lookup, advisory intelligence, exploitability context, fix versions, GHSA/OSV/NVD enrichment, or package vulnerability triage.

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.