📦 bits is generally available — four signed agents you can download and verify

The bits family — the agents that run on your own machines — is now downloadable from the downloads page. Four binaries, every one signed with the same key, every one verifiable before you run it.

Agent	Version	What it does	Platforms
bitcollector	v0.1.0-ga	Evidence-grade asset truth from a host: processes, packages, ports, accounts, posture	Linux amd64/arm64, macOS amd64/arm64, Windows amd64
bitscanner	v0.1.3-ga	Finds the devices your inventory does not contain	Linux amd64/arm64
bitenforcer	v0.1.0-ga	Hardening policy validation and pre-flight	Linux amd64/arm64
bitmapper	v0.1.0-ga	Live connection capture — endpoints, ports, protocol, counters, connection state. No process attribution in this release	Linux amd64

Correction: bitmapper v0.1.0-ga does not attribute flows to processes

The row above first read "Live connection capture with per-process attribution", and the bitmapper entry under What each agent is for said bitmapper reports "which processes are actually talking to what, attributed per connection". Both were false of the binary this post announces, and they were false in the direction that costs you: per-process attribution is the one thing that distinguishes bitmapper from an off-host scanner, and it is the reason to deploy it at all.

Measured against the published 0.1.0-ga — commit 64ebc64, the artefact on the downloads page today — 0 of 12 captured flows carried any process attribution, including a 60-second flow whose owning process was alive and pollable throughout. destination_process was never populated anywhere outside test code. In that build the lookup is attempted once, when the connection is created, against a socket-table snapshot that cannot contain a new outbound connection's socket; nothing looks again on a later packet, and there is no listening-socket inference to fall back on, because that code does not exist in 64ebc64 at all.

What v0.1.0-ga actually does is passive flow capture, and that part is real. Every tracked connection is exported as a flow record: source and destination endpoints, ports, protocol, connection state, direction, interface, first and last seen, duration, and byte and packet counters — with no payload bytes, ever. That is a useful answer to "what is this machine talking to". It is not an answer to "which process is doing it".

Per-process attribution is implemented and verified — it is simply not in the binary you can download. On the same harness that measured 0 of 12, the replacement attributes 12 of 12, records the answer against the end that actually owns the socket, and separates a direct socket match from an inference, declining to name anyone where a port has several listeners. It lands in the next bitmapper release. We are not attaching a date to that here; we have already told you once that this capability had shipped when it had not.

If you downloaded bitmapper on the strength of the original sentence, that is our error. Process attribution sets out exactly what today's binary resolves, and what replaces it.

Why some agents list fewer platforms than others

Because a binary that installs, reports healthy and collects nothing is worse than no binary.

Every platform in that table is one where the agent does its job. Where it would not, we have not published it, and we would rather say so than let you discover it after a rollout:

• bitenforcer is Linux-only. Its entire surface is iptables, sysctl, systemd and SELinux. On macOS those do not exist, so the agent would validate nothing and its rollback primitives would have nothing to restore.
• bitmapper is Linux amd64 only. It needs a real packet capture library compiled in. A build without it still produces a runnable binary — one that captures nothing at all — so our release pipeline refuses to sign an artefact that cannot demonstrably capture.
• bitscanner is Linux-only for the same class of reason: its neighbour and route readers are implemented for Linux.

We expect these lists to grow. When they do, it will be because the agent was exercised on that platform, not because it compiled.

Verify before you run

Every release ships a detached signature, an SBOM and a build attestation per binary, plus a signed SHA256SUMS covering the whole set. Builds are reproducible: the pipeline builds twice from scratch and refuses to publish unless both are byte-identical.

The signing key is published in three independent places that must agree — the docs site, a DNS TXT record holding its fingerprint, and a second TXT record holding the key itself. Cross-check at least two. A signature is only worth the trust anchor behind it, and one source is a ritual rather than a check.

# Fetch the key over DNS — works inside CI, where bot protection blocks plain HTTPS fetches
dig +short TXT _cosign-key.cert-ix.com | tr -d '"' | sed 's/.*key=//' \
  | base64 -d | openssl pkey -pubin -inform DER -out cosign.pub

# Confirm it is OUR key, against the fingerprint published on the docs site
openssl pkey -pubin -in cosign.pub -outform DER | sha256sum
# expected: 552839f6b1b1eb0934557e1886326c7270584fa602fbf56f84754a98be3de822

# Then verify the release you downloaded
cosign verify-blob --key cosign.pub --bundle SHA256SUMS.sig \
  --insecure-ignore-tlog=true SHA256SUMS
sha256sum --check --ignore-missing SHA256SUMS

DNS is the transport, not the trust anchor

cert-ix.com does not yet publish a DS record, so DNS answers are not cryptographically validated end to end. Fetching the key over DNS is convenient and works where HTTPS is blocked, but the fingerprint comparison against the docs site — loaded over HTTPS, with a validated certificate — is what establishes trust. Do not skip it.

Full instructions, including what each file in a release is for and what a failed check looks like, are in Verifying your downloads.

What each agent is for

• bitcollector — what is on this machine, as evidence rather than assertion. Every batch is attested and the chain can be verified offline, with no access to Cert-IX at all.
• bitscanner — the devices an agent-based inventory cannot see by construction, because nothing is installed on them. Ships inert: it puts no packets on your network until you explicitly arm it, and authorisation cannot come from an environment variable.
• bitenforcer — what a hardening policy would change, before it changes anything. v1 validates and reports; it does not apply.
• bitmapper — what this machine is actually talking to, flow by flow: endpoints, ports, protocol, counters and connection state, captured live from its own interfaces. In v0.1.0-ga those flows carry no process attribution — see the correction above before you plan around it.

Where to start

Download an agent, verify it, and read the page for whichever one you picked. If you are not sure which, What is bits? explains how the four fit together and, just as importantly, what each one deliberately does not do.