Core concepts

Four ideas explain most of the interface. Everything else is a view over them.

Network

A network is a CIDR you have told Loomscope about, IPv4 or IPv6.

Nothing is scanned until a network exists. Loomscope never probes a range you have not declared — not on installation, not on daemon registration, and not by inferring one from the daemon's own address. When discovery finds nothing, the first question is always whether a network exists.

A network can carry exclusions, so a range containing a fragile appliance can be scanned without touching that address.

Daemon

A daemon is the process that does the scanning. It lives on the network it scans and polls the control plane for work, so it needs no inbound connectivity and no port opened towards it — which is what makes a daemon behind NAT, or inside a customer's DMZ, an ordinary deployment rather than a special case.

One deployment can have many. Each authenticates with its own key, and each can be bound to a site.

Daemons never call cloud APIs. Cloud discovery runs in the control plane, so a daemon host holds no cloud credentials — if one is compromised, the attacker gets a scanner, not your AWS account.

Host

A host is a discovered machine, identified by a stable fingerprint rather than by IP address, so it survives DHCP changes instead of reappearing as a new machine every lease.

Hosts accumulate what has been observed about them: addresses, interfaces, open ports, identified services with versions, TLS certificates, vulnerabilities and a change feed. A host can also have a parent — a virtual machine under a hypervisor, a container under its engine — which is what the workload topology view draws.

Site

A site is a grouping: a building, a datacentre, a client. Daemons, hosts and networks belong to one, and the site picker in the header scopes every page you look at.

Sites are also a permission boundary. A per-site role override can raise someone's access for one location — a viewer across the organisation who is an editor for one site — but never lower it. Your organisation role is always the floor.

---

A useful way to hold all four: networks say where to look, daemons do the looking, hosts are what was found, sites decide what you are currently looking at.

Supporting ideas

Service and signature

A service is what is running on a port, not the fact that the port is open. It is produced by matching a signature — a pattern combining port, protocol, an HTTP endpoint and an expected response fragment.

Grafana is identified by /api/health returning something containing grafana, not by port 3000 being open. Signatures come in two forms with one internal type: a set compiled into the daemon, and YAML you drop into a directory and reload with SIGHUP. See Service signatures.

Confidence

Every service match carries a confidence score, and it propagates. A service matched by an endpoint response is more certain than one matched by a banner; a low-confidence version guess produces a lower-confidence vulnerability finding. Confidence is shown rather than hidden, because a finding you cannot weigh is a finding you cannot act on.

Observation

The daemon does not write to the inventory. It posts observations — batches of hosts, ports, services, neighbours, certificates and flows — and the control plane reconciles them. That is why a scan can be partial, interrupted or duplicated without corrupting anything.

Snapshot

A snapshot freezes the whole inventory at a point in time. One is taken daily; you can take one by hand before a change window. Any two snapshots diff against each other, which is the fastest way to answer "what changed since Friday".

Organisation

Every business table carries an organization_id, enforced by PostgreSQL row-level security with FORCE enabled — so a query that forgets its tenant filter returns nothing rather than returning somebody else's estate. One deployment can hold several organisations; a service provider with several clients is the usual reason.