ZAP findings bridge: ingest alerts as canonical Hackmode/StarIntel evidence #22

New issue

Open

opened 2026-08-25 07:37:11 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-25 07:37:11 +00:00

(Migrated from github.com)

Goal

Turn ZAP alerts into durable, deduplicated investigation evidence instead of leaving them trapped in the proxy UI.

Depends on #21 for the ZAP provider and on the canonical Hackmode operation/asset protocol.

Flow

ZAP alert -> normalize -> typed Hackmode finding/evidence -> local operation store -> event -> durable StarIntel outbox

Do not bypass Hackmode state by posting raw ZAP JSON directly to StarIntel.

Mapping

Define an explicit, tested mapping from ZAP alert fields into the existing Hackmode finding and StarIntel-compatible document model. Preserve raw provider data by reference where useful, but keep canonical fields stable.

Required metadata:

provider = OWASP ZAP
alert/plugin/rule identity
URL and related asset identity
risk + confidence
description/solution/reference
parameter/evidence where suitable
scan/context identity
first/last observed timestamps
operation ID
provenance/source

Dedupe

Stable identity must prevent repeated pulls of the same alert from creating duplicate canonical findings while still allowing observation timestamps/status to advance.

Nyxt use case

Nyxt should be able to:

import current-page ZAP alerts into the selected operation
show whether an alert is already attached
jump from alert -> local finding -> StarIntel document when synced
capture screenshot/note and relate it to the finding

Acceptance criteria

deterministic fixtures for multiple ZAP alert severities
repeat import is idempotent
local operation works with StarIntel offline
outbox retry preserves provenance and does not duplicate the remote logical finding
malformed provider payload is quarantined/inspectable
no API key or sensitive request headers are stored as evidence by default

Verification

Fake ZAP alert fixtures + fake StarIntel outbox adapter; optional local integration test may use a deliberately vulnerable test application only.

## Goal Turn ZAP alerts into durable, deduplicated investigation evidence instead of leaving them trapped in the proxy UI. Depends on #21 for the ZAP provider and on the canonical Hackmode operation/asset protocol. ## Flow `ZAP alert -> normalize -> typed Hackmode finding/evidence -> local operation store -> event -> durable StarIntel outbox` Do not bypass Hackmode state by posting raw ZAP JSON directly to StarIntel. ## Mapping Define an explicit, tested mapping from ZAP alert fields into the existing Hackmode finding and StarIntel-compatible document model. Preserve raw provider data by reference where useful, but keep canonical fields stable. Required metadata: - provider = OWASP ZAP - alert/plugin/rule identity - URL and related asset identity - risk + confidence - description/solution/reference - parameter/evidence where suitable - scan/context identity - first/last observed timestamps - operation ID - provenance/source ## Dedupe Stable identity must prevent repeated pulls of the same alert from creating duplicate canonical findings while still allowing observation timestamps/status to advance. ## Nyxt use case Nyxt should be able to: - import current-page ZAP alerts into the selected operation - show whether an alert is already attached - jump from alert -> local finding -> StarIntel document when synced - capture screenshot/note and relate it to the finding ## Acceptance criteria - deterministic fixtures for multiple ZAP alert severities - repeat import is idempotent - local operation works with StarIntel offline - outbox retry preserves provenance and does not duplicate the remote logical finding - malformed provider payload is quarantined/inspectable - no API key or sensitive request headers are stored as evidence by default ## Verification Fake ZAP alert fixtures + fake StarIntel outbox adapter; optional local integration test may use a deliberately vulnerable test application only.