Passive vs active checks: the difference

A passive check gathers what is already visible from outside, without sending probes to your service:

• discovery of subdomains and hosts from open sources (DNS, certificate logs, passive data)
• what stack is visible from the certificate and response headers
• a vulnerability feed for that stack (CVE, FSTEC BDU, GHSA/OSV, EUVD, CIRCL) prioritised by KEV / EPSS / exploit availability
• perimeter hygiene: domain expiry, SSL parameters, inventory and new subdomains

A passive result is usually `probable` — a match on version or signature, a signal to look, not proof. The exception is hygiene: an expired certificate or an expiring domain is observed directly and is `confirmed` right away.

Passive checks are safe by definition and available on the free Radar — they need no domain verification.

An active check sends safe requests to your perimeter to tell vulnerable behaviour from patched. This is what turns `probable` into `confirmed`.

What counts as safe: checking responses and headers, TLS parameters (via testssl and the like), behaviour that distinguishes a patch from its absence — with no destructive actions and no load.

What an active check does not do:

• does not pull or store the contents of your data — only the fact (port, response type, version)
• does not break the service or create load
• does not run public exploits against your production server

More on statuses and why a match ≠ a breach: how to tell if a CVE affects you.

Active checks run only after you have verified domain ownership (a TXT record in DNS). This is both legality and protection: we do not reach anything that is not yours.

Verification is not permanent: ownership is re-checked before active phases. If the record disappears, active checks stop and only passive remains.

So the order is: passive is visible right away and free, active checks come after domain verification on a paid plan.

The minimal-evidence principle: a finding stores the fact — a port number, a response type, the version seen — not the contents of your data. We do not pull or store target data.

Requests run with a size and time limit, no hops to internal addresses, from fixed egress IPs and within rate limits. That sets the approach apart from a noisy scanner that screams “critical” at any match, and from an “autonomous hacker”.

For hygiene and a typical stack (including Bitrix / 1C) these are ordinary safe checks; exploitation with load is not part of them.

Checks with real load and access (access logic such as IDOR, API, LLM — with test accounts) are deep analysis. It is not part of a normal active check and runs only under separate explicit consent.

Consent is a separate record: which domain and scope, for how long, who granted it and when. Without it, deep phases do not start, even if the domain is verified.

Briefly, without promising what isn’t there:

• Radar (free): passive only — discovery, a vulnerability feed for your stack (`probable`), hygiene (part of it `confirmed` right away)
• Contour: safe active checks, raising `probable → confirmed`, a retest after the fix
• Contour Business: everything in Contour + deep analysis (S4) under explicit consent

You can start with passive for free: add a domain to Radar. Active checks switch on after DNS verification on a paid plan.