History Baselines and Monitoring

History, Baselines, and Monitoring

Scan history

Completed reports are persisted to SQLite with normalized assets, components, dependency edges, findings, evidence, remediations, and policy decisions.

hooray history list
hooray history show 'run:UUID'
hooray history diff 'run:new' 'run:baseline'
hooray inventory --run-id 'run:UUID' --format yaml

Diffs partition stable finding IDs into introduced, resolved, and unchanged sets. First-seen and last-seen timestamps survive compatible baselines.

Baselines

hooray scan project . --baseline 'run:UUID' --new-findings-only
hooray scan project . --new-findings-only

An explicit baseline must belong to the same asset identity as the current inventory. An implicit baseline selects the latest run for that asset only. Cross-asset reports are never used to suppress matching stable IDs.

Monitoring

hooray monitor --once
hooray monitor

Monitoring persists targets, source/advisory/policy cursors, alert events, retries, dead letters, and retention state. A source fingerprint includes bounded scanner-relevant paths and contents, so source-only secret, SAST, or IaC changes trigger evaluation. Evaluation uses the same full engine pipeline as normal scans.

OSV does not expose a single global feed digest. Hooray therefore persists a conservative periodic advisory refresh generation that guarantees reevaluation instead of falsely claiming an unchanged advisory state.

Delivery correctness

Due alert events are claimed atomically in an SQLite immediate transaction before notification. Concurrent monitor processes cannot both deliver the same successfully claimed event. Failed delivery uses bounded exponential backoff and eventually dead-letters the event according to the retry policy.

Continuous mode survives transient cycle failures and applies bounded backoff rather than terminating the daemon. Individual target failures are rescheduled.

Target registration

Targets register through the CLI so future monitor cycles watch them:

hooray monitor targets add webapp --source ./webapp --interval-seconds 300
hooray monitor targets list --limit 50 --offset 0
hooray monitor targets remove webapp

add requires a target ID, source, and interval in seconds; list paginates registered targets; remove deletes a target together with its queued events. Provisioning directly through the supported persistence/application integration layer remains valid.

Alert delivery

The CLI notifier emits JSON alert events to standard error by default. Passing --webhook-url URL together with --webhook-secret-env VAR switches delivery to an HTTPS-only webhook signed with the shared integration HMAC scheme. The secret resolves from the named environment variable before the loop starts and never appears in errors or logs; the two flags are required as a pair, and omitting both keeps standard-error delivery. Webhook failures use the existing bounded backoff and dead-letter behavior.