What is bits?

bits is the family of small, signed binaries Cert-IX puts on your hosts. They exist because there is a question a cloud scanner cannot answer from the outside: what is actually on this machine, what state is it in, and can you prove it?

Everything here is written for the person with a deadline — the one answering a NIS2, DORA, ISO 27001 or SecNumCloud question and needing an answer that survives being challenged.

The jobs, in order

An estate you only half know creates five jobs, and they have to be done in this order:

#	The job	Who does it
1	Know what I have.	bitcollector
2	Find what I do not know I have.	bitscanner
3	Know what state it is in.	bitcollector
4	Change that state safely.	bitenforcer
5	Prove all of it to an auditor.	the family — and this is the point

Almost every tool on the market does 1 and 3. Job 2 is the one an agent-based inventory cannot do by construction: it can only ever contain machines somebody installed an agent on, so the printer, the lab switch and the contractor's laptop are missing not because anything failed but because nobody knew to look. And very few tools do 5 honestly. That is what bits is shaped around: not "visibility", but a defensible answer.

Job 5 is not a report you export at the end. It is a property the data has from the moment it is captured — every batch of bitcollector telemetry is signed on the host and chained to the batch before it, so you can prove your own inventory was not altered afterwards, including by us. See bitcollector for how that works, and its honest limits.

The boundary that settles every question

There is exactly one rule for deciding which binary owns a capability, and it is about the verb, not the subject area:

The verb is the boundary

• bitcollector READS and PUBLISHES. It is the single publisher of what a host is. It never writes to the host and never enforces anything.
• bitscanner LOOKS OUTWARD and PUBLISHES. Same verb, opposite direction: bitcollector reads the host it runs on, bitscanner reads the segment around that host. It never writes to the host either, and by default it puts no packets on the network at all.
• bitenforcer OWNS WRITING, and PROVING ITS OWN WRITE. It is the only binary that may ever write hardening state: one-shot, local, operator-invoked. It never ships telemetry. This is an ownership rule about the product family, not a description of v1 — bitenforcer v1 does not change hosts; it plans and reports only.

The test: if the answer is about this machine and must be continuously true across the fleet, that is bitcollector. If it is about the wire this machine is on — an address that answers and that nothing in your inventory explains — that is bitscanner. If the question is "did the change I just made land on this box", that is bitenforcer.

A domain split — "collector does inventory, enforcer does hardening" — sounds tidier and collapses immediately, because bitenforcer must read sysctls and bitcollector must report SELinux mode. So the split is the verb, and no capability is built in both. It is also why bitscanner does not collect processes, packages or accounts: those are the collector's, even though the same binary is standing on the same host.

What bitenforcer v1 does today

bitenforcer v1 does not change hosts. It ships validate and apply --dry-run: it reads your policy, plans every change, and shows you the complete change set — then refuses to apply it. That is a deliberate scope decision, and the reasons are worth reading before you plan a rollout. See bitenforcer.

The binaries

bitcollector — evidence-grade asset truth

A lightweight agent that runs continuously and reports what the host is: hardware and OS, installed software, running processes, listening ports, established network peers, local accounts, and the machine's live security posture.

What makes it different from an inventory agent:

• Every batch is signed on the host and hash-chained to the one before it. Your auditor can verify the chain offline, with no network and no Cert-IX access at all, using the agent's own verify subcommand and a trust anchor they get off your host with export-pubkey.
• Privacy is the default, not a setting you remember to turn on. Process command lines are off by default. Environment variables and file contents are never collected. The local-account collector publishes UIDs rather than login names unless you opt in — with one documented exception in the binary you can download today (0.2.0-ga): process records carry the owning account's login name, and no setting suppresses it short of disabling the process collector. The next release adds collectors.process.identity, which defaults to publishing the uid and never the name. See privacy and local accounts.
• Posture is observed, never assumed. sshd's effective configuration comes from sshd -T, the firewall from the live ruleset, sysctls from /proc — never from re-reading a config file that may not be what the kernel is doing.

→ bitcollector in detail

bitscanner — the devices your inventory does not contain

A lightweight agent that looks outward from the host it is installed on and reports what else is on the segment: neighbours with their addresses, MAC vendors and device types, the routes and gateways out, and — only if you arm it — the services those neighbours are running.

