Vulnerability Management

---
name: "Blackpoint Vulnerability Management"
description: >
  Blackpoint Cyber (CompassOne) exposure data across four lenses: host
  vulnerability findings and the filters that matter (CVE, severity,
  patch and exploit availability), scan history, dark-web credential
  and data leaks, and internet-facing external exposures — plus how to
  combine them into a prioritized remediation view.
when_to_use: >-
  When working with Blackpoint Cyber / CompassOne vulnerability data — host-level findings, scan
  history, dark-web exposures, and internet-facing external exposures — and building prioritized
  remediation views. Use when: blackpoint vulnerability, blackpoint vulnerabilities, compassone
  vulnerability, blackpoint scan, blackpoint dark web, blackpoint external exposure, blackpoint
  cve, or blackpoint exposure.
---

# Blackpoint Vulnerability Management

CompassOne exposes four exposure lenses against a tenant's assets:
host-level vulnerabilities, scan history, dark-web leaks, and
internet-facing external exposures. This skill covers all four and
how to combine them into a prioritized remediation view.

## Anti-triggers

- **Patching, suppressing, or marking a finding fixed** — the
  `status` values (`fixed`, `ignored`, `false_positive`) are filters on
  a read, not actions. Nothing here writes; remediation happens in the
  CompassOne portal or the patching tool.
- **Another vendor's vulnerability view** — `sentinelone-vulnerabilities`
  and `sentinelone-misconfigurations` cover different scanners with
  different CVE coverage. Do not merge severity counts across products.
- **Live threat activity** — a vulnerability is a latent weakness;
  something actually happening is a detection, in
  `blackpoint-incident-response`.
- **Which host a CVE lands on** — asset detail and topology are
  `blackpoint-asset-inventory`.

## API Tools

| Tool | Purpose |
|------|---------|
| `blackpoint_vulnerabilities_list` | Host-level vulnerability findings |
| `blackpoint_vulnerabilities_scans_list` | Vulnerability scan history and status |
| `blackpoint_vulnerabilities_darkweb_list` | Dark-web exposures (leaked data) |
| `blackpoint_vulnerabilities_external_list` | Internet-facing external exposures |

## Filters That Matter

`blackpoint_vulnerabilities_list` accepts:

- `tenant_id`, `asset_id` — scope
- `severity` — `low`, `medium`, `high`, `critical`
- `status` — `open`, `fixed`, `ignored`, `false_positive`
- `cve_id` — pivot on a specific CVE
- `patch_available` — is a fix published?
- `exploit_available` — is it weaponized in the wild?

The **fix-now cohort** is the intersection: `severity` in
{`high`, `critical`}, `status: open`, `exploit_available: true`,
`patch_available: true` — a known, weaponized, fixable problem that
has not been fixed.

`blackpoint_vulnerabilities_darkweb_list` exposure types:
`credentials`, `documents`, `data_breach`, `malware`.

`blackpoint_vulnerabilities_external_list` exposure types:
`open_port`, `vulnerable_service`, `certificate_issue`,
`misconfiguration`.

`blackpoint_vulnerabilities_scans_list` status values:
`pending`, `running`, `completed`, `failed`.

## Common Workflows

### Prioritized remediation list for a tenant

1. Check `blackpoint_vulnerabilities_scans_list` — if the last
   `completed` scan is stale or recent scans `failed`, say so; it
   caps confidence in everything below.
2. Pull `blackpoint_vulnerabilities_list` for the tenant.
3. Filter to the fix-now cohort and present it first.
4. List remaining open criticals/highs (especially no-patch ones)
   separately with a compensating-controls note.

### Dark-web exposure check

1. `blackpoint_vulnerabilities_darkweb_list` for the tenant.
2. For `credentials` exposures, recommend forced password resets and
   an MFA enforcement check.
3. Flag `data_breach` and `malware` exposures for follow-up.

### External attack-surface review

1. `blackpoint_vulnerabilities_external_list` for the tenant.
2. Group by exposure type; treat `vulnerable_service` and
   `open_port` on management ports as highest priority.
3. Pair with `certificate_issue` findings for a complete edge view.

## Edge Cases

- **Stale scans** — never present a vulnerability rollup without
  checking scan recency first; old data misleads the reader.
- **No-patch criticals** — separate these from the fix-now list;
  they need compensating controls, not a patch ticket.
- **Read-only** — remediation actions happen outside CompassOne;
  the MCP cannot mark findings fixed.

## Best Practices

- Risk-weight, do not just severity-sort: exploitability and patch
  availability change the priority order materially.
- Combine all four lenses for QBRs — host, scan, dark-web, external
  tell complementary stories.
- Always cite CVE IDs and asset IDs so a finding can be re-pulled.

## Related Skills

- [incident-response](../incident-response/SKILL.md) - Detection-to-vulnerability correlation
- [asset-inventory](../asset-inventory/SKILL.md) - Mapping findings to assets