# Tools & Scanners

Prüfwerk uses a combination of open-source scanners and AI-powered analysis to provide comprehensive security coverage. This page describes each tool and how it contributes to the scan pipeline.

## Semgrep -- Static Analysis (SAST)

[Semgrep](https://semgrep.dev/) is an open-source static analysis tool that finds vulnerabilities by matching patterns in source code. It supports many languages and has an extensive rule library.

Prüfwerk runs Semgrep with rules covering:

- **OWASP Top 10** -- injection, broken authentication, XSS, insecure deserialization, and more
- **General security** -- insecure cryptography, hardcoded credentials, path traversal
- **Language-specific** -- patterns unique to Python, JavaScript, TypeScript, Rust, Go, Java, and others

Semgrep produces SAST-type findings with file paths, line numbers, and rule descriptions.

## Syft -- SBOM Generation

[Syft](https://github.com/anchore/syft) is an open-source tool for generating Software Bills of Materials. It scans your repository and identifies every dependency, including:

- Package name and version
- Package manager (npm, cargo, pip, go, maven, nuget, composer, gem)
- License information

Syft output feeds into both the SBOM feature and the vulnerability scanning pipeline.

## OSV.dev + NVD -- Vulnerability Matching

Prüfwerk matches every SBOM component directly against two public vulnerability sources (no separate scanner binary):

- [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

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

A purpose-built scanner that detects OAuth and OIDC misconfigurations in your code, including:

- Missing state parameter validation
- Insecure token storage
- Incorrect redirect URI handling
- Missing PKCE implementation
- Token exposure in logs or URLs

## Custom GDPR Scanner

A scanner focused on data protection compliance, detecting:

- Personal data handling without consent checks
- Missing data retention policies
- Unencrypted PII storage
- Cross-border data transfer issues

## Custom Secrets Scanner

Detects hardcoded secrets and credentials in source code:

- API keys and tokens
- Database connection strings with embedded passwords
- Private keys and certificates
- Cloud provider credentials (AWS, GCP, Azure)

## LLM-Powered Code Review

Beyond rule-based scanning, Prüfwerk uses an LLM to perform architectural and security code review. The AI reviews code patterns that are too nuanced for static rules, such as:

- Business logic flaws
- Race conditions
- Improper error handling that leaks information
- Insecure design patterns

Code review findings are marked with the **Code Review** type.

## LLM-Powered Triage

Every finding -- regardless of which scanner produced it -- goes through AI triage. Here is how it works:

1. **Context gathering** -- the triage engine collects the finding details, the code snippet, and information from the code knowledge graph (what calls this code, what it calls, how it connects to entry points)

2. **Severity assessment** -- the LLM evaluates the finding considering:
   - The vulnerability type and its typical impact
   - The specific code context (is this in a test file? behind authentication? in dead code?)
   - The blast radius -- how many entry points and call chains are affected, based on the code graph

3. **Confidence scoring** -- the LLM assigns a confidence score (0.0 to 1.0) indicating how certain it is about the assessment

4. **Rationale generation** -- the LLM writes a human-readable explanation of why it assigned the severity and confidence it did

5. **Remediation guidance** -- the LLM generates step-by-step fix instructions and, where possible, a suggested code fix

### Learning from Feedback

When you mark findings as false positives or provide developer feedback, this information is used to improve future triage accuracy. Over time, the AI becomes better at understanding which findings are actionable in your specific codebase and which are noise.

::: 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.