Talos

Why it exists

Auditing how a server is hardened almost always means installing something. And that is where the conversation starts: whether you are allowed, what dependencies it drags in, who signs off that it will not touch anything. In a small company with a server in production, that conversation drags on and the audit never happens.

I wanted a file you copy, run, get a report from, and delete. No installer, no interpreter and no write permissions anywhere.

How it is built

One Go binary per operating system, with no external dependencies. Read-only: it does not touch a registry key, does not rewrite a config file, does not restart a service. That restriction has been in the design since day one, because a tool that can fix things can also break them, and then the who-signs-off conversation comes back.

The catalogue is 147 checks, 109 for Linux and 38 for Windows, and none of them live in the code. Each one is a data sheet with its identifier, its severity, its weight in the score, the controls of the Spanish ENS framework it covers and the text for how to fix it. Adding a check means adding a sheet, so somebody who does not know Go can do it.

Alongside it there is a catalogue of critical vulnerabilities by version. It compares the installed version of a package with the version where the flaw was fixed in that distribution, which is not the same in Debian as in Ubuntu. It covers PwnKit, Looney Tunables, regreSSHion, sudoedit, polkit, glibc iconv and CopyFail.

And a single-file HTML report, with severity filters, light and dark themes and a print stylesheet so it comes out right as a PDF. A single file because a report with a folder of assets next to it cannot be attached to an email.

Built with agents

The 147 checks were not written by hand. I got them done by directing AI agents, which is a different way of working from asking a chat for code and pasting it.

The rules are written as files the agent has to comply with: what shape a sheet has, which fields are mandatory and what it must never write. On top of that, checkers that break the build when one of them skips a rule.

The design of the format, the judgement about what is worth checking and the verification that each sheet tells the truth are mine. The volume of mechanical work is the agents, and it is the reason the catalogue reaches 147 rather than stopping at twenty.

The vulnerabilities-by-version catalogue

This is the part that took me longest, and not because of the code. Each distribution’s security tracker says different things about the same flaw, and comparing versions the naive way gives false positives by the handful. If the report says three critical things and two of them are not, nobody believes the third.

I verified the entries by hand against the Debian and Ubuntu trackers, and tested them in containers across several distributions until they stopped firing where they should not. It is slow work and there is no shortcut.

Design decisions

Go and not Python. The requirement was a dependency-free binary, and in Python that means bundling an interpreter.

Checks as data. It costs more up front, because you have to design a sheet format and an engine that reads it. In exchange the catalogue grows without recompiling, and without whoever extends it having to understand the engine.

Read-only, no exceptions. At one point I considered adding a mode that fixed the trivial things. I did not: the reason somebody lets this run in production is precisely that it cannot do anything.

Pending

On Windows the tool only audits and never remediates, and there the catalogue has fewer checks than on Linux.