docs: document Nuclei/ZAP as decided deterministic detectors under the agentic DAST (not yet implemented)

Spec v0.2.1 decision (2026-08-31): keep the agentic DAST/pentest layer, integrate
Nuclei then ZAP baseline underneath as deterministic detectors feeding the
control-map LUT; offline vuln DB (Trivy/Grype) on the on-prem runner trigger.
Clearly marked as planned so the docs stay truthful until the code lands.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EgxGHn22YEfQz5fLHSHkLv

.gitea/workflows/ci.yml

@@ -72,7 +72,7 @@ jobs:
             echo '[source.crates-io]'
             echo 'replace-with = "kellnr"'
             echo '[registries.kellnr]'
-            echo 'index = "sparse+https://crates.meghsakha.com/api/v1/cratesio/"'
+            echo 'index = "sparse+https://crates.breakpilot.com/api/v1/cratesio/"'
           } >> "$CARGO_HOME/config.toml"
         env:
           RUSTC_WRAPPER: ""
@@ -94,8 +94,8 @@ jobs:
       - name: Configure git auth for private tramiton dependency
         run: |
           git config --global \
-            url."https://sharang:${{ secrets.TRAMITON_FETCH_TOKEN }}@gitea.meghsakha.com/".insteadOf \
-            "ssh://git@gitea.meghsakha.com:22222/"
+            url."https://sharang:${{ secrets.TRAMITON_FETCH_TOKEN }}@git.breakpilot.com/".insteadOf \
+            "ssh://git@git.breakpilot.com:22222/"
         env:
           RUSTC_WRAPPER: ""
 
@@ -213,8 +213,8 @@ jobs:
           apk add --no-cache git curl openssl
           git init && git remote add origin "${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}.git"
           git fetch --depth=1 origin "${GITHUB_SHA}" && git checkout FETCH_HEAD
-          IMAGE=repo.meghsakha.com/certifai/compliance-agent
-          echo "$REGISTRY_PASSWORD" | docker login repo.meghsakha.com -u "$REGISTRY_USERNAME" --password-stdin
+          IMAGE=repo.breakpilot.com/certifai/compliance-agent
+          echo "$REGISTRY_PASSWORD" | docker login repo.breakpilot.com -u "$REGISTRY_USERNAME" --password-stdin
           DOCKER_BUILDKIT=1 docker build --secret id=tramiton_token,env=TRAMITON_FETCH_TOKEN \
             -f Dockerfile.agent -t "$IMAGE:latest" -t "$IMAGE:${GITHUB_SHA}" .
           docker push "$IMAGE:latest" && docker push "$IMAGE:${GITHUB_SHA}"
@@ -240,8 +240,8 @@ jobs:
           apk add --no-cache git curl openssl
           git init && git remote add origin "${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}.git"
           git fetch --depth=1 origin "${GITHUB_SHA}" && git checkout FETCH_HEAD
-          IMAGE=repo.meghsakha.com/certifai/compliance-dashboard
-          echo "$REGISTRY_PASSWORD" | docker login repo.meghsakha.com -u "$REGISTRY_USERNAME" --password-stdin
+          IMAGE=repo.breakpilot.com/certifai/compliance-dashboard
+          echo "$REGISTRY_PASSWORD" | docker login repo.breakpilot.com -u "$REGISTRY_USERNAME" --password-stdin
           DOCKER_BUILDKIT=1 docker build --secret id=tramiton_token,env=TRAMITON_FETCH_TOKEN \
             -f Dockerfile.dashboard -t "$IMAGE:latest" -t "$IMAGE:${GITHUB_SHA}" .
           docker push "$IMAGE:latest" && docker push "$IMAGE:${GITHUB_SHA}"
@@ -265,8 +265,8 @@ jobs:
           apk add --no-cache git curl openssl
           git init && git remote add origin "${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}.git"
           git fetch --depth=1 origin "${GITHUB_SHA}" && git checkout FETCH_HEAD
