How Startups Should Keep Security Testing Tools Off the Public Web

A tool built to test security can become a security problem when it is reachable by anyone on the internet. For a small startup without a dedicated security team, the important question is not whether a particular tool is in the news. It is whether your own testing tools have a public address and no meaningful access boundary.

TechCrunch reported that researchers found hundreds of servers hosting the penetration-testing tool Artex exposed to the internet, allowing anyone access to the tool. That report is a reason to inspect your own setup—not evidence that every security tool is exposed, or that every exposed server was misused.

Start with reachability, not the tool name

Security tools are often run for a limited purpose: a test, an investigation, or a development task. Over time, a temporary server can remain online after the work ends. The risk to check first is straightforward: can an untrusted person reach the service from outside your organization?

Make a short inventory of security testing tools and the machines or services that run them. Include temporary environments and systems managed by contractors or individual team members. For each one, record an owner, its purpose, and whether it needs to be online.

A practical sequence for reducing exposure

1. List what is running. Ask engineering and security owners which testing tools they run, where they run them, and who is responsible. Check cloud infrastructure and development environments as well as long-lived servers.
2. Verify access from outside. For each service, confirm whether it is reachable from the public internet. Do not rely only on the original setup notes: compare the intended access with the current configuration.
3. Remove unnecessary public access. If a tool is not needed, shut it down. If it is needed, limit access to the people and networks that require it. Use your organization’s established access controls rather than creating a separate, hard-to-maintain exception.
4. Confirm the change. Test that the service is no longer publicly reachable while authorized users can still do their work. Record the owner and the intended access so the next change does not quietly reopen it.
5. Make the check repeatable. Add these services to your regular infrastructure review, and revisit them when a test or project ends. A named owner and a recurring check are more useful than a one-time cleanup.

Who should act now—and what remains uncertain

Act now if your startup runs security testing tools on internet-reachable infrastructure, uses temporary test servers, or cannot say who owns those services. The first step is an inventory and an external reachability check—not an assumption that an incident has occurred.

You can wait on a larger security project if you have confirmed that these tools are not publicly reachable, access is intentionally limited, and there is an owner who reviews the setup. Keep the review in your normal operating routine.

One limitation: restricting access does not establish whether a service was previously accessed or whether other weaknesses exist. If you find a tool exposed unexpectedly, preserve relevant logs and follow your incident-response process instead of treating the configuration change as proof that the issue is resolved.

Keep the boundary visible

The useful lesson from the Artex report is not to stop testing your systems. It is to keep tools with powerful capabilities behind deliberate access boundaries, and to know who is accountable for them.

Takeaway: Pick one security testing service today, confirm who owns it, and verify whether it is reachable from outside your organization.