Chain OWASP ZAP through canonical mitmproxy/IPX capture and correlate alerts #33

New issue

Open

opened 2026-09-02 17:24:36 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-02 17:24:36 +00:00

Owner

Outcome

Reconcile #21/#22/#23 with #26/#133 so ZAP keeps its valuable API/scanner semantics without becoming a second canonical HTTP-history pipeline.

Owning RAGE lane

Provider/runtime/tool worker; database worker owns only canonical evidence relationship primitives if missing.

Dependencies

#21 typed ZAP provider
#22 ZAP alert bridge
#23 ZAP/Nyxt epic
#135/#136 canonical mitmproxy/IPX capture
#137 transport policy

Research/design gate

Test supported proxy-chain topologies (client -> ZAP -> mitmproxy -> origin vs client -> mitmproxy -> ZAP -> origin) against ZAP upstream-proxy support, HTTPS interception/certificate behavior, passive-scan visibility, and reproducibility. Pick one explicitly and document the TLS/capture tradeoff.

Required behavior

ZAP-specific control remains typed: health/version, contexts/scope, passive scan, alerts, spider, active scan jobs, cancellation;
outbound ZAP traffic uses canonical operation capture where technically supported;
do not create a separate canonical ZAP HTTP exchange schema when :http-exchange suffices;
ZAP alert evidence may reference/correlate to canonical HTTP exchange IDs when evidence exists;
active scanning stays explicit and operation-scope constrained per #21;
API keys/secrets never leak into capture/profile logs.

RED-first tests

Proxy chain fixture, HTTPS fixture, passive alert retrieval, alert-to-exchange correlation, out-of-scope active scan rejection, repeated alert dedupe, and capture-off/unsupported behavior.

Acceptance proof

Run a local fixture through the selected chain, prove one canonical HTTP exchange is stored via IPX and a ZAP alert can reference that evidence while ZAP's API/provider state remains separate and no duplicate HTTP history authority exists.

## Outcome Reconcile #21/#22/#23 with #26/#133 so ZAP keeps its valuable API/scanner semantics without becoming a second canonical HTTP-history pipeline. ## Owning RAGE lane Provider/runtime/tool worker; database worker owns only canonical evidence relationship primitives if missing. ## Dependencies - #21 typed ZAP provider - #22 ZAP alert bridge - #23 ZAP/Nyxt epic - #135/#136 canonical mitmproxy/IPX capture - #137 transport policy ## Research/design gate Test supported proxy-chain topologies (`client -> ZAP -> mitmproxy -> origin` vs `client -> mitmproxy -> ZAP -> origin`) against ZAP upstream-proxy support, HTTPS interception/certificate behavior, passive-scan visibility, and reproducibility. Pick one explicitly and document the TLS/capture tradeoff. ## Required behavior - ZAP-specific control remains typed: health/version, contexts/scope, passive scan, alerts, spider, active scan jobs, cancellation; - outbound ZAP traffic uses canonical operation capture where technically supported; - do not create a separate canonical `ZAP HTTP exchange` schema when `:http-exchange` suffices; - ZAP alert evidence may reference/correlate to canonical HTTP exchange IDs when evidence exists; - active scanning stays explicit and operation-scope constrained per #21; - API keys/secrets never leak into capture/profile logs. ## RED-first tests Proxy chain fixture, HTTPS fixture, passive alert retrieval, alert-to-exchange correlation, out-of-scope active scan rejection, repeated alert dedupe, and capture-off/unsupported behavior. ## Acceptance proof Run a local fixture through the selected chain, prove one canonical HTTP exchange is stored via IPX and a ZAP alert can reference that evidence while ZAP's API/provider state remains separate and no duplicate HTTP history authority exists.