TestNet wraps a dozen scanners behind an asset inventory and a DSL

The inventory is the product, scanning is a feature of it

TestNet is described as an asset management system that provides internet asset management and monitoring services and builds a detailed asset repository. The stated purpose is to help corporate security teams or penetration testers conduct deep reconnaissance and analysis of target assets, providing continuous risk monitoring from an attacker's perspective, keeping track of asset dynamics in real time, and reducing the attack surface. Read that carefully, because it defines the category. This is not a fuzzer or an exploit framework. It is an inventory system that happens to have a large set of scanners wired into it, and the value is in the repository and the tracking rather than in any single scan. The asset management scope is broad, covering companies, domains, subdomains, IPs, ports, web interfaces, APIs, vulnerabilities, asset tags and blacklists. There is project management for multiple independent asset projects, user management with permissions, roles and access control, and import and export of asset data in Excel and JSON formats. A space engine renders asset topology graphs with force-directed relationship maps, alongside multi-dimensional search.

Tool Spec and Workflow Spec YAML is where the customisation lives

The mechanism that makes this more than a list of shell scripts is a declarative specification layer. The feature list names Workflow and DSL customization, with support for Tool Spec and Workflow Spec vNext YAML definitions, enabling customized scanning scripts and process orchestration. The layout confirms it, with a testnet-registry directory described as DSL tools and workflows files, separate from the server, web and client directories. A tool spec describes what a scanner invocation is, a workflow spec describes the sequence and the parameters, and the scan node executes it. That separation is what lets a team encode a repeatable process rather than a list of ad hoc commands, and it is why the registry is a versioned directory in the repository rather than a hardcoded list. The scan client exposes it directly on the command line, where a spec file is validated first and then a test run can be performed against a mock file with verbose output, which is a fast way to check a workflow before pointing it at a real target.

A distributed node model with STOMP wakeup

Scanning is not done by the server. The project describes node configuration customization, with flexible configuration of distributed multi-nodes and a real-time STOMP communication wakeup mechanism, and the top level directory list names testnet-client as a Go distributed scan client node. The Go client registers itself with the server and receives work, and the STOMP wakeup is the mechanism that lets the server push a job to an idle node without polling. A node is started by pointing the client at a server address with a registration secret and a node name, and the client runs as a separate process from the server and the web UI. This design is the point of the whole system. Scanning is slow and can be parallelised, but it is also the part that needs credentials, network access and the third party tools installed, and keeping it in a separate binary means the management plane can live in a data centre while the scanners sit on the network they are allowed to touch. The trade-off is operational: you now have a server, a web frontend, a database, Redis, a client and a set of nodes to keep alive.

Space search engines are a first class input

The second integration group is space search engines, described as quick integration with major cyberspace search engines such as Fofa, Hunter, Shodan and Quake. This is a different kind of asset discovery from active scanning. A space search engine has already indexed a great deal of the reachable internet, and querying it tells you what your organisation already exposes before you send a single packet. For an asset management system, that is a cheap way to bootstrap the inventory, and it also explains the tool list, which includes an ICP filing query for basic queries. What you do with the results is up to you. The repository also carries a whole space engine section in its screenshot gallery, and the topics and description confirm the intent, with asset management, information collection, exposure management, subdomain scanning, C segment scanning, port scanning, vulnerability scanning, Hunter and Fofa all named. The honest framing is that the system gives you one place to see what the search engines know about you and what your own scanners confirm.

A wide set of external tools, none of them written here

Every scanning capability in the list comes from an existing tool. Subdomain scanning uses OneForAll and subfinder. Port scanning uses nmap, naabu, masscan and Rustscan, with firewall detection. Web discovery and screenshotting uses httpx, web fingerprinting uses TideFinger and xapp, vulnerability scanning uses nuclei, Xpoc and Afrog, sensitive directory scanning uses DirSearch and ffuf, and the web crawler is katana. That has two consequences. First, the quality of each capability is the quality of the tool behind it, and the project has no control over that. Second, and more importantly operationally, each of those tools has to be installed and reachable on whichever node runs the workflow, so a scan that calls nuclei fails on a node without nuclei rather than degrading. The scan node in particular is the component that needs the widest set of binaries present, and the system is designed so you can add nodes with different tool sets, but you have to plan that distribution yourself. There is no bundling of these tools in the project itself.

What the AI assistant layer actually does

The feature list includes an AI assistant described as a built-in MCP (Model Context Protocol) adapter layer, allowing external AI assistants to retrieve assets and execute tasks more intelligently and efficiently. This is worth reading narrowly rather than generously. An MCP adapter exposes the system's own data and operations to an assistant that you attach, so the assistant can query the asset inventory and trigger task execution through the same interfaces the rest of the product uses. The adapter does not bring a model with it. What the assistant can then do depends on the tools you expose and the permissions behind them, which is the same permission model as the web UI, with user management, role assignment and access control in place. There is also a licence toggle in the environment file, with LICENSE_ENABLED set to false and a comment saying to set it to true in production, which is the mechanism that gates the licensed tier. Whether the AI layer is part of that tier is not stated in the documentation available here, so read the deployment guide before you assume either way.

Running the stack and the legal frame around it

The deployment is three services, a database and a client. The top level of the repository holds a docker-compose.yml, an nginx.conf, a testnet-pg.sql initialisation script, a gen-certs.sh script, install.sh, install-client.sh, testnet.sh, testnet.ps1 and a .env.example. The compose file brings up PostgreSQL 16 and Redis 7, with healthchecks, resource limits, and a Redis configured with appendonly, a password, a 200mb memory cap and a volatile-lru eviction policy. The server image runs with the prod profile and a JDBC URL pointing at the db service. For local work, the developer path starts the dependencies with docker compose -f docker/docker-compose-dev.yml up -d, then the backend with mvn spring-boot:run in testnet-server, the frontend with npm install and npm run dev in testnet-web, and the scan node with go run ./cmd in testnet-client. The one-line install for users is a curl of install.sh piped to bash, with the deployment guide linked for the details. The disclaimer is explicit and should be read as a precondition rather than boilerplate: the tool should only be used in enterprise security architecture where sufficient legal authorization has been obtained, users must ensure actions comply with local laws, and the developers assume no legal or joint liability for illegal acts. The one-line install for a user is:

curl -fsSL https://raw.githubusercontent.com/testnet0/testnet/main/install.sh | bash

For local work the developer path is:

docker compose -f docker/docker-compose-dev.yml up -d

then the backend, the frontend and the scan node, each started from its own directory:

cd testnet-server
mvn spring-boot:run

cd testnet-web
npm install
npm run dev

cd testnet-client
go run ./cmd -server http://localhost:8081 -secret default-client-secret-for-dev-environment-32chars -name MyNode

The client flags are the registration details: where the server is, the shared secret, and the node name shown in the interface.

Editorial conclusion

Adopt TestNet when you need a persistent inventory of your own attack surface and a repeatable, scheduled scan process across it, and when you are authorized to scan everything you point it at. Do not adopt it for a single ad hoc scan of a range you own, since the setup cost is a full stack, and do not treat it as a compliance product, since the licence toggle in the env file is off by default. Verify first that the tools it drives are on the nodes you deploy, that the scan node secret is unique and long enough, that the CORS and licence settings match your deployment, and that the legal authorisation for scanning each target exists in writing before a scheduled task runs it.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. testnet0/testnet on GitHub