---
name: assess-product-exposure
description: Work out which indexed CVEs affect a given product, vendor, package, or version, and turn that into a prioritised exposure summary. Use when asked whether something is vulnerable or what to patch.
---

# Assess product exposure

Answer "is this thing vulnerable, and what do I do about it?" from indexed
affected-component evidence rather than from guesswork.

## Workflow

1. Call `find_vulnerabilities_by_product` with what you have been given:
   `product` is required, and `vendor`, `package`, `ecosystem`, and `version`
   narrow it. Pass `version` whenever the user gave you one — it is what turns a
   list of CVEs into an answer about their deployment. Submit only fields needed
   for the comparison; tool arguments are captured for service telemetry, so
   never send secrets or unnecessary internal asset identifiers.
2. The tool returns at most 20 matches and has no cursor or truncation flag. Use
   `limit: 20` for a broad exposure request, call the result a bounded set of
   indexed matches, and do not claim it is the complete affected population.
   Repeating the same call cannot retrieve another page.
3. Read `matchMode` before the results. It describes the complete supplied
   filter set, not only the product spelling:
   - `exact` — component rows matched the product and every optional vendor,
     package, and ecosystem filter.
   - `suggestions` — no complete match was returned, and `suggestions` contains
     product-name alternatives. An optional filter may be the mismatch, so do
     not assume the product spelling alone was wrong. Re-run a clear
     normalization such as "Google Chrome" to "Chrome", or present the choice;
     do not silently drop deployment filters from the final exposure answer.
   - `none` — no complete match or available product suggestion was returned.
     Short product names and unavailable suggestion support can also produce
     this state. Say the supplied filter set returned no component rows, which
     is not the same claim as "it is not affected".
4. For a broad technology question ("what goes wrong with reverse proxies") use
   `search_vulnerabilities` instead — component rows only cover CVEs whose
   sources named a product.
5. For a result you already hold, prefer reading its
   `vulnerability.okfUri` resource when you need the fix version or mitigation:
   `get_vulnerability` would repeat the metadata as well as returning the same
   full report. Product matches omit raw affected ranges because the service
   has already reduced them to `applicability`; read the resource only when the
   full version evidence is needed. Use `get_vulnerability` when you have only
   an exact identifier or alias.
6. A validation, rate-limit, readiness, or transport failure is not a clean
   product result. Report it separately from `matchMode` and do not reinterpret
   it as no exposure.

## Reading `applicability`

Each result carries `applicability` for the version you supplied. The three
values are not two answers and a shrug:

- `affected` — the version falls inside a recorded affected range, or is listed
  explicitly. Act on it.
- `not_affected` — the version sits outside every usable range. This is a real
  negative and can be reported as one.
- `unknown` — the corpus **cannot decide**, which is not the same as safe.
  Never report it as "not affected".

A result can be `unknown` for reasons including:

- No version was supplied.
- The version cannot be ordered — pre-release (`1.0.0-rc1`) or
  distribution-packaged (`1:2.3-4ubuntu5`) versions need scheme-specific rules
  the service will not guess at.
- The recorded range is unusable: upstream advisories routinely publish a range
  whose lower and upper endpoints are equal, which covers no version at all.
  The range is broken; that is not evidence the deployment is safe.
- Structured ranges are missing, malformed, ambiguous, or use an expression the
  conservative comparator cannot order.

The response does not carry an explicit reason field or the raw affected
ranges. State a specific reason only when it is established by the returned
metadata or canonical report. Explicit seeded `notAffectedVersions` and
`versions` entries take precedence over range bounds.

## Reporting rules

- Lead with what the operator should act on: which records are `affected` in
  their stated configuration, and which are informational.
- Report `unknown` as an open question, not as a clean bill of health. Give a
  reason only when the component data or canonical report establishes it;
  otherwise say the service did not expose one. If it matters, read the full
  report and quote what the advisory actually says about versions.
- Give the fix as the source states it (fixed version, vendor advisory, or
  mitigation), and cite that source.
- Absence of a result is not evidence of safety. Say the supplied filter set
  returned no indexed affected-component rows, which is a different claim from
  "it is not vulnerable". When results are present, still describe them as a
  bounded set rather than the complete affected population.