Security checks with a grade and a fix.

What you check

The things you check are your domains, and web apps at an https:// address. An organisation can add up to 200. Each one gets a card on the Toolbox's overview with its grade.

A thing's page groups its checks by category: E-mail, Website, DNS, Domain & certificate and Web application. Its problems can be shown three ways: Bucket view (grouped by where you fix them), Cards or List.

The checks

Each check answers one plain question about a domain or a web app. These are published today, by category:

More checks appear as the platform publishes them. A check is versioned, and a run stays on the version it started with.

Running a test

• Start new test: add your domain or web app, choose what to check, and run them together as one batch.
• Check everything: run every published check that fits the thing.
• Or run one check on its own.
• Re-checks repeat a test every week, or every 1 to 90 days.
• When a batch ends, you get one e-mail for it: "Your test of N checks on <name> has finished."

The score and the grade

The arithmetic is simple and stated, so you can check it:

• A check's score is 100, minus 25 for each fail, minus 8 for each finding that needs attention.
• A category's score is the mean of its checks', and the thing's score is the mean of its categories', rounded half up.
• The grade: A from 90, B from 75, C from 60, D from 40, and F below.

The report

Every check answers in one standard shape:

• a verdict;
• findings, each with How to fix;
• the key facts it read;
• a comparison with the last run on the same target.

There is a PDF for a single run, and one for a whole domain or app with its grade over time.

The fix, written by AI

When a batch ends, BasePit's AI is asked once for the whole batch. Each problem gets a fix written with the thing's other checks in view, so it can name the right place. For example: a DNSSEC fix that knows from the expiry check who your registrar is.

• Each fix says where in your provider's own console to make it, and one action.
• Every fix is labelled AI-written. A fix that carries a destructive command is dropped.
• The batch's e-mail waits for the fixes, for at most 4 minutes.
• An organisation whose AI is off, or that uses its own AI key, gets the findings and their How to fix, without the AI-written fix.

Proving a domain

A check that reads only what any visitor could read is passive, and runs on any public target. A check that probes more is active, and runs only on a domain your organisation has proved it owns.

• Prove a domain with a DNS TXT record at _basepit-verify.<domain>, or a file at /.well-known/basepit-verify.txt.
• A proof covers the domain's subdomains, and is checked again every 30 days.
• Only an Admin can prove a domain.

How a check runs

Each step of a check is one container:

• an unprivileged user, a read-only root file system and every capability dropped;
• its image pinned by digest;
• a time limit for each step.

Steps run on BasePit's workers, or on one of your own Linux hosts installed with --allow-tasks. On a worker they run in rootless Podman, behind a network fence that drops private, loopback, link-local, carrier-grade NAT, multicast and cloud-metadata addresses after DNS. A worker checks its fence before every task and refuses the task without it. The images are fetched ahead, so a run starts in about a second.

A whole run lasts at most 30 minutes. A step that waits 10 minutes for a free slot fails its run, and the run is refunded.

Limits

• A run uses credits, free ones first. Its price is shown on the button before you run it, and it is refunded if it ends without a report. A check the platform marks for paying organisations is shown with that note until you have bought credits. Pricing.
• Active checks need a proven domain. Passive checks read only what any visitor could.
• Web apps must be at an https:// address.
• AI-written fixes are suggestions, labelled as such. Read them before you act on them.