What it was

Dan Farmer had form. As a computer science student at Purdue in 1989, working with his professor Gene Spafford, he had written COPS - the Computer Oracle and Password System - a suite of small scanners that checked one machine for known weaknesses. It worked, it was useful, and it only examined the host you ran it on.

In 1995 he and , a Dutch physicist and programmer at Eindhoven who had already written TCP Wrapper, produced the version that looks across a network. SATAN - Security Administrator Tool for Analyzing Networks - was written mostly in Perl, scanned remote Unix hosts for known vulnerabilities, and reported what it found.

Two design decisions made it different from anything before it, and both are worth noticing because every scanner since has copied them.

It had a web interface. In 1995. Forms to enter targets, tables of results, all in a browser at a time when most security tooling meant a terminal and a manual. That alone put it in reach of administrators who were not specialists.

And it explained itself. For each type of problem found, SATAN offered a tutorial: what the problem was, what its impact could be, and what to do about it - correct an error in a configuration file, install a fix, restrict access by other means, or simply turn the service off. It reported the weaknesses without exploiting them. That combination - find, explain, advise, do not break - is the template for every credible vulnerability report written since, and a great many modern tools still do it worse.

The humour was part of it too. A command called repent rearranged the acronym from SATAN to SANTA for anyone offended by the name, and Neil Gaiman drew the artwork for the documentation.

The panic

The authors announced the release in advance. What followed, in the weeks before 5 April 1995, was a public alarm that reads oddly now and read reasonably then.

Newspapers ran the obvious headline. A national laboratory and other research institutions were reported to be scrambling to protect themselves ahead of an anticipated wave of intruders armed with the new tool. The Department of Justice was among those making threatening noises. The expectation, stated widely, was that publishing a program which found security holes would cause a great many computers to be broken into.

And Silicon Graphics fired Farmer for releasing it.

His position was the one the industry now holds without argument: the holes were already there, the people who wanted to exploit them already had tools, and publishing a good one would force organisations to take security seriously rather than continuing to rely on the fact that nobody had looked. He and Venema wrote the counter-argument into their own documentation, and did not pretend it away - they described SATAN as a two-edged sword which, like many tools, could be used for good and for evil purposes.

His old employer, Sun, was impressed and hired him back.

How it was settled

Nothing much happened on 5 April. There was no wave. What happened instead took a decade, and it settled the argument completely in Farmer's favour - not by anyone winning a debate but by the entire industry adopting his position as its business model.

SATAN itself was never updated and was superseded by Nessus and SAINT. Those were superseded in turn, and today every vendor in this catalogue sells or ships a scanner: the vulnerability assessment built into a firewall, the posture check in an endpoint agent, the compliance scan in a cloud console. Penetration testing became a profession with certifications, insurance requirements and a standard contract. The tools Farmer was fired for publishing are now a line item in the budget of every organisation that fired anyone for publishing them.

The interception tools article makes the same observation about proxies, and the shape is identical: there is no technical property that separates the auditor from the attacker; what separates them is consent and disclosure. SATAN is where the profession learned that the hard way, in public, with someone losing their job over it.

What the case actually teaches

The tool is not the exposure. Every host SATAN found was vulnerable before SATAN existed. A scanner changes who knows, not what is true. This is the same argument the Kaminsky disclosure turns on and the same one behind the observation that a patch is a description of the vulnerability - information moves, and the only question is whether it reaches defenders first.

Explaining is the product. The part of SATAN that survived is not the scanning; port scanning was not new. It is the tutorial attached to each finding. A list of findings creates work; an explanation creates capability, and the difference is whether the person reading the report can act without escalating. Anyone who writes security reports for a living, or teaches people to read them, is working in a tradition that starts here.

And the argument is not settled permanently, only for this case. It reopens every time the capability jumps: with Metasploit, with automated exploitation, and now with systems that discover vulnerabilities rather than merely checking for known ones. The Pessimists Archive drew the parallel explicitly in 2026, setting the reaction to SATAN beside the reaction to Anthropic's Mythos - a model tier capable of finding security flaws in software, released to a small number of organisations rather than to everyone, with a sibling model carrying additional restrictions in cybersecurity among other areas. Thirty-one years apart, the same sentence appears in both arguments: this will help attackers more than defenders. The 1995 objections were not stupid - they were about who gets the capability first and how fast defenders can absorb it, and those are exactly the right questions to ask about any new class of tool. What the SATAN case suggests is not that the objections are always wrong, but that withholding a capability that others can build anyway has never yet been the thing that protected anybody.

Sources