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

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.