Security
Security overview
A tool that maps your network should be the least risky thing on it. This page says what NS-Discovery does with your data, what it can and cannot do in your network, and what we have not done yet.
What leaves the segment
Inventory, not traffic
A Sensor sends its Manager only the inventory: MAC and IP addresses, names, type and model, VLANs and switch-port neighbors, change events and findings, and the Sensor’s own health and network. Packets, their contents and credentials never leave the Sensor.
No vendor cloud, no telemetry
Neither the Sensor nor the Manager contacts us. There is no license check over the network, no usage reporting and no automatic updates: you install new packages yourself.
What it can and cannot do in your network
| Question | Answer |
|---|---|
| Does it send traffic? | No. It only receives. Two optional features are off by default and, when enabled, bounded by the operator: local ARP discovery, and DNS name lookups, which go to your own DNS server, never to devices. |
| Do we open inbound ports for it? | Not for Sensors: they only open an outbound connection. The Manager accepts connections on one TCP port (8443 by default) from Sensors and browsers. |
| Can the Manager run commands on a Sensor? | No. There is no command channel: the Manager cannot run commands, upgrade or restart a Sensor. A Sensor pulls an allowlisted set of its own settings over the connection it opens, validates them, and can be set to ignore the Manager entirely (managed_config.enabled: false). Active network traffic cannot be turned on from the Manager. A compromised Manager cannot be used to execute code in the networks it monitors. |
| How do Sensor and Manager trust each other? | Mutual TLS 1.3. A Sensor enrolls with a one-time token and pins the fingerprint of the Manager's certificate authority, so DNS tricks or another server cannot impersonate the Manager. Sensors can be revoked. The one-command install pins the Manager's server key, checks the package hash before installing, and never puts the token on the command line. |
| What privileges does the Sensor need? | On Linux it runs as a dedicated user with only CAP_NET_RAW and CAP_NET_ADMIN, under systemd sandboxing. By default its web interface listens on the loopback address only and is read-only; an optional signed-in HTTPS interface stays off unless you enable it. |
| How is hostile traffic handled? | Every decoder treats packets as hostile and checks bounds before every read, with tests for malformed input. Queues, request sizes and result sets are bounded. |
Access to the Manager
Single sign-on
OpenID Connect with your identity provider, so multi-factor authentication and leavers are handled where you already manage them. Local accounts lock after failed attempts.
Two-factor for local accounts
Authenticator-app codes (TOTP) with one-time recovery codes, required for administrators by default and optionally for everyone. A used code is not accepted twice.
Roles and site limits
Administrator, operator, viewer and auditor roles. A user or API key can be limited to chosen Sensors; the limit applies on the server to every read.
Audit log
Sign-ins, configuration changes and administrative actions are recorded and can be reviewed by auditors.
Building the software
Few dependencies
Written in Go, mostly on the standard library, and built without cgo (the SQLite engine is a pure-Go translation). Each dependency is reviewed for license, maintenance and security history.
Checked on every change
Automated tests including race detection, and govulncheck against the Go vulnerability database.
Reproducible binaries
CI builds the Sensor and Manager twice from the same commit and checks that the binaries are byte-identical. Each Debian package ships a CycloneDX software bill of materials.
Not done yet
We would rather say it than have you find out.
Independent assessment
No SOC 2 report and no external penetration test yet. Both are planned.
Hosted service
We do not host customer data today. Every deployment runs on the customer's or the service provider's infrastructure.
Report a vulnerability
Write to security@ns-discovery.com with the affected version and the steps to reproduce. We aim to acknowledge reports within three business days and credit reporters who wish to be named. We run no public service: please test against your own installation.