Automated CVE Triage. Every scan. Every advisory.
HarborGuard triggers triage the moment a scan completes and again every time NVD, OSV, GitHub Security Advisories, or CISA KEV publishes something that hits your image inventory. The queue stays focused on what matters — deduplicated, SLA-ranked, and attested.
CVE-2024-6197
curl 8.6.0
CVE-2024-5535
openssl 3.2.1
CVE-2024-7592
python 3.11.4
CVE-2024-3596
freeradius 3.0
Built for signal, not noise
2
Trigger events (scan + advisory)
4
Advisory sources monitored
Continuous
CVE Watch polling
100%
Findings deduplicated
What it does
Two triggers. One queue. Zero manual sorting.
Most container security tools hand you a list of CVEs at scan time and stop there. The problem is that the 2,200 CVEs published last month did not all exist when your last scan ran. If you shipped an image in January that contained libwebp 1.2.4, you would not have known about CVE-2023-4863 until you ran a scan — which you might not do until the next build cycle.
HarborGuard solves this with a dual-trigger model. Triage runs automatically when a scan completes, and it runs again when the CVE Watch worker detects a new advisory that matches a package version already present in your image inventory. The CVE Watch worker continuously polls the NVD, the OSV.dev database, GitHub Security Advisories (GHSA), and the CISA Known Exploited Vulnerabilities (KEV) catalog.
Before anything enters the triage queue, findings are deduplicated across all six bundled scanners, filtered by your organization's minimum severity threshold, and enriched with EPSS exploitation-probability scores. The result: engineers see the vulnerabilities that require action this sprint, not a 240-row spreadsheet of theoretical risk.
How it works
Automated CVE triage, step by step.
Scan completes or a new advisory lands
Every time a scan finishes or the CVE Watch worker polls NVD, OSV, GitHub Security Advisories, or CISA KEV and finds a matching package in your inventory, the triage pipeline triggers automatically.
CVE Watch cross-references your image inventory
The CVE Watch worker maintains an index of all known package names across your scanned images. New advisories are matched against this index in a single batch pass, so only packages you've actually shipped generate alerts.
Findings are deduplicated across all six scanners
Trivy, Grype, and OSV-Scanner frequently surface the same CVE. Before any triage run opens, findings are merged by CVE ID so a single vulnerability that three scanners found appears once with all source attribution preserved.
Severity is normalized and filtered by your policy threshold
Your organization's minimum severity threshold (set in the compliance policy) gates which findings enter the triage queue. CVEs below the threshold are stored but never open an active run, keeping the queue focused on what matters.
EPSS enrichment scores exploitation probability
Each finding is enriched with the EPSS (Exploit Prediction Scoring System) score and percentile from the canonical EPSS feed. This gives your team a probability-of-exploitation signal alongside the CVSS severity.
A triage run is dispatched with SLA deadlines attached
An ephemeral triage container is dispatched to a cloud worker (or local Docker in dev). The run carries the CVE record snapshot, SLA deadline computed from severity and your policy settings, and a callback token for secure result submission.
False-positive attestations suppress recurrence
Engineers can attest a finding as a false positive directly in the dashboard. Attested CVEs are suppressed with an immutable audit trail — they will not reopen for the same image on future scans or new advisories unless explicitly un-attested.
The dual-trigger model
Triage trigger one: a scan completes. The scan worker dispatches an ephemeral sensor container (to an ephemeral cloud worker in production, local Docker in dev), waits for the sensor to POST results back, and on receipt the ingest pipeline kicks off auto-triage. This fires synchronously within seconds of the sensor uploading its envelope.
Triage trigger two: a new CVE advisory. The CVE Watch worker runs on a continuous schedule. It polls NVD, GHSA, and CISA KEV, builds a set of newly published CVEs, cross-references them against the known-packages index, then queries for any scanned image version that falls within the affected version range. Alerts generate triage runs for every matching image and organization.
The two triggers are entirely independent. A scan started yesterday and a CVE published today will each dispatch their own triage run. Both are gated by the same organization policy (severity threshold, scope filter, auto-triage minimum severity).
SLA-driven prioritization
Every triage run carries an SLA deadline computed from the organization's compliance policy. The policy defines separate remediation windows per severity level — for example: CRITICAL 3 days, HIGH 7 days, MEDIUM 30 days. When a triage run opens, the platform stamps the deadline on the finding.
The SLA breach worker runs on a continuous schedule. It evaluates all open findings with an active deadline, computes distance to breach, and fires warning notifications for findings within the configured lead time (default 24 hours) and breach notifications for anything already past due. All notifications route through your configured channels: Slack, PagerDuty, email, or custom webhooks with HMAC signing.
When you update the compliance policy via the Compliance Policy modal, you can optionally trigger an SLA backfill that recomputes deadlines for all currently open findings against the new policy. This means policy changes take effect retroactively, not just for new findings.
Advisory sources: NVD, OSV, GHSA, CISA KEV
NVD (National Vulnerability Database)
The NIST National Vulnerability Database is the canonical registry of CVE records. HarborGuard polls NVD via its date-range query API, storing a cursor per source so each poll fetches only new or modified records since the last run. CVSS scores, severity ratings, and affected package ranges come primarily from NVD.
OSV.dev
The Open Source Vulnerability database aggregates ecosystem-specific advisory feeds (PyPA, RustSec, Go vuln DB, Linux distributions) alongside NVD. Its version-range format provides stronger accuracy for language-package advisories compared to NVD-only scanners. OSV records often have earlier timestamps than the corresponding NVD entry.
GitHub Security Advisories (GHSA)
The GitHub Advisory Database publishes security advisories for packages hosted on GitHub. Many advisories appear in GHSA before NVD processes them, giving the CVE Watch worker an early-warning advantage. GHSA is the upstream source for all Dependabot alerts and drives much of Grype's advisory database.
CISA KEV (Known Exploited Vulnerabilities)
CISA's KEV catalog lists vulnerabilities that threat actors are actively exploiting. A KEV-flagged finding in HarborGuard generates an elevated notification event and signals that exploitation is confirmed — not theoretical. Many security teams set their CRITICAL SLA to 24 hours for KEV-listed CVEs regardless of CVSS score.
What it looks like in practice
A typical mid-sized production image scan returns around 240 raw CVE findings across all six scanners. After deduplication, that collapses to roughly 140 unique CVEs. After applying a HIGH severity threshold, approximately 28 findings remain. After filtering findings that already have an open triage run or a false-positive attestation, the net new triage queue for the sprint might be 12 items — the ones that require action now.
The 228 findings that did not enter the active queue are not deleted — they are stored with their full CVE metadata and remain visible in the scan detail view. Only the 12 that require remediation action this sprint are surfaced in the triage queue.
False-positive attestations
Not every CVE in your scanner output is a real risk for your workload. A CVE in a library you have statically linked but whose vulnerable code path is never executed, a false positive in the scanner's version matching logic, or a vulnerability in a component compiled out of the final binary — these should be dismissed once and suppressed forever, not re-triaged on every scan.
HarborGuard's false-positive attestation system lets an engineer mark a finding as FP with a reason string. The attestation is written to the audit log and attached to the (image tag, CVE) pair. On subsequent scans and CVE Watch triggers for the same image, the ingest pipeline checks for an existing attestation and skips opening a new triage run. The CVE is still stored in the vulnerability record — it is never deleted — but it is marked suppressed and excluded from the active triage queue.
Notification routing
Triage events route through the platform's notification engine, which supports Slack webhooks, PagerDuty integration, SendGrid email, and custom webhooks with HMAC-SHA256 signing. Each event type — new CVE detected, KEV-flagged exploitation, SLA warning, SLA breach — can be routed to a different destination.
CVE Watch can be configured in three delivery modes per organization: realtime (a notification fires within seconds of the CVE Watch poll detecting the match), daily digest (a summary notification fires at 09:00 UTC grouping all pending alerts), or weekly digest (fires every Monday). The digest mode prevents alert fatigue on organizations with large, frequently-updated image inventories.
CISA KEV findings always fire realtime regardless of digest mode — exploitation is confirmed, so the time-to-notification matters.
Explore related capabilities
Questions about automated CVE triage
What triggers automated CVE triage in HarborGuard?
Triage fires on two distinct events. First, when a scan completes and results are ingested via the scan worker callback, the triage pipeline runs against the new findings immediately. Second, the CVE Watch worker continuously polls NVD, OSV, GitHub Security Advisories (GHSA), and the CISA Known Exploited Vulnerabilities (KEV) catalog. When a newly published advisory affects a package version present in any scanned image in your inventory, a triage run opens for the affected images. This dual-trigger model means a vulnerability in curl that your team shipped three months ago will surface in your triage queue the day it gets a CVE number — without requiring a rescan.
How are findings deduplicated when multiple scanners report the same CVE?
The sensor runs Trivy, Grype, and OSV-Scanner in parallel on the same image. All three query different advisory databases and often surface the same CVE. Before the finding is persisted, the ingest pipeline merges by CVE ID within a single scan: if CVE-2024-6197 appears in both Trivy output and Grype output, it lands as one finding with both scanner names recorded in the sources field. The deduplication key combines scan, CVE, package, and package version — same package, same version, same CVE always collapses to one finding regardless of how many scanners caught it.
What is CISA KEV and why does it matter for triage prioritization?
The CISA Known Exploited Vulnerabilities catalog is a curated list of CVEs that CISA has confirmed are actively being exploited in the wild. HarborGuard's CVE Watch polls the KEV feed and flags matching alerts. In the notification pipeline, KEV-flagged CVEs dispatch an elevated event type so Slack, PagerDuty, and webhook destinations can route them to the right on-call queue. For triage prioritization, a CRITICAL CVE on the KEV list should jump any CVSS-equivalent that is theoretical. Many organizations configure HarborGuard's severity threshold to pass all CRITICAL findings but use the KEV flag to determine response-time SLA.
How does the SLA deadline work per severity?
SLA deadlines are computed from your organization's compliance policy. The policy defines separate remediation windows for CRITICAL, HIGH, MEDIUM, and LOW findings (for example: CRITICAL in 3 days, HIGH in 7 days, MEDIUM in 30 days). When a triage run opens, the deadline is set to now plus the matching window. The SLA breach worker runs on a continuous schedule and fires SLA-breach notifications for any open vulnerability whose deadline has passed, and SLA-warning notifications for any that will breach within the configurable lead-time (default 24 hours). If you update the policy and run the SLA backfill, existing open triage items have their deadlines recomputed to match the new policy.
What happens to a false positive after I attest it?
Attesting a false positive writes an attestation record with the actor, timestamp, and reason to the audit log. The CVE is marked with a suppressed status in the triage table. On subsequent scans of the same image, if the same CVE resurfaces in the scan findings, the ingest pipeline checks for an existing attestation for that image-tag and CVE pair and skips opening a new triage run. The attestation persists until an operator explicitly revokes it. Every attestation and revocation is immutable in the audit log, which exports as signed evidence for SOC 2 and ISO 27001 controls.
Can I configure CVE Watch to only alert on certain registries or namespaces?
Yes. CVE Watch has a scope filter configurable per organization in the CVE Watch settings. The scope field accepts registry names, image name patterns (with glob support), and tag patterns. Alerts are only generated for images whose registry and name match the scope. The scope filter applies before the severity filter and before auto-triage dispatch, so an out-of-scope image never generates an alert, a notification, or an auto-triage run even if it matches an affected package.
Ready to stop triaging manually?
Start your 14-day trial. Zero manual triage in under 10 minutes.
Connect a registry, run your first scan, and watch automated CVE triage open its first run. No credit card required on the free tier.