Skip to content

Triage

/triage · per-product at /products/:productId/triage

Triage is where findings become decisions. It is also the part teams most often skip, and the part an assessor most wants to see.

A scan report on its own is not evidence of vulnerability handling. Arguably it is worse than nothing: it proves you knew, without showing what you concluded. The decision log is the product here.

The queue is organised by component

One firmware image can produce thousands of findings across a few dozen components. Working CVE-by-CVE is not finishable; working component-by-component is.

For each component you record one of:

Decision Meaning
Affected The vulnerability is reachable and relevant in this product
Not affected Present, but not exploitable here, and you say why
False positive The component or version match is wrong

Every decision carries a justification. "We considered this and here is why it does not affect the product" is the sentence an assessor is looking for, and the one that is impossible to reconstruct from memory two years later.

Decisions persist

Triage decisions survive rescans. A new scheduled pass does not reset the work you did; it adds new findings and leaves your existing decisions in place.

Decisions can also be carried forward to a new release, with a preview of exactly what would carry before you commit. This is what makes triage sustainable across a long release history: the same component at the same version usually deserves the same answer, and re-deriving it every time is how teams give up on triage.

Review what carries rather than accepting it blindly. A component that was not exploitable in one product configuration may be in another.

Importing VEX

Existing VEX documents can be imported to seed decisions, which is useful when a supplier has already assessed a component on your behalf, or when you are migrating from another system.

An imported decision is still your decision: you are the manufacturer, and the justification is attributed to your organisation.

What triage unlocks

Triage is not a tidiness exercise. Two things downstream are gated on it:

Customer advisories. An advisory cannot be sent unless at least one linked finding resolves to an exploitable state. You cannot notify customers on the strength of an untriaged scan result, because until triage concludes, there is nothing to tell them.

→ Advisories

Article 14 scoping. When an incident opens, the affected-release list is only as good as the triage behind it. The 72-hour notification asks which products and versions are affected; that answer comes from here.

→ Reporting

Triage and the conformity checklist

The third-party component due diligence item on the conformity checklist is fed by triage decisions and the component inventory. Art. 13(5) expects a record of due diligence over third-party and open source components; a component inventory with reasoned decisions attached is what that record looks like in practice.

A working rhythm

  1. New findings arrive from a scheduled rescan or a fresh upload.
  2. High and critical land in your PSIRT inbox.
  3. Work the queue by component, deciding and justifying.
  4. Anything affected with a fix becomes a candidate for an advisory.
  5. Anything actively exploited in a shipped release is an incident, on a 24-hour clock.
  6. The decision history goes into the evidence pack for the release.

Next