A port scanner is reconnaissance. A packet capture tool is interception. A fuzzer finds bugs for whoever is running it. A model that writes code writes whatever code it's asked for.
That's the ordinary condition of nearly everything in security, and of most systems engineering besides. A hammer builds houses and breaks windows, and nobody has worked out how to make one that only does the first.
Why "don't build it" isn't available¶
Withholding a capability assumes the capability is scarce. Usually it isn't:
- The technique is published. Security research is adversarial and public; withholding a tool doesn't withhold the method.
- The adversary is resourced. The actors you'd most like to deny are the ones best able to build it themselves.
- Defenders need it more. You can't test what you can't attack. Withhold offensive tooling and you disarm the defender, because the attacker was never waiting on your release.
That's the standard argument for publication and it's largely right. It also gets used to wave away a real question: the marginal effect of a particular release.
Where the argument weakens¶
- Weaponisation gap. A proof of concept that needs expertise to use is a different object from a packaged tool that needs none. Lowering the skill floor changes who can attack, and "it was already public" doesn't address that.
- Scale. A technique that works once differs from one that works against everything at once. The automation is itself the capability.
- Patch availability. Publishing before a fix exists and publishing after are different acts carrying the same information.
That third one is why coordinated disclosure exists. The hard cases are the ones where a working proof of concept is public before the official patch ships, which is the scenario the norm was built to prevent and the one it handles worst.
What open tooling makes possible¶
An open security tool is how a competent person without a budget gets to be competent. Whoever runs IT for a housing association, a school trust or a regional hospital can scan their own estate, capture their own traffic and fuzz their own application. None of them is buying a commercial assessment; all of them can run nmap and Wireshark and a fuzzer tonight, because somebody published. Remove that and defensive capability becomes a purchase that tracks budget rather than need. The least-resourced organisations holding the most sensitive records then get the least protection. That is the situation in healthcare and it is not improving.
The engineering benefit is more specific. Tooling that attacks your own system turns a class of bug from unknown to routine: the memory-safety fault on malformed input, the parser that accepts what it should reject, the authentication path that behaves differently on the fourth attempt. Before fuzzing was normal those shipped and were found by incident. Now a build server finds them overnight, because the tools were free.
The same applies to automated vulnerability discovery. A tool that finds bugs faster than people can lands on both sides at once, and which side it helps more is decided by access. Cheap and open, the defender runs it over their own code continuously and the bugs are gone first; expensive and licensed, the defender runs it quarterly if at all while the attacker runs it constantly. Our bet is that this becomes the central security question of the next decade, settled by distribution rather than capability.
The chokepoint is neither a registry nor a key. It is the ability to classify a technique as a controlled export.
Intrusion software has been within scope of the Wassenaar Arrangement for years. The first attempts to implement those controls were drafted broadly enough that publishing a proof of concept, or emailing a colleague abroad a capture tool, was arguably a licensable export. The community pushed back and the language narrowed, but the statute remains, applying to a category defined by what software does rather than what it is.
The burden is where it bites. A large company has an export compliance function and can file for a licence; an individual researcher, a university group or a four-person consultancy cannot, and will decline to publish rather than find out. A control written to stop surveillance vendors selling to abusive governments lands hardest on independent research and barely touches the vendors, who have lawyers and sell under government licence anyway. The surveillance industry gets regulated into legitimacy and the open community into silence.
Watch for the same move applied to model weights. The argument that a capable code-writing model is a dual-use export is already being made, and it is more plausible than the intrusion-software version because the artefact is one file with a clear owner. If it lands, open weights become a customs question and the only parties who may lawfully hold a frontier capability are three companies and several governments. The capability does not get rarer; it concentrates, the opposite of what the policy says on the tin.
Here at AxisOps our position is that defensive capability has to be ownable: tools you can read, run on your own hardware and keep running when a licence lapses or a jurisdiction changes its mind. A regime in which you may inspect your own systems only while somebody's subscription is current is the thing to refuse, and export control is the likeliest route there.
The choice that remains¶
A judgement rather than a measurement:
- Coordinate disclosure. Report first, publish once a fix exists or a reasonable deadline has passed. The deadline matters: unbounded delay serves the vendor alone.
- Publish the defence alongside the attack. A detection rule, a mitigation, a configuration change. The most practical item here and the one most often skipped.
- Be straight about what you built. A tool described as a "security scanner" that is in fact an exploitation framework does nobody any favours, least of all you when somebody reads it.
That list is least sufficient against the state and military case. Technology built for defence gets used offensively; technology built for legitimate law enforcement gets used against journalists. The commercial spyware industry is the clearest example, and the mechanism isn't deception: capability is fungible and the customer list changes. For one engineer the leverage is small but real. It sits in who you build for and what you will work on, a career decision rather than a technical one. Stated plainly rather than resolved, because we don't think it resolves.
So: build the tool. Publish the defence with it. Be specific about the threat model it serves. And treat "it would exist anyway" as an explanation rather than an excuse: true, and still not an answer to what you chose to spend your time on.