How the security rating is computed

The scale

A security rating is the result of applying a published rule set to evidence gathered by passive observation: the public DNS records of a domain, the registrar’s public record, one TLS handshake per protocol version with its web servers, one request for the landing page over HTTP and over HTTPS, and public data sources — Shodan’s InternetDB for open ports and known vulnerabilities, certificate-transparency logs, DNS blocklists.

Nothing is probed beyond the landing page, no port is scanned by us, and nothing is sent to the observed system that a browser or a mail server would not send. The rules below are the whole method: every point a score loses is listed here with its cost, and a change to the rules is a new version, dated, that never rewrites an earlier score.

• A domain starts at 950 and loses points for each failed check. The floor is 0.
• Every check has a tier — critical, high, medium, low or informational — with a fixed cost. Informational checks are shown and never cost anything.
• The overall score is computed on every failed check, with no cap per category. Category scores are shown for orientation and do not feed the overall score; a domain with many problems loses the full amount for each.
• An entity with several hosts or domains is pulled toward its worst asset: the score is the average, pulled halfway toward the minimum, so a bad host cannot hide behind good ones.
• A score always comes with its coverage: how many checks were evaluated, how many this version does not cover, and how many could not be observed. A score with twenty checks not observed is a weaker claim than one with two, and the page that shows it says so.

Statuses

Every check of every observation ends in one of these, and the coverage line under a score counts them.

Provisional checks are evaluated and shown with their tier but cost nothing, for at least one method version, so that a reader sees them before they move the number.

Why these costs

No rating vendor publishes per-check costs, and a regression over 396 public reports of one of them recovers only half the variance, so there was nothing to copy. These tiers are decided, not measured, and the reasoning for the most expensive ones is written down so that an auditor can argue with it. What the regression does support is the ordering: a missing DMARC record, no HTTPS, legacy TLS, untrusted certificates and end-of-life software sit at the top; single headers, cookie flags and open standard ports at the bottom.

Every other tier assignment follows the same two questions: what can an attacker do with it today, and does the regression over real domains agree with the ordering.

Not in this version

Dark-web and credential-leak monitoring, brand protection (typosquats, fake apps), questionnaires beyond the seven-item attestation below, operational risk as a category, cipher-suite enumeration beyond one weak-list handshake, per-vulnerability severity weighting. Each is listed as not covered where it would appear, and counted in the coverage of every score.

Where the observation comes from

Observation runs from our own worker, hosted in the European Union (Amsterdam), on a shared outbound address. For one domain it makes the DNS lookups listed above, one registrar lookup, at most six TLS handshakes per web host, two requests for the landing page, and the public-source queries — once a day at most, and never more than five hosts per domain.

What is observed is kept with the score as evidence: the record, the certificate dates, the header values. Response bodies are not kept.

Opting out

A domain owner who does not want their public posture observed by this product can ask for the domain to be excluded. Write to hello@tacans.com naming the domain. The request is honoured, and the domain is shown as “not observed at the owner’s request” to every customer who registered it.

The rules

Method version 1. Every domain starts at 950; each failed check subtracts its tier cost; the floor is 0.

domain_loss  = Σ domain-level costs + 0.5 × max(host_loss) + 0.5 × mean(host_loss)
domain_score = max(0, 950 − domain_loss)
entity_score = 0.5 × min(domain_score) + 0.5 × mean(domain_score)

Worst case per category, counting each mutually exclusive group once. Informational: the overall score has no per-category cap.

Attestation (version 1) and the blend

Observation measures what the public internet sees. An attestation records what a person at the customer has been shown about a supplier — certificates on file, clauses in the contract, a named contact, a recent test — answered item by item from the evidence, not from expectation, and recorded under that person’s name with the date.

An attested supplier carries a third number beside the two: the blend, half observation and half attestation, labelled as blended wherever it appears. Items answered as not applicable leave the denominator, so a supplier that never touches card data is not marked down for having no PCI attestation; an unanswered attestation is an absence, never a zero. The observation score and its history are untouched by any attestation.

attestation_score = 950 × Σ points(yes) / Σ points(applicable)   (null when nothing applicable is answered)
blended_score     = 0.5 × observation_score + 0.5 × attestation_score   (only when both exist)

Version history

A change to any rule is a new version. A score keeps the version it was computed with, and history is never rescored.