Riskrancher on t0ul

A whole web app in one binary: the standard library and an embedded UI

Wed, 09 Sep 2026 00:00:00 +0000

Part of my series on RiskRancher, the open-source vulnerability manager I build. Source: github.com/Kuebiko-LLC/risk-rancher-core.

Intro

Across this series I’ve said RiskRancher is one binary a few times: one binary and SQLite, pure-Go so it builds everywhere, air-gapped because it carries everything. This post is the capstone: how the web app itself fits in that one file with no framework and no loose static assets. The short version is that modern Go’s standard library is enough, and embed does the rest.

Showing what to fix first, without a black-box risk score

Wed, 12 Aug 2026 00:00:00 +0000

Part of my series on RiskRancher, the open-source vulnerability manager I build. Source: github.com/Kuebiko-LLC/risk-rancher-core.

Intro

“Risk-based” has become a marketing word that usually means a vendor multiplies some numbers together and hands you a score you can’t question. I went the other way with RiskRancher. Prioritization here is a handful of honest counts: how many open findings you have, broken down by severity and by source, combined with the SLA deadlines from the last post. No black box. This post is about why transparent beats clever for deciding what to fix first.

From finding to fixed: tickets, SLAs, and a workflow that isn't a spreadsheet

Wed, 08 Jul 2026 00:00:00 +0000

Part of my series on RiskRancher, the open-source vulnerability manager I build. Source: github.com/Kuebiko-LLC/risk-rancher-core.

Intro

Ingesting and deduping findings gets you a clean list. But a clean list is still just a list, and the reason most teams’ “system of record” is a spreadsheet is that nobody built the part where findings turn into tracked, deadlined work. That’s the part that actually reduces risk, so in RiskRancher every finding becomes a ticket with a lifecycle and an SLA. This post is about that workflow.

Deduping millions of findings with one content hash

Wed, 10 Jun 2026 00:00:00 +0000

Part of my series on RiskRancher, the open-source vulnerability manager I build. Source: github.com/Kuebiko-LLC/risk-rancher-core.

Intro

Scanners are repetitive by nature. You run Trivy on the same image every build, Nessus on the same hosts every week, and the overwhelming majority of what comes back is findings you already have. If you store every finding from every scan as a new row, you drown in duplicates fast, and the “system of record” becomes useless. So deduplication isn’t a nice-to-have in a vulnerability manager, it’s the thing that makes the data worth keeping. Here’s how RiskRancher does it with a single hash, and the interesting part is what I chose to leave out of that hash.

The no-code Adapter Builder: supporting any scanner without shipping a parser

Wed, 13 May 2026 00:00:00 +0000

Part of my series on RiskRancher, the open-source vulnerability manager I build. Source: github.com/Kuebiko-LLC/risk-rancher-core.

Intro

In the last post I said the trick to handling every scanner is to normalize findings into one model, and to keep the per-scanner mapping as configuration rather than code. This post is about that configuration: the Adapter Builder. It’s the feature I’m happiest with, because it means a user can teach RiskRancher a brand-new scanner in a couple of minutes, in the browser, and I never have to cut a release to support it.

Every scanner speaks a different language: normalizing findings into one model

Wed, 08 Apr 2026 00:00:00 +0000

Part of my series on RiskRancher, the open-source vulnerability manager I build. Source: github.com/Kuebiko-LLC/risk-rancher-core.

Intro

The first hard problem in vulnerability management isn’t storing findings, it’s that every tool describes a finding differently. Trivy buries vulnerabilities under nested result arrays, Qualys hands you one giant CSV, Nessus has its own format, and Dependabot speaks yet another JSON dialect. One calls it title, the next name, the third vuln_id. One says severity is HIGH, another says 7.5, another says Critical. If you want all of that in one place, you have to translate. This post is about how RiskRancher does that translation once, into a single model, so nothing downstream has to care where a finding came from.

Air-gapped by design: a vuln manager that doesn't phone home

Wed, 11 Mar 2026 00:00:00 +0000

Part of my series on RiskRancher, the open-source vulnerability manager I build. Source: github.com/Kuebiko-LLC/risk-rancher-core.

Intro

A vulnerability manager holds some of the most sensitive data an organization has: a map of exactly where it’s weak. So “where does this data go?” is a fair first question, and for a lot of teams, especially on isolated or classified networks, the only acceptable answer is “nowhere.” RiskRancher is built so that findings stay on the machine you run it on. In this post I want to be precise about what that means, including the one place it talks to the network, because I’d rather you trust a claim I can back up than a slogan.

Pure-Go SQLite: the no-CGO trick behind a single cross-platform binary

Thu, 12 Feb 2026 00:00:00 +0000

Part of my series on RiskRancher, the open-source vulnerability manager I build. Source: github.com/Kuebiko-LLC/risk-rancher-core.

Intro

In the last post I said RiskRancher is one Go binary and a SQLite file. That sounds simple, but there’s a specific technical choice that makes it actually work: the SQLite driver is pure Go, with no CGO. If I’d used the usual driver, the “download the binary for your OS and run it” story would have fallen apart. Let me explain why, because this is the kind of decision that quietly determines whether a project ships easily or painfully.

One Go binary and a SQLite file: vuln management without the Docker tax

Thu, 15 Jan 2026 00:00:00 +0000

Part of my series on RiskRancher, the open-source vulnerability manager I build. Source: github.com/Kuebiko-LLC/risk-rancher-core.

Intro

Most vulnerability-management platforms want a lot from you before they do anything useful. Stand up Postgres, add Redis, wire up a Docker Compose file, maybe a Kubernetes cluster if you’re feeling ambitious, and then you can start storing scanner output. I got tired of that, so I built RiskRancher to be the opposite: one Go binary and a SQLite file. Download it, run it, open your browser. In this post I want to explain that choice, because “boring and self-contained” turned out to be the whole product.