-          IMAGE=repo.meghsakha.com/certifai/compliance-docs
-          echo "$REGISTRY_PASSWORD" | docker login repo.meghsakha.com -u "$REGISTRY_USERNAME" --password-stdin
+          IMAGE=repo.breakpilot.com/certifai/compliance-docs
+          echo "$REGISTRY_PASSWORD" | docker login repo.breakpilot.com -u "$REGISTRY_USERNAME" --password-stdin
           docker build -f Dockerfile.docs -t "$IMAGE:latest" -t "$IMAGE:${GITHUB_SHA}" .
           docker push "$IMAGE:latest" && docker push "$IMAGE:${GITHUB_SHA}"
           { command -v cosign >/dev/null 2>&1 || curl -sSfLo /usr/local/bin/cosign https://github.com/sigstore/cosign/releases/download/v2.4.3/cosign-linux-amd64 || wget -qO /usr/local/bin/cosign https://github.com/sigstore/cosign/releases/download/v2.4.3/cosign-linux-amd64; } || echo "::warning::cosign fetch failed"
@@ -291,8 +291,8 @@ jobs:
           apk add --no-cache git curl openssl
           git init && git remote add origin "${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}.git"
           git fetch --depth=1 origin "${GITHUB_SHA}" && git checkout FETCH_HEAD
-          IMAGE=repo.meghsakha.com/certifai/compliance-mcp
-          echo "$REGISTRY_PASSWORD" | docker login repo.meghsakha.com -u "$REGISTRY_USERNAME" --password-stdin
+          IMAGE=repo.breakpilot.com/certifai/compliance-mcp
+          echo "$REGISTRY_PASSWORD" | docker login repo.breakpilot.com -u "$REGISTRY_USERNAME" --password-stdin
           DOCKER_BUILDKIT=1 docker build --secret id=tramiton_token,env=TRAMITON_FETCH_TOKEN \
             -f Dockerfile.mcp -t "$IMAGE:latest" -t "$IMAGE:${GITHUB_SHA}" .
           docker push "$IMAGE:latest" && docker push "$IMAGE:${GITHUB_SHA}"

Dockerfile.agent

@@ -8,8 +8,8 @@ COPY . .
 RUN --mount=type=secret,id=tramiton_token \
     if [ -s /run/secrets/tramiton_token ]; then \
       git config --global \
-        url."https://sharang:$(cat /run/secrets/tramiton_token)@gitea.meghsakha.com/".insteadOf \
-        "ssh://git@gitea.meghsakha.com:22222/"; \
+        url."https://sharang:$(cat /run/secrets/tramiton_token)@git.breakpilot.com/".insteadOf \
+        "ssh://git@git.breakpilot.com:22222/"; \
     fi && \
     CARGO_NET_GIT_FETCH_WITH_CLI=true cargo build --release -p compliance-agent
 

Dockerfile.dashboard

@@ -13,8 +13,8 @@ ENV DOCS_URL=${DOCS_URL}
 RUN --mount=type=secret,id=tramiton_token \
     if [ -s /run/secrets/tramiton_token ]; then \
       git config --global \
-        url."https://sharang:$(cat /run/secrets/tramiton_token)@gitea.meghsakha.com/".insteadOf \
-        "ssh://git@gitea.meghsakha.com:22222/"; \
+        url."https://sharang:$(cat /run/secrets/tramiton_token)@git.breakpilot.com/".insteadOf \
+        "ssh://git@git.breakpilot.com:22222/"; \
     fi && \
     CARGO_NET_GIT_FETCH_WITH_CLI=true dx build --release --package compliance-dashboard
 

Dockerfile.mcp

@@ -8,8 +8,8 @@ COPY . .
 RUN --mount=type=secret,id=tramiton_token \
     if [ -s /run/secrets/tramiton_token ]; then \
       git config --global \
-        url."https://sharang:$(cat /run/secrets/tramiton_token)@gitea.meghsakha.com/".insteadOf \
-        "ssh://git@gitea.meghsakha.com:22222/"; \
+        url."https://sharang:$(cat /run/secrets/tramiton_token)@git.breakpilot.com/".insteadOf \
+        "ssh://git@git.breakpilot.com:22222/"; \
     fi && \
     CARGO_NET_GIT_FETCH_WITH_CLI=true cargo build --release -p compliance-mcp
 

compliance-agent/src/pipeline/orchestrator.rs

@@ -277,8 +277,10 @@ impl PipelineOrchestrator {
             }
         }
 
-        // Dedup against existing findings and insert new ones
+        // Dedup against existing findings: insert first-seen ones, and refresh the
+        // control mappings on ones we've seen before.
         let mut new_count = 0u32;
