Files
compliance-scanner-agent/docs/reference/tools.md
T
Sharang ParnerkarandClaude Fable 5 b7b9c812ab
CI / Check (push) Skipped
CI / Check (pull_request) Failing after 3m1s
CI / Detect Changes (pull_request) Skipped
CI / Deploy Agent (pull_request) Skipped
CI / Deploy Dashboard (pull_request) Skipped
CI / Deploy Docs (pull_request) Skipped
CI / Deploy MCP (pull_request) Skipped
docs: align tool inventory with what actually runs (no Grype, no ZAP/nuclei)
CVE matching is done directly against OSV.dev (by purl) and NVD (CVSS, CODESYS
CPE) in pipeline/cve.rs; Grype is not installed or invoked. DAST/pentest use the
in-house compliance-dast agents, not ZAP or nuclei. Found while reconciling the
Certifai requirements spec (Collectives) with the code.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EgxGHn22YEfQz5fLHSHkLv
2026-08-31 15:05:06 +02:00

99 lines
4.5 KiB
Markdown

# Tools & Scanners
Certifai 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.
Certifai 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
Certifai 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, Certifai 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.
:::