What makes it different from a network scanner:

• It ships inert. Two separate switches must both be true before a single packet is sent, and every probe defaults to off, so scanning.enabled: true on its own still sends nothing. Measured on a host with 118 real ARP neighbours: four consecutive cycles, zero probes.
• The authorisation cannot come from the environment. scanning.* and security.* are readable only from the config file. Setting one from an environment variable stops the agent and names the variable — because an acknowledgement that a shell profile could supply would not be an acknowledgement.
• Every packet is authorised at the moment it leaves, by one guard, against one allowlist, with a machine-readable reason recorded for each decision — not by a target list filtered three functions earlier.

→ bitscanner in detail

bitenforcer — hardening policy validation and pre-flight

A one-shot command-line tool. You give it a declarative hardening policy; it tells you exactly what applying that policy would do to this host — every file, systemd unit, firewall rule, sysctl and account, in the order it would touch them — with candidate content run through the real validators (sshd -t, visudo -c, nft -c, iptables-restore --test) and with lockout findings measured against the session you are sitting in.

v1 ships validate and apply --dry-run only. It does not write to the host, and no flag makes it. "Show me exactly what would change, and refuse to guess" is the product.

→ bitenforcer in detail

bitmapper — what this host is talking to

bitmapper watches the packets crossing a host's own interfaces and attributes each one to the process that owns the socket. Where an inventory tells you a machine exists, a capture tells you what it actually talks to, and what on it is doing the talking.

It ships, and it is the narrowest of the four. 0.1.0-ga is published and signed for linux/amd64 only — capture needs a compiled-in libpcap, so bitmapper is the one bit that cannot be cross-compiled. What reaches the platform is flow records: endpoints, ports, protocol, counters, connection state and the attributed process — no payload bytes, no packet captures, and not the process command line. Parts of the agent are still unbuilt (no service-topology aggregation, no Prometheus metrics), and its pages list them rather than leaving you to find out.

→ bitmapper in detail

Why the set beats any one of them

bitcollector reports that a host has a vulnerable package and that a specific control is verified enforced on that same host. That turns "4,000 findings" into "the 40 where the compensating control is not actually there".

bitscanner answers the question none of that can: whether the segment those hosts sit on also carries devices that report nothing at all. A finding count is only as honest as the denominator behind it.

bitenforcer takes the policy that would close those 40 and shows you the exact change set before anyone touches anything — including what it would do to your own access.

What you get for an audit

The auditor asks	What you hand over
"What was on this host on 12 March?"	The attested telemetry batch, with the signature and the chain position
"How do I know it wasn't edited afterwards?"	bitcollector verify, run by them, offline, against your spool
"How do I know Cert-IX didn't edit it?"	The trust anchor comes off your host, not from us
"Is control X enforced, or just written in a config file?"	Posture is observed host state — sshd -T, live ruleset, /proc
"Is anything on that segment not in the inventory?"	bitscanner's neighbour records, with the address, MAC, vendor and first-seen time — and the scan envelope showing what it was authorised to look at
"What would this hardening baseline change?"	bitenforcer apply --dry-run, item by item

Before you install anything

All four binaries are reproducibly built, ship a CycloneDX SBOM, and are signed with cosign using the same family key. The signature is only worth what the key check is worth, so start here:

Product	Version	Platforms
bitcollector	0.1.0-ga	linux amd64/arm64, macOS amd64/arm64, Windows amd64
bitscanner	0.1.3-ga	linux amd64/arm64
bitenforcer	0.1.0-ga	linux amd64/arm64
bitmapper	0.1.0-ga	linux amd64

The platform lists differ on purpose — each page says what is withheld and why, and the release table collects the reasons in one place.

→ Verifying your downloads — including the trust-anchor problem that most verification instructions quietly skip.

Next steps

• bitcollector — what it collects, how to run it, and what it costs. Then the evidence chain and privacy and local accounts.
• bitscanner — what it discovers, then the two switches that arm scanning and what leaves the host.
• bitenforcer — what v1 does, and why it deliberately does not enforce.
• Verifying your downloads — prove the bytes before you run them.
• Asset Management — where the telemetry lands.

Questions? Email [email protected]. Security issues go to [email protected].