docs: align tool inventory with what actually runs (no Grype, no ZAP/nuclei) (#233)

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"]

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**
+**OSV.dev**
-An open-source vulnerability scanner for container images and filesystems. Used by Certifai to match dependencies against known vulnerabilities.
+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)
+- [OSV.dev](https://osv.dev/) -- batch queried by package URL (purl) for ecosystem advisories (npm, PyPI, crates.io, Go, Maven, ...)
-- GitHub Advisory Database
+- [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
-- OS-specific advisory databases
 
-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.