Triage Workflow

Every vulnerability HarborGuard discovers enters the triage state machine. The state is stored on the vulnerability record at triage.status and drives SLA timers, dashboard counters, and compliance evidence.

State machine

        ┌─────────────────────────────────────────┐
        ▼                                         │
  ┌─────────┐    ┌──────────────┐    ┌──────────────┐
  │  OPEN   │ ─▶ │ ACKNOWLEDGED │ ─▶ │ IN_PROGRESS  │
  └─────────┘    └──────────────┘    └──────────────┘
        │              │                    │
        │              ▼                    ▼
        │        ┌──────────┐        ┌──────────┐
        └──────▶ │ WONT_FIX │        │  FIXED   │
                 └──────────┘        └──────────┘

State	Meaning	SLA timer
`OPEN`	Newly detected, not yet reviewed. Default for any new finding.	Counts toward breach.
`ACKNOWLEDGED`	A human has reviewed and confirmed the finding is real and in-scope.	Counts toward breach.
`IN_PROGRESS`	Remediation is underway (PR open, image rebuild queued, etc).	Counts toward breach.
`FIXED`	Remediated. The finding will auto-clear when the next scan no longer reports it.	Stopped.
`WONT_FIX`	The team has decided not to remediate. Requires an active attestation to suppress from compliance reports.	Stopped.

Any state can transition back to OPEN if a re-scan finds the CVE again after being marked FIXED, or if an attestation expires.

API

PUT /api/vulnerabilities/{vulnId}/triage updates a single vulnerability. The vulnId may be either the internal vulnerability primary key or a CVE ID (when unique within your org).

curl -X PUT \
  -H "Authorization: Bearer $HG_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "status": "IN_PROGRESS",
    "assignee": "alice@example.com",
    "note": "PR #482 bumps openssl to 3.0.13"
  }' \
  "https://harborguard.co/api/vulnerabilities/vuln_01HV.../triage"

Required role: developer or higher. The response echoes the updated triage object including updatedBy and updatedAt.

Won't Fix and attestations

WONT_FIX on its own only changes dashboard state — it does not remove the vulnerability from compliance reports or SLA dashboards. To suppress a finding from compliance evidence you must pair WONT_FIX with an attestation that records the justification, scope, and (optionally) an expiry date.

Attestation scopes determine which scans the suppression applies to:

Scope	Applies to
`tag`	One specific image tag only (e.g. `api-gateway:v2.4.1`).
`historical`	Every scan whose detection date is on or before `asOfDate`.
`blanket`	All current and future detections of this CVE+package across the org.

When an attestation expires, any finding it was suppressing reverts to OPEN and re-enters the SLA timer. See Attestations for the full data model and creation API.

Automation rules

The compliance policy exposes opt-in triage rules that the platform applies automatically:

autoAckLowCvss — auto-transition new OPEN findings with CVSS < 4.0 to ACKNOWLEDGED.
suppressKernelOnly — flag kernel-CVE findings for review without firing alerts.
requireUpstreamPatch — block transition to FIXED until an upstream fix version is published.
autoSlaDeadline — compute and persist triage.slaDeadline whenever the SLA policy changes (default on).

These are configured in Compliance → Policy → Triage rules.

State machine

API

Won't Fix and attestations

Automation rules

See also

On this page