VerdictGit is one self-hosted binary that stores your vulnerability-triage verdicts as YAML in your own git repository and re-applies them to every future scan — from any scanner. This page is the complete technical picture: downloads, requirements, formats, matching, security and licensing. If a figure appears here, it was measured or shipped — and where a measurement is corpus-bound, we say so.
One static binary per platform; the triage console is embedded in it. Release archives are delivered with your licence — there is no account, portal or activation server involved.
| Platform | Archive | Size | Notes |
|---|---|---|---|
| Linux · x86-64 | verdictgit-1.0.2-linux-amd64.tar.gz | 8.1 MB | Static binary; also the build inside the container image. |
| Linux · ARM64 | verdictgit-1.0.2-linux-arm64.tar.gz | 7.4 MB | For ARM servers and CI runners. |
| macOS · Intel | verdictgit-1.0.2-darwin-amd64.tar.gz | 8.2 MB | |
| macOS · Apple Silicon | verdictgit-1.0.2-darwin-arm64.tar.gz | 7.5 MB | |
| Windows · x86-64 | verdictgit-1.0.2-windows-amd64.zip | 8.2 MB | |
| Docker · OCI image | verdictgit:1.0.2 | 19.8 MB | Multi-stage image (scratch runtime); mount your data and repo volumes. |
Each release ships with SHA-256 checksums (SHA256SUMS), an Ed25519 detached signature over them, verified against the release public key published with the artefacts, and a software bill of materials (sbom.json) covering all 194 packages — 75 Go modules and 119 npm packages. Verify before you install: sha256sum -c SHA256SUMS.
No database server to provision, no cluster, no runtime. If it runs an ordinary workload, it runs VerdictGit.
Any ordinary laptop, workstation, server or CI runner on Linux, macOS or Windows (x86-64 or ARM64). We publish no artificial minimums — the benchmark below was measured on a small 4-core VM.
A web UI served by the binary itself, bound to 127.0.0.1:8080 — localhost only by default. A non-loopback bind is refused unless you explicitly pass --allow-remote (then put it behind a TLS-terminating reverse proxy and a firewall).
None to install. Findings are indexed in an embedded SQLite database that is a rebuildable cache — delete it and it is rebuilt from your ingested reports and your verdict repository. The git repo, not the index, is the source of truth.
Handled by the engine built into the binary (pure-Go backend). A system git binary is supported as an optional alternative backend — never a requirement.
None required after install. No telemetry, no update check, no licence server, no phone-home. The optional extras you can switch on are listed in the egress inventory below.
100,000 findings ingested end-to-end in 4.5 seconds on a 4-core VM, fully offline. Cross-scanner matcher recall on the benchmark corpus: 100% / 100% / 97.8% depending on direction, with 0 wrong auto-applies. Stated honestly: those figures certify behaviour on the golden corpus shipped in the product's test fixtures — the defence on real-world reports is structural (conservative tiers plus shown match evidence), not a bigger claim.
A structurally damaged report fails loudly with a typed error — it never silently becomes “zero findings”.
| Input | Format | Support level |
|---|---|---|
| Trivy | Native JSON | Primary |
| Grype | Native JSON | Primary |
| OSV-Scanner | Native JSON | Primary |
| Semgrep · Snyk exports · other tools | SARIF 2.1.0 | Secondary — generic-SARIF level; the native formats are the primary, best-tested path |
Every finding is canonicalised to three things: the alias-resolved vulnerability ID (CVE ↔ GHSA ↔ OSV IDs, resolved through a local alias snapshot), the package URL (purl) of the component, and the version — compared with ecosystem-aware semantics (PEP 440 for PyPI, semver-ish for npm). An ID with no alias links canonicalises to itself — never into another ID's group. That one rule is what makes a wrong auto-apply structurally hard.
Switching scanners? Run both, and VerdictGit produces a coverage report for the switch: how many of your verdicts carry to the new scanner automatically, how many need one confirmation click, and how many are honestly lost (for example an accepted risk that expired). The homepage shows real, unedited output from the benchmark corpus.
| Tier | Meaning | Behaviour |
|---|---|---|
| EXACT | Same canonical identity — alias-resolved ID, component and version all agree. | Auto-applies. The only tier that ever does. |
| PROBABLE | Strong evidence, short of exact — a version respelling (3.2 vs 3.2.0), or a match resting on a multi-CVE alias group (these are capped here by rule). | Arrives as a suggestion with its evidence attached; a human confirms in one click and the verdict pins to the finding. |
| CONFLICT | The record disagrees with itself — e.g. two verdicts on the same finding with different states. | Routed to a human. Both sides are shown; the engine never silently picks one, and a conflicted finding never auto-applies. |
| NONE | No matching verdict exists. | The finding is simply new — it enters the triage queue undecided. |
The format is open and deliberately boring: plain YAML in a git repository. If VerdictGit disappeared tomorrow, every verdict remains readable, diffable and greppable with tools you already have.
format: verdictgit/verdict-file
format_version: 1
component: pkg:npm/lodash
verdicts:
- fingerprint: "9f2c…"
vuln_id: CVE-2021-23337
aliases: [GHSA-35jh-r3h4-6jhm]
version: "4.17.20"
scope: ">=4.17.0 <4.17.21"
state: false_positive
reason: "Command injection requires attacker-controlled keys;
our usage passes only constants."
author: "Jane Doe <jane@example.com>"
decided_at: "2026-11-08T15:04:05Z"
expires_at: null
evidence: ["https://github.com/lodash/lodash/issues/5261"]A real entry shape from the published format specification — a reason is mandatory, the author matches the git commit, and a finding whose version moves outside scope resurfaces instead of silently inheriting the decision.
Specified completely enough for a third party to write a conforming reader or writer: format specification plus a published JSON Schema. Unknown fields are a validation error — never silently dropped. Back it up the way you back up code: git clone is the restore.
Every verdict write is one normal git commit — never a rewrite, never a force-push — attributed to the authenticated author. git log and git blame on a verdict file are the finding's decision history: who, when, and the reason in the file itself.
An accepted_risk verdict requires an expiry date. Past it, the finding resurfaces into the queue on the next reconciliation — via the built-in scheduler or a one-shot cron run. Nothing stays accepted by inertia.
Confirmed verdicts create or link Jira issues. In the other direction, an issue closing as Done creates a proposal only — a human approves or rejects it before any verdict is written. Sync never authors a decision on its own, and your Jira credentials come from the environment only: they are never written to any file.
There is no VerdictGit cloud. Don't take this page's word for any of it — the product prints its own evidence: run verdictgit egress-report and it lists every network destination derived from your actual configuration.
| Egress inventory | When it happens |
|---|---|
| Zero configured destinations | The default. Nothing configured means nothing to talk to — the complete inventory on a default install is empty. |
| Your OIDC identity provider | Only if you configure SSO — your users, signing in through your provider. |
| Your own Jira | Only if you configure Jira sync — your instance, your project. |
| OSV snapshot download | On demand only, when you run snapshot refresh: a plain file download of public advisory data; nothing is uploaded. Prefer fully offline? Build the snapshot from your own scanner reports instead. |
| Licence checks · update checks · telemetry · analytics | Never. Licence verification is offline Ed25519 signature checking inside your binary. The others do not exist in this product. |
| Role | Can do |
|---|---|
| admin | Everything, including user and API-token management. |
| triager | Verdict writes, proposal decisions, Jira sync. |
| viewer | Read-only: queues, history, exports. |
Local accounts with bcrypt-hashed passwords and no default admin — first run prints a one-time setup URL, and setup disables itself once the admin exists. Optional OIDC SSO with just-in-time provisioning (admins by allow-listed email, everyone else viewer; an existing role is never changed by sign-in), with a local admin retained as break-glass for IdP outages.
Sessions are HttpOnly, SameSite=Lax cookies; mutating calls require the per-session CSRF token; login is rate-limited. API tokens are scoped (for example ingest-only, for CI), stored as hashes only, and a new token is shown exactly once.
One command produces a self-contained bundle — readable HTML report, CSV, and a manifest recording the repository HEAD: every verdict with its state, reason, author, dates and the git commit that last touched its file. The manifest carries the line: “Generated locally by VerdictGit — no data left this machine.”
Licences are Ed25519-signed files, verified inside your binary against a public key. There is no licence server and no phone-home — renewal is swapping one file, no restart needed; suspended writes resume the moment a valid licence lands.
| State | What it means | Verdict writes |
|---|---|---|
| none — evaluation | No licence file installed. Full product, so you can evaluate for real. | Enabled |
| valid | A signed licence is in place. | Enabled |
| grace | Within 30 days after the licence's expiry date. | Enabled |
| expired | Past the grace period. | New verdict writes pause. Reads, history, ingestion and exports always work — your data is never locked. |
A lifetime licence for your company with all future updates included and lifetime email support, delivered as a signed offline key, for the first 50 companies. One payment; nothing to renew, nothing to lapse. Full terms in the Licence Terms.
The complete product, flat per company — no per-seat, per-scan or per-finding meters. Also available as a yearly licence key, issued the same offline way. Upgrades for either licence: stop the server, replace the binary, start it again — no migration step to run by hand, and rollback is the same procedure in reverse. See pricing.
No. VerdictGit runs inside your network and there is no VerdictGit cloud, telemetry or analytics. On a default install the product's complete network inventory is zero destinations — and you don't have to trust this page: verdictgit egress-report prints the destinations derived from your own configuration. The only destinations that can ever appear are ones you switch on yourself: your OIDC provider, your own Jira, and the OSV snapshot download you invoke.
Your verdicts carry over. Findings are matched by canonical identity — the alias-resolved vulnerability ID, the component and its version — not by one scanner's naming, so a decision made against Trivy applies itself to Grype's report of the same finding. Before you commit to a switch, migration mode runs both scanners and reports the coverage: carried automatically, carried with one confirmation, and honestly lost. On the benchmark corpus, cross-scanner recall measured 97.8–100% with zero verdicts applied to the wrong finding.
Yes. The binary, the console and licence verification are all fully offline. The one optional download in the product is the OSV alias-snapshot refresh — skip it and build the snapshot from your own scanner reports instead; matching still works from the alias links each report asserts itself. Nothing in VerdictGit requires an internet connection at runtime.
Less than you'd fear. After the expiry date there is a 30-day grace period with writes still enabled. Past that, only new verdict writes pause — reads, history, scan ingestion and auditor exports keep working indefinitely, and installing a renewed licence file resumes writes instantly, with no restart. Founding licences are lifetime, so for founding customers there is nothing to expire in the first place.
Trivy, Grype and OSV-Scanner in their native JSON formats — the primary, best-tested path — plus SARIF 2.1.0 at the generic level, which covers Semgrep and Snyk exports and other SARIF-producing tools. One honesty note: a report whose structure doesn't match the recognised formats is rejected with a loud, typed error rather than partially ingested — you will never be shown a silent “zero findings”.
You receive the release archive for your platform (about 8 MB) and your signed licence file. Extract, initialise a verdicts repository, start the server: it prints a one-time setup URL where you create the admin account — there is no default account. Drop the licence file into the data directory and it is read automatically; there is no activation server to call. Zero to your first carried-over verdict takes about ten minutes.
Founding licences include all future updates, forever. Standard includes updates while your licence is active. Upgrading is deliberately dull: stop the server, verify and replace the binary (SHA-256 checksums and an Ed25519 signature ship with every release), start it against the same data and repository. There is no migration step to run by hand, and rolling back is the same procedure with the older binary — verdict files stay valid either way.
Founding licences carry a 30-day, no-questions-asked money-back guarantee from the day your key arrives, and refunds are processed within 7 working days of your request; after day 30 the founding sale is final, and we say so up front rather than in a footnote. Standard can be cancelled at any time and runs to the end of the period paid for. The full policy is on the Refund Policy page.
By email only, from a human: verdictgit@gmail.com — no phone line, no chat widget, no ticket portal. And for founding customers, email support is lifetime: it never expires and is never upsold, alongside a direct line to the builder and priority on the roadmap. There is no support tier to buy into — the complete product, including SSO, roles and audit, is the same at every price.
They stay exactly where they always were: in your git repository, as plain YAML files in an open, published format (specification v1 plus a JSON Schema). You can read, diff, grep and even build tooling against them with no VerdictGit involvement at all — one file per component, every decision with its reason, author and date. The format is the guarantee; the engine is the product.