Getting Started

Current release: v3.4.1. The engine images build with and ship Go 1.27, so govulncheck loads any module whose go.mod requires Go 1.27 or older — the earlier ceiling was 1.25. No scanner, fingerprint or exit-code changes; the Go module floor stays 1.25. v3.4.0: a scan can no longer look complete when it wasn't. Every analyzer that can silently degrade — the endpoint discovery, the spec parser, active probes, secrets, textscan, semgrep, govulncheck, pip, npm, the Python engine and its checks, and plugins — now records once per scan whether it ran, and if not, a machine-readable reason: not applicable, disabled by a flag, a missing dependency, an unsupported target, or a failure with its cause. The report's new metadata.coverage block says whether everything the run was configured to do actually ran and names the gaps. A URL scan that finds zero endpoints now writes its report before exiting 2 instead of vanishing; --fail-on-coverage-gap and --require-analyzers turn a gap into a failing build, off by default; a transient network failure in a dependency scanner is retried once in process; SARIF, HTML and PDF show the coverage table; and the Docker image now ships a Go toolchain so govulncheck runs inside it. Finding identity, scoring and default exit codes are unchanged. v3.3.0: an upgrade no longer splits a finding you were already tracking into a closed one and a new one: reports now carry the retired identity alongside the current one, purely as a migration bridge for anything that joins findings across the v3.0 identity change. Nothing scores or filters on it, and the current identity is unchanged, so saved baselines and .fendix-ignore fingerprint: rules keep matching. The list of checks a scan ran is also honest now — it is built from what actually completed rather than what was configured, so a scanner that was unavailable is no longer named as though it had run. v3.2.0 made every blocking decision explain itself: Every blocking decision now explains itself in the report. A finding carries the decision, the policy it was made under, the evidence class that justified it, and a rule-by-rule breakdown of its confidence score — and the JSON and SARIF reports say the same thing, so "why did this fail my pipeline?" is answerable without opening Fendix. A build blocked only because confidence enforcement was switched off is labelled as such, and findings that do not block are never marked as though they did. v3.1.0 stopped findings claiming more than they proved: wildcard CORS with credentials is a misconfiguration rather than an exploit and no longer fails a build, missing rate limiting is ranked by how abusable the endpoint is, browser security headers are judged against the response they sit on, a dynamic file path is not reported as a proven traversal, obvious test fixtures stop being treated as leaks, and an unresolved import is no longer read as proof a dependency is unused. The engine ships a unified Go/JS/IaC/Java textscan SAST engine, decision reports (BLOCK / WARN / INFO with a deterministic confidence band), PDF reports and Arabic HTML, Jira / Slack / Teams integrations, diff-aware scans that run on every commit (fendix scan --code . --diff --staged --fast), a fendix hook install pre-commit gate, Proven Path taint chains exported as SARIF codeFlows, and transitive Python SCA over poetry.lock / Pipfile.lock. v3.0 changed finding identity: a finding is identified by rule, file, symbol and operation rather than partly by its line, so it survives edits above it — but a baseline saved by an older release matches nothing and must be regenerated with --save-baseline, along with any .fendix-ignore rule pinning a fingerprint: value. v2.0 CI behaviour still applies: --fail-on consults the deterministic confidence band, not severity alone — --enforce-confidence=false restores the previous mapping byte-for-byte. On the labeled synthetic accuracy corpus, fendix scores F1 = 1.000 across all detection categories. See /performance for the cold-start benchmark and /accuracy for the precision/recall scorecard.