+        let mut refreshed_count = 0u32;
         let mut new_findings: Vec<Finding> = Vec::new();
         for mut finding in all_findings {
             finding.scan_run_id = Some(scan_run_id.to_string());
@@ -293,8 +295,25 @@ impl PipelineOrchestrator {
                 finding.id = result.inserted_id.as_object_id();
                 new_findings.push(finding);
                 new_count += 1;
+            } else if !finding.control_refs.is_empty() {
+                // Re-scan refresh: a mapping pass (newly enabled or tuned) computed
+                // control_refs for a finding first seen before mapping ran. Persist
+                // them onto the existing row — the insert path alone never would.
+                self.db
+                    .findings()
+                    .update_one(
+                        doc! { "fingerprint": &finding.fingerprint },
+                        doc! { "$set": { "control_refs": finding.control_refs.clone() } },
+                    )
+                    .await?;
+                refreshed_count += 1;
             }
         }
+        if refreshed_count > 0 {
+            tracing::info!(
+                "[{repo_id}] Refreshed control_refs on {refreshed_count} existing findings"
+            );
+        }
 
         // Remove stale SBOM entries for this repo before reinserting
         if !sbom_entries.is_empty() {
@@ -567,7 +586,21 @@ impl PipelineOrchestrator {
             let Some(path) = ingest_set.get(&a.id).and_then(|ia| ia.working_path.clone()) else {
                 continue;
             };
-            all_findings.extend(crate::pipeline::plc::analyze_tree(&path, target_id));
+            let mut source_findings = crate::pipeline::plc::analyze_tree(&path, target_id);
+            // Control mapping for the PLC path (run_plc_scan is separate from
+            // run_pipeline, which does its own mapping). PLC findings carry
+            // file_path/line/cwe, so the semantic pass reads each region under this
+            // source's `path` and stamps master-control refs. The LUT + grounded
+            // surface passes are code-pattern / CRA-specific and don't apply to
+            // IEC 61131-3 control logic, so only the semantic pass runs here.
+            crate::controls::semantic_stamp_findings(
+                &self.config,
+                self.llm.clone(),
+                &path,
+                &mut source_findings,
+            )
+            .await;
+            all_findings.extend(source_findings);
             // Control-application SBOM: CODESYS libraries + runtime from a
             // `.projectarchive` (uploaded, or committed in the working tree).
             let archive = a
@@ -592,6 +625,7 @@ impl PipelineOrchestrator {
         );
 
         let mut new_count = 0u32;
+        let mut refreshed_count = 0u32;
         for mut finding in all_findings {
             finding.scan_run_id = Some(scan_run_id.to_string());
             if self
@@ -603,8 +637,27 @@ impl PipelineOrchestrator {
             {
                 self.db.findings().insert_one(&finding).await?;
                 new_count += 1;
+            } else if !finding.control_refs.is_empty() {
+                // Re-scan refresh: mirror run_pipeline — persist newly-computed
+                // control_refs onto a PLC finding first seen before the semantic
+                // pass ran. The insert path alone never would, so without this a
+                // PLC re-scan can only pick up mappings via a delete + re-add.
+                self.db
+                    .findings()
+                    .update_one(
+                        doc! { "fingerprint": &finding.fingerprint },
+                        doc! { "$set": { "control_refs": finding.control_refs.clone() } },
+                    )
+                    .await?;
+                refreshed_count += 1;
             }
         }
+        if refreshed_count > 0 {
+            tracing::info!(
+                target_id,
+                "Refreshed control_refs on {refreshed_count} existing PLC findings"
+            );
+        }
 
         if !all_sbom.is_empty() {
             if let Err(e) = self

docs/features/control-mapping.md

@@ -6,7 +6,7 @@ Control mapping connects the scanner's raw output — deterministic tool finding
 
 The design has one rule, borrowed from the ZeroFalse / IRIS line of research: **deterministic tools are the detectors; the LLM is only ever a grounded false-positive filter, never the thing that finds the issue.**
 
-- A tool (semgrep, gitleaks, syft/osv, ZAP, nuclei) detects deterministically.
+- A tool (semgrep, gitleaks, syft/osv, the PLC linter; the DAST agents today, with **Nuclei and ZAP planned** as deterministic web/OT detectors underneath them — see [Tools & Scanners](/reference/tools#planned-integrations-decided-2026-08-31-not-yet-in-the-code)) detects.
 - An **authored, human-reviewed lookup table** (`control-map`) maps that detection to the control(s) it's evidence for.
 - The LLM enters last, to *confirm or refute* the mapping against the actual code — and every surviving verdict is anchored to a verbatim snippet by the grounding gate.
 
@@ -34,7 +34,7 @@ At scale, the **master-controls** corpus (breakpilot's deduped clusters, exporte
 
 ```mermaid
 flowchart TD
-    T[Deterministic tools\nsemgrep · gitleaks · syft/osv · ZAP] --> F[Findings]
+    T[Deterministic tools\nsemgrep · gitleaks · syft/osv · DAST · PLC linter] --> F[Findings]
     F --> B["Stage 5b — LUT triage\ncontrols_for(tool, cwe / rule_id)"]
     F --> C["Stage 5c — Semantic\nembed region+intent → top-K master controls"]
     R[Repo source] --> D["Stage 5d — Grounded surface\nretrieve surface for absence-based controls"]
@@ -108,16 +108,25 @@ Every finding maps to its exact control family, with the most specific control o
 - **Generic catch-all controls co-occur.** `mc-20890 secure_development_security_code_review` appears in the top-K for many code-security findings because it is semantically near almost all of them. It's harmless (the judge grounds it, and it never crowds out the specific controls — the SQLi example didn't get it) but is a candidate for future down-weighting.
 - **Corpus classification noise.** The master-controls `verification_method` classification is imperfect — e.g. a documentation control (`eu_declaration_accuracy`) is currently tagged `source_code`. That's a corpus-side data-quality issue, separate from the mapping engine.
 
+## Emitting over MCP — closing the loop
+
+Findings don't just land in the dashboard; they flow to breakpilot-compliance as OSCAL over the scanner's MCP server, so the compliance report is assembled from real, control-tagged findings.
+
+- The MCP server exposes an **`oscal_assessment`** tool: given a `repo_id`, it emits a standard OSCAL 1.1 assessment-results document for that repo's findings — mapped findings target their controls via the stamped `control_refs`, and unmapped findings are reported **as-is** (as observations), so nothing is lost.
+- breakpilot pulls it: `POST /v1/cra/oscal-from-scanner` calls `oscal_assessment` over MCP (Streamable HTTP + bearer) and consumes the pre-computed OSCAL — rather than pulling raw findings and re-assessing.
+
+**Operational note — tenant context over HTTP.** The MCP server is multi-tenant; the bearer token resolves a tenant whose per-tenant database the tools query. rmcp's Streamable HTTP transport runs each session's tool calls in a `tokio::spawn`ed task, and `task_local`s do **not** cross a spawn — so binding the tenant in a per-request middleware `task_local` leaves tool handlers with no context (every call fails `no tenant context`). The fix is to bind the tenant to the **per-session server instance** at creation (the factory runs in the request scope before the spawn), not to a per-request task_local. Until this was fixed, the loop silently failed over HTTP and consumers fell back to demo data.
+
 ## Configuration
 
 | Variable | Effect |
 | --- | --- |
-| `BREAKPILOT_BASE_URL` | breakpilot-compliance root; enables control ingest + Stage 5b. Unset disables all control mapping. |
-| `BREAKPILOT_SEMANTIC_MAPPING` | Enables Stage 5c (semantic master-controls mapping). Default off. |
-| `BREAKPILOT_GROUNDED_CHECKS` | Enables Stage 5d (grounded surface checks). Default off. |
+| `BREAKPILOT_BASE_URL` | breakpilot-compliance root; enables control ingest + all mapping passes. **Unset disables all control mapping** — findings are produced without `control_refs`. |
+| `BREAKPILOT_SEMANTIC_MAPPING` | Stage 5c (semantic master-controls mapping). **Default on** (validated live). |
+| `BREAKPILOT_GROUNDED_CHECKS` | Stage 5d (grounded surface checks). **Default on** (validated live). |
 | `BREAKPILOT_SNAPSHOT_DIR` | Where OSCAL catalog snapshots and the cached control-embedding index live. |
 
-The semantic and grounded passes are gated because they are the heavier, less deterministic paths; they stay off until verified live against a deployed catalog. The live verification lives in `compliance-agent/tests/c5_semantic_live.rs` (ignored; run with `--ignored`).
+The semantic and grounded passes default **on** now that both are validated live; each is still a no-op if `BREAKPILOT_BASE_URL` is unset or the catalog is unreachable, so they only ever add coverage. The live verifications live in `compliance-agent/tests/c5_semantic_live.rs` and `grounded_surface_live.rs` (ignored; run with `--ignored`).
 
 ## Appendix — the master-controls data pipeline
 

docs/features/dast.md

@@ -92,3 +92,7 @@ Filters can be combined. A count indicator shows how many findings match the cur
 ::: tip
 Findings marked as **Confirmed** exploitable were verified with a successful attack payload. **Unconfirmed** findings show suspicious behavior that may indicate a vulnerability but could not be fully exploited.
 :::
+
+## Deterministic detectors (planned)
+
+The DAST engine above is agentic: an LLM drives crawler, browser and testing tools and decides what to try next. That gives depth and code-aware exploitation, but not run-to-run reproducibility. The next step (decided 2026-08-31, not yet implemented) adds two deterministic open-source detectors **under** the agents: **Nuclei** (template checks incl. ICS/OT and default-credential templates) first, then an **OWASP ZAP** baseline scan. Their findings will appear alongside agent findings, carry CWE + compliance `control_refs`, and seed the agent's context so it verifies and chains instead of rediscovering. See [Tools & Scanners](/reference/tools#planned-integrations-decided-2026-08-31-not-yet-in-the-code).

docs/guide/findings.md

@@ -26,7 +26,7 @@ Filters can be combined. Results are paginated with 20 findings per page.
 | Severity | Color-coded badge: Critical (red), High (orange), Medium (yellow), Low (green), Info (blue) |
 | Title | Short description of the vulnerability (clickable) |
 | Type | SAST, SBOM, CVE, GDPR, OAuth, Secrets, or Code Review |
-| Scanner | Tool that found the issue (e.g. Semgrep, Grype) |
+| Scanner | Tool that found the issue (e.g. Semgrep, Syft/OSV) |
 | File | Source file path where the issue was found |
 | Status | Current triage status |
 
@@ -73,7 +73,7 @@ If the finding has been pushed to an issue tracker (GitHub, GitLab, Gitea, Jira)
 | Type | Source | Description |
 |------|--------|-------------|
 | **SAST** | Semgrep | Code-level vulnerabilities found through static analysis |
-| **SBOM** | Syft + Grype | Vulnerable dependencies identified in your software bill of materials |
+| **SBOM** | Syft + OSV.dev/NVD | Vulnerable dependencies identified in your software bill of materials |
 | **CVE** | NVD | Known CVEs matching your dependency versions |
 | **GDPR** | Custom rules | Personal data handling and consent issues |
 | **OAuth** | Custom rules | OAuth/OIDC misconfigurations and insecure token handling |

docs/guide/sbom.md

@@ -6,7 +6,7 @@ The SBOM (Software Bill of Materials) feature provides a complete inventory of a
 
 A Software Bill of Materials is a list of every component (library, package, framework) that your software depends on, along with version numbers, licenses, and known vulnerabilities. SBOMs are increasingly required for compliance audits, customer security questionnaires, and supply chain transparency.
 
-Certifai generates SBOMs automatically during each scan using Syft for dependency extraction and Grype for vulnerability matching.
+Certifai generates SBOMs automatically during each scan using Syft for dependency extraction and OSV.dev + NVD for vulnerability matching.
 
 ## Packages Tab
 

docs/guide/scanning.md

@@ -8,7 +8,7 @@ When a scan is triggered, Certifai runs through these phases in order:
 
 1. **Clone** -- pulls the latest code from the Git remote (or clones it for the first time)
 2. **SAST** -- runs static analysis using Semgrep with rules covering OWASP, GDPR, OAuth, secrets, and general security patterns
-3. **SBOM** -- extracts all dependencies using Syft, identifying packages, versions, licenses, and known vulnerabilities via Grype
+3. **SBOM** -- extracts all dependencies using Syft, identifying packages, versions, licenses, and known vulnerabilities via OSV.dev + NVD
 4. **CVE Check** -- cross-references dependencies against the NVD database for known CVEs
 5. **Graph Build** -- parses the codebase to construct a code knowledge graph of functions, classes, and their relationships
 6. **AI Triage** -- new findings are reviewed by an LLM that assesses severity, considers blast radius using the code graph, and generates remediation guidance
@@ -52,7 +52,7 @@ A full scan runs multiple analysis engines, each producing different types of fi
 | Scan Type | What It Detects | Scanner |
 |-----------|----------------|---------|
 | **SAST** | Code-level vulnerabilities (injection, XSS, insecure crypto, etc.) | Semgrep |
-| **SBOM** | Dependency inventory, outdated packages, known vulnerabilities | Syft + Grype |
+| **SBOM** | Dependency inventory, outdated packages, known vulnerabilities | Syft + OSV.dev/NVD |
 | **CVE** | Known CVEs in dependencies cross-referenced against NVD | NVD API |
 | **GDPR** | Personal data handling issues, consent violations | Custom rules |
 | **OAuth** | OAuth/OIDC misconfigurations, insecure token handling | Custom rules |

docs/reference/glossary.md

@@ -58,8 +58,8 @@ An open-source static analysis tool that finds bugs and enforces code standards
 **Syft**
 An open-source tool for generating SBOMs from container images and filesystems. Used by Certifai to extract dependency information.
 
-**Grype**
-An open-source vulnerability scanner for container images and filesystems. Used by Certifai to match dependencies against known vulnerabilities.
+**OSV.dev**
+Google's open distributed vulnerability database, queried by package URL. Certifai uses it (together with NVD) to match SBOM components against known vulnerabilities.
 
 ## Protocols
 

docs/reference/tools.md

@@ -24,15 +24,14 @@ Semgrep produces SAST-type findings with file paths, line numbers, and rule desc
 
 Syft output feeds into both the SBOM feature and the vulnerability scanning pipeline.
 
-## Grype -- Vulnerability Scanning
+## OSV.dev + NVD -- Vulnerability Matching
 
-[Grype](https://github.com/anchore/grype) is an open-source vulnerability scanner that matches your dependencies against known vulnerability databases. It takes Syft's SBOM output and cross-references it against:
+Certifai matches every SBOM component directly against two public vulnerability sources (no separate scanner binary):
 
-- National Vulnerability Database (NVD)
-- GitHub Advisory Database
-- OS-specific advisory databases
+- [OSV.dev](https://osv.dev/) -- batch queried by package URL (purl) for ecosystem advisories (npm, PyPI, crates.io, Go, Maven, ...)
+- [NVD](https://nvd.nist.gov/) -- queried per CVE for the CVSS v3.1 base score, and by CPE for CODESYS runtime versions found in PLC projects
 
-Grype produces SBOM-type findings with CVE identifiers, severity ratings, and links to advisories.
+Matches are stored as CVE alerts with CVSS scores and re-checked hourly, so newly published CVEs against an unchanged dependency still raise a notification.
 
 ## Custom OAuth Scanner
 
@@ -97,3 +96,14 @@ When you mark findings as false positives or provide developer feedback, this in
 ::: tip
 The AI triage is a starting point, not a final verdict. Always review the rationale and code evidence before acting on a finding. See [Understanding Findings](/guide/findings#human-in-the-loop) for more on the human-in-the-loop workflow.
 :::
+
+## Planned integrations (decided 2026-08-31, not yet in the code)
+
+The product spec keeps an **OSS-only** tooling policy and a control-mapping rule of *tools detect, the LLM judges*. Two deterministic detectors are therefore being added **underneath** the agentic DAST/pentest layer — the agents stay on top for context-seeded exploitation, chaining and explanation:
+
+| Tool | Role | Status |
+|------|------|--------|
+| [Nuclei](https://github.com/projectdiscovery/nuclei) | Template-driven checks (CVE probes, default credentials, exposed panels, misconfigurations) including ICS/OT templates for WebVisu / OpenPLC / HMI endpoints. Runs as a DAST phase and as a Werkbank job with vendored templates so it works on-prem. | Planned — tracked as an issue |
+| [OWASP ZAP](https://www.zaproxy.org/) | Baseline (passive) and, behind the destructive-tests flag, active scan for reproducible spider + rule coverage; results seed the pentest agent. | Planned — follows Nuclei |
+
+Both feed the same `control-map` lookup table as Semgrep, so their findings receive compliance `control_refs` through the grounded judge. An **offline vulnerability database** (Trivy preferred, Grype as alternative) is planned for the on-prem Werkbank runner, which cannot reach the OSV.dev / NVD APIs. Until these land, DAST findings come exclusively from the in-house agents described above.