Trust and security

What this page is

A statement of controls that exist, in a product that is not yet operating commercially. Everything below is implemented. Nothing below is aspirational, and where something is planned rather than built, it says so.

Claims we do not make

We are not ISO 27001 certified. We are not SOC 2 audited. SiteGuardia holds no data protection certification at present.

That last sentence used to read that "GDPR certified" is not a thing that exists, which was wrong. Article 42 of the GDPR provides for certification mechanisms and for data protection seals and marks, and approved schemes exist under it. What is true is narrower and is what the sentence says now: we hold none of them. Correcting it here rather than quietly is the point of this page.

We have no customer logos, no user counts, no ratings and no testimonials, because the product has no customers yet. If you see any of those claims attached to SiteGuardia, they did not come from us.

Architecture

The control plane and the scan plane are separate.

The control plane holds the web app, the API, PostgreSQL and Redis. It never runs a scanning tool and never connects to a target.

The scan plane holds the workers. They accept no inbound connections, hold no database credentials, have no route to the data network, mount no Docker socket, run as a non-root user on a read-only filesystem with a memory-backed scratch directory, drop all Linux capabilities, run with no-new-privileges, and have CPU, memory and process limits.

Only ports 80 and 443 are published. PostgreSQL, Redis, the API and the workers publish nothing to the host.

Request safety

The visitor controls the target, which makes server-side request forgery the primary risk. The defence is layered:

• A strict target parser: HTTP and HTTPS only, no credentials in the URL, no IP literals, no ports, no special-use names, valid public suffix required.
• Every resolved address checked against a blocked-network policy sourced from the IANA special-purpose registries. One private answer refuses the whole name.
• Re-resolution immediately before connecting, with the validated address set pinned, so a name that changes between admission and connection is refused.
• Every redirect re-validated through the full path before it is followed.
• A host firewall that blocks the same destinations independently, so a parser bug does not become an exposure.

Which of these travel with the software

The controls above are two different kinds of thing and this page used not to say so.

Properties of the product. These are in the code, the schema and the container definitions, and they hold wherever SiteGuardia runs. The scan plane has no database credentials and no network route to the database. A finding classified as sensitive on an unverified target has no field in the schema that could carry its evidence, and the database refuses to store one that does. Reports are keyed-hash addressed. Every resolved address is checked against the blocked-network policy, and every redirect is re-validated. The renderer that produces a PDF runs a browser that cannot reach the network at all.

Properties of a deployment. These are configuration of the machine the service happens to run on, and a different deployment has to reproduce them deliberately. The host firewall that blocks the same destinations a second time. Memory-backed storage for scanner workspaces. Whatever encryption at rest the host provides. Log retention, backup handling and where those backups sit.

Today there is one deployment and it is a development machine. Nothing in the second list has been verified on a production host, because there is not one. When there is, this page says which host and what was checked.

Data handling

Raw scanner output lives in memory-backed storage and is deleted within minutes, including when a job crashes. Sanitized reports expire after 48 hours and are purged. Report tokens are 256 bits of CSPRNG output and are stored as keyed hashes, never in plain text. IP addresses are not stored for quota purposes; a rotating pseudonymous key is derived instead.

Sensitive findings

A finding classified as sensitive on an unverified target is reduced to metadata before persistence. The evidence is not hidden in the interface; it is never written. The database has a constraint that refuses to store a locked finding carrying evidence, and the API response model has no field that could carry one.

No AI in the free tier

Every explanation a visitor reads comes from a versioned editorial catalog. No model generates security findings, severities or advice. The same finding produces the same words every time, in both languages.

Two things there, and they are evidenced differently. Versioned is checkable: each entry carries a version, the published copy is generated from the source, and the build fails if the two disagree. Each entry also records a reviewer and a review date. That is a record that a review was logged, which is not the same as a guarantee that one happened, and this page used to say "human-reviewed" as though it were. It will say so again when there is a review process somebody outside the team can inspect.

We do not train any model on scan results.

Supply chain

Tool versions and container images are pinned by digest. The Nuclei template allowlist is explicit, versioned and individually reviewed; upstream publishing a new template does not add it. Dependency, container and secret scanning run in CI. Updates are staged and tested before production.

Our own disclosure policy

SiteGuardia publishes /.well-known/security.txt and accepts vulnerability reports. We respond, we do not threaten researchers who act in good faith, and we credit reporters who want to be credited.

Planned, not built

Domain ownership verification, which will release withheld findings to a verified owner, is planned. Accounts, history and monitoring are planned. None of them exist today, and this page will change when they do.