The maker behind Noxen
Noxen is built and maintained by one engineer, not a team. That matters more here than it would for most software: you are being asked to hand a program your SSH keys and point it at every machine you own. You should know whose program it is.
Paul Snyman
DevOps, Systems Engineer, Developer. hello@noxen.app
My background is in DevOps and systems engineering — keeping infrastructure reliable, observable, and boring. Noxen is made of the habits that job leaves you with: inventory before opinion, evidence before alarm, and a standing preference for whatever still works at three in the morning.
Why an operator wrote a CVE scanner
It started as an annoyance on my own network. A Proxmox node, a NAS, a Pi running DNS, a couple of VPSes, a handful of containers that had quietly become load-bearing — and no honest answer to one plain question: which of these is running a package with a known CVE this morning?
The tools that answer it properly are built for a different shape of problem. Enterprise scanners assume a security team, a change window, and a budget line. The good open-source options assume you will install something on every host and keep it fed. Both are reasonable for a fleet with an owner whose job is the fleet. Neither fits a person who has twelve machines, an hour on a Sunday, and a Mac already sitting there with the SSH keys in it.
So Noxen runs from the Mac. It reads what is installed over SSH using the keys you already have, matches that against a signed CVE snapshot, and tells you what changed since yesterday. No agent to install, no logs to ship anywhere, no account. The full check list has grown since, but that is still the shape of it.
Why Noxen flags things instead of logging into them
Noxen fingerprints exposed admin surfaces — a Home Assistant on a bare port, a Proxmox UI reachable from the wrong interface — and it will tell you they are there. It will never try a credential against one. Not a real one, not a default one, not on a host you own.
Partly that is a line worth not crossing: a scanner that tries passwords is indistinguishable from an attacker in your own auth logs, and "it was my own box" is a distinction your fail2ban config does not make. Mostly, though, it is that the alternative is worse software. A tool that locks you out of your own dashboard while checking whether you could be locked out of your own dashboard has failed at the only job it had. Finding the exposed surface is the useful part. Proving it opens is your call, with your eyes on it.
Why Developer ID, and not the Mac App Store
Noxen needs two things the App Sandbox does not permit: read access to your
existing ~/.ssh/config, and raw sockets for port scanning. There
is a version of this app that fits inside the sandbox, and it is a worse app
that asks you to re-enter configuration you already have.
So Noxen ships signed and notarised through Apple's Developer ID channel, and updates arrive over Sparkle with Ed25519-signed artefacts. You still get Apple's notarisation check on every build and tamper detection at every launch — you just get them without the sandbox. I wrote up the whole trade-off here.
What I try not to claim
- Noxen mirrors; it does not re-score. The feed is what VulnCheck NVD++ and OSV.dev already publish, indexed for package matching. If a CVSS score looks wrong to you, it is wrong upstream and Noxen should not be quietly "fixing" it.
- Compliance mapping is evidence, not certification. Noxen can map findings to CIS Controls v8, SOC 2, and ISO 27001 references so you have something to hand an auditor. It does not make you compliant and does not say it does.
- Heuristics say they are heuristics. Where a check infers rather than confirms, the finding tells you so. A false positive you can recognise is survivable; one dressed as a fact is not.
The other half of the same instinct
I also build PingKit, a network diagnostic toolkit for iPhone and Mac — same maker, separate products with separate codebases. PingKit answers "what is on this network and is it behaving"; Noxen answers "and which of those boxes is out of date". Between them they cover most of what actually goes wrong on a home or small-business network, from opposite ends.
Get in touch
Purchases, activation trouble, a finding you think is wrong, or a probe you wish existed — hello@noxen.app. A false-positive report is the most useful mail I get; it is the only way the matching rules improve.
For what Noxen is and how it is built, rather than who builds it, see about Noxen.