How we test our own security

How the Tonvin Collection checks its own security: the tooling we built, what it looks for, the open-source software it is built on and the limits we hold it to. This page describes our method. It does not publish results.

Last reviewed on 25 October 2026. To report a problem, see the security page.

The approach

We test our own systems and nobody else's. Every scan, from a single port check to a full web scan, is pointed at a target we own, and each target is on an explicit list before anything runs.

We start passively. The first pass reads what a system already shows to any visitor: its open ports, its certificate, its headers and its DNS records. Anything more active comes second, and runs with a rate limit and a time limit.

We keep evidence. The output of each run goes into one evidence store with an audit trail of what was run and when. Secrets that turn up in the output are redacted before they are stored, and reports can be compared run against run, so a fix can be re-tested and shown to have worked.

What we check

These are the kinds of thing we look for. The list is the scope of the tooling, not a result.

• Open ports and services. Which doors are open on a server, and which service answers behind each one.
• Web vulnerabilities. Common weaknesses in how a website handles requests and input.
• TLS and security headers. Certificate and encryption settings, and the headers, such as a Content Security Policy, that tell a browser how to treat the site.
• Known vulnerabilities and dependencies. Software and libraries with published vulnerabilities, matched against public lists of known-exploited and likely-to-be-exploited issues.
• Secrets in code. Keys, passwords and tokens that were committed to a code repository by mistake.
• DNS and subdomain exposure. Which names point at our systems, including forgotten ones that should not be reachable.
• WordPress-specific checks. Plugins, themes and settings on the WordPress sites in the collection.

Built on

Nothing here is a secret weapon. The tooling is built on standard, widely used open-source tools and public vulnerability data. We wrote the glue, the evidence store and the guardrails around them.

The read-only fleet check

Separately from the scanners, a read-only fleet check goes through each of our 12 servers, one at a time. For each one it copies a small probe across, runs it under a controlled service unit and pulls the results back to our own machine.

It only reads. It never restarts a service, prunes anything or installs software. It looks at the hardening settings of the server and at the health of the monitoring that server reports to.

The AI assistant

We also use an AI pentest assistant that we run locally. It reads scan results and suggests fixes. It is advisory: it does not decide anything, and it does not act on its own.

It works from the results of scans of our own systems. Anything hands-on is limited to an isolated practice machine that is deliberately vulnerable. The assistant is never pointed at our servers or at anyone else's.

A person runs it and a person reviews what it says. Every finding starts out unverified until someone has confirmed it.

Guardrails

These limits are the point of the design.

• Authorised targets only. Our own systems, and nothing else.
• An explicit target allowlist. A target has to be on the list before a scan will run against it.
• Passive first. Scans start with what a system already shows to any visitor, and go further only when we have decided to.
• Rate limits and run timeouts. Every run is slowed and capped, so a check cannot hammer a system or run on without end.
• A permission step. The scanning console asks for an explicit confirmation before it launches a scan.
• Offensive tools stay in the lab. Metasploit and SQLMap are kept to an isolated practice machine. They are never pointed at the fleet, at our sites or at anyone else's systems.
• People in the loop. A person runs the tools and reviews what they report. Findings start unverified.
• Local, not a service. The tooling runs on our own machines. It is not a public service, and nobody outside can use it to scan anything.

What this does and does not mean

We make no claim of perfect security, for this site or for any other site in the collection. No scanner can prove such a thing, and a run that finds nothing means only that these tools found nothing that time.

What it does mean: we look for problems in our own systems with the tools above, we fix what we find, and we check again afterwards. Findings are verified by a person before we treat them as real.

This page publishes no findings, counts or scan output, and names no hosts, on purpose. If you have found a problem we missed, the security page says how to tell us.

The contact is on the security page and in the security.txt file.