Read-only, external, unauthenticated

The three properties everything else follows from.

External. Every check runs against the target from outside, over the network, the way any other visitor reaches it. Nothing is installed on the target, no agent is enrolled, no code is deployed and no configuration is changed. There is no server-side component on your infrastructure that has to be trusted, maintained, or kept up to date.

Read-only. No state-changing method is ever sent to a target. Every request is a GET, a HEAD or an OPTIONS, and that allowlist is enforced in the fetch layer rather than by convention, so a new check cannot widen it. What the engine does send, inside those methods, is crafted probe values: GET query strings carrying injection, cross-site-scripting, path-traversal and request-forgery payloads, each written to be compared against a control request for the same URL and to change nothing. Nothing beyond the differential that one comparison measures is attempted. It does not authenticate, does not guess credentials, and reaches nothing behind a login. Where a check would need a state-changing request to prove something, the check reports that it could not be tested rather than performing it.

Unauthenticated. No credentials of any kind are supplied to the engine or used by it. A session cookie is never stored, never replayed and never asked for. This is the reason the assessment sees what an unauthenticated attacker would see, and also the reason it cannot see anything behind your login.

Assessment traffic is ordinary HTTP and DNS, plus two other kinds worth naming. Transport checks open a raw TLS handshake to read the certificate and the protocols on offer, which is not an HTTP request at all. Certificate transparency checks query third-party log aggregators — crt.sh and api.certspotter.com — for certificates naming your domain, so part of an assessment is HTTPS traffic to somebody else's API about you, not to you. Everything aimed at you is rate-limited and held within the per-host request budget described below, so it behaves like normal visitor traffic. It will still appear in your web server's logs, and it may trip rate-limiting, firewall or intrusion-detection rules on the way in.

Read-only is not invisible

An assessment does make requests to the target. Your logs will show them.
Your provider, host or WAF may alert on the pattern. Warn them before you scan.
A scan is not exempt from your target's acceptable-use rules. The Terms of Service make authorisation your responsibility as a matter of contract.

Permitted request methods

The methods the target-facing request layer is allowed to use.

Every outbound request this HTTP layer will make to a target is one of GET, HEAD, OPTIONS. The allowlist is enforced in the fetch layer itself, not at the call sites, so a new check module cannot widen it without changing that one list and failing a test that pins it.

This is what makes "read-only" a property of the implementation rather than a promise in the documentation. A module that needed POST, PUT, PATCH or DELETE cannot express that request: it is refused before a socket is opened.

Two constraints on the shape of those requests are worth stating separately from the method, because they are enforced in different places. This list governs the target-facing HTTP layer only. The certificate transparency check described above uses its own client to reach a third-party log API, and the transport check opens a TLS socket rather than an HTTP one; neither is a request to your site, and neither could change anything there if it were.

Two further constraints apply to every request to a target:

Scheme and port. Only http and https, on ports 80 and 443. An assessment does not connect to a database port, a management interface or an arbitrary service.
Response size and time. Each response is read under a byte cap and a wall-clock deadline, so a hostile or simply enormous target cannot hold a request open.

Redirects are followed, up to a small hop limit, and every hop is re-validated rather than trusted: a redirect is a fresh request and is treated as one.

The ownership verification model

Verifying control of a domain takes one of two forms, and either is enough. The authoritative one is a DNS TXT record in that domain's own zone: we issue a random token, you publish it, we read it back. The check walks the zone from your domain up to the registrable domain only, reads the domain's own published nameservers, and never follows a delegation outside the namespace.

The second is a file served over HTTP at /.well-known/soryvex-verification.txt, containing the same token. That request goes through the same guarded client as an assessment request, except that redirects are not followed: a 3xx is a failure rather than a step, because a site that redirects unknown well-known paths would otherwise hand the token to whoever registered one. The DNS record is the stronger of the two — it is authoritative and has no equivalent weakness — and it is the one to use where you can publish it.

A verification record is valid for 30 days and then has to be renewed. That is deliberate: a record left in a zone forever becomes a permanent, published statement that the domain is monitored, and rotating it keeps the statement true.

Verification is required for the full check surface and not required for a basic assessment. A basic assessment runs on any public web address straight away, which is what makes it usable for vetting a third party before any relationship exists. Every report states which of the two levels it ran at, so a basic one is never read as a complete one.

Verification is an authorisation signal, not a secret

The token is published, so it is public either way. It proves you control the domain; it does not authenticate you to the site.
It is required before anything on the target is touched beyond plain observation.
The Terms of Service make it your responsibility to only assess domains you own or are authorised to assess, whether or not verification is required for a given check.

Public addresses only

Before a connection is made, the hostname is resolved and every address it returns is classified. If any answer is a private, loopback, link-local, carrier-grade NAT, documentation, benchmarking, multicast, reserved or unique-local address, the whole host is refused. A hostname that resolves to one public and one private address is treated as private.

Two further controls matter, and both exist because DNS answers are not a promise:

The address is pinned. The request goes to the address that was just validated, not to a second resolution, so there is no window in which the answer can change between the check and the connection.
The peer is re-checked. The address the socket actually connected to is validated again afterwards, and the check fails closed if it cannot be established.

Literals typed as input are classified before any lookup happens, and IPv4-mapped IPv6 forms are normalised to their IPv4 value first — a documented bypass in a class of bug where ::ffff:127.0.0.1 reads as a public address to naive comparison.

Scan depth, and what "bounded" means

An assessment is bounded on every axis that could otherwise make it expensive for you or for the target. These are the current values, read from the running configuration:

Per-assessment bounds on requests, duration, crawl and per-host request rate
Bound	Value	What it means
Requests per host	195 basic	The cap on an unverified, basic assessment. This is the ceiling that applies to a first run.
Requests per host	5000 verified	The budget once ownership is verified. A redirect chain can consume several of these for one logical fetch.
Wall-clock duration	4 hours	Checked between stages, and the same at either depth. When the deadline is reached the run stops early, and the report then says so and names the check modules that never ran.
Crawl depth	2 levels verified	How far the crawler follows links from the pages it fetched. The crawler is one of the checks that needs ownership proof, so this bound applies from the second level of the check surface upwards.
Crawled pages	150 verified	The ceiling on pages fetched while mapping the application surface.
Time budget per request	15 s	Applied to the HTTP client, with a shorter allowance for connecting.

A deep assessment runs the same checks as a standard one with a wider budget. It is the same set of probes, asked more of them and with more room to follow what it finds — never a different method, and never past the authorisation boundary. The multipliers are settings, so they are printed from the running configuration rather than described:

How a deep assessment's budget compares with a standard one
Bound	Deep, against standard	What it means
Requests per host	× 2.5	The verified request budget above is multiplied by this. The per-host request rate is deliberately unchanged, so a deep assessment takes proportionally longer rather than hitting a target harder.
Probes per check module	× 2.5	Scales the dynamic per-module probe caps: how many probed parameters, endpoints or candidates each module may work through.
Crawl depth	+ 1 level	Added to the crawl depth above.
Crawled pages	× 2.0	Scales the page ceiling above, and with it the ceilings on scripts, sitemap entries and parameters per endpoint.

A deep assessment on an unverified domain is not refused and does not run at deep depth. It runs at standard depth, and the report says so in a notice at the top of the report, above the executive summary: that a deep assessment was requested, that deeper probing needs verified ownership, and that this run therefore ran at the standard depth. The report names the depth it actually ran at rather than the one that was asked for, because the two produce different amounts of evidence.

When the crawl budget runs out, the report states which parts of the surface were not reached. An assessment that stopped early says so; it does not present a partial map as a complete one.

What is outside the method

These require a different kind of engagement

Authenticated testing. Anything behind a login, a member area or an admin panel is not assessed. The engine has no credentials and does not ask for any.
Source code review. Logic flaws, unsafe data handling and injection sinks in your own code are invisible from outside, whatever they are worth.
Dependency and patch management. Whether a known vulnerability affects the version of a library you ship is a question about your build, not about your public surface.
Internal network and cloud posture. The assessment stops at public addresses. What is reachable from inside is not in view.
Social engineering, phishing and physical testing. Not attempted, and not something an automated service should be doing.
Availability. Nothing here tests whether a site can be made to fall over, and the rate limits are chosen so that this assessment cannot be the thing that does it.

The consequence worth stating plainly: a clean report means nothing was found from outside. It does not mean the site is secure, and it is not evidence of compliance with anything. Soryvex does not certify websites and does not produce a compliance audit.

False positives, false negatives, and how findings are graded

Automated external assessment produces noise. A scanner that reported every possible issue as an equal-severity alarm would be unusable and, worse, would train people to ignore it. So each finding carries two independent ratings and a grade, and all three are shown:

Severity: What the condition would mean if it were exploited. It starts as the rating in the catalogue entry for that check, and a model cannot raise it — but it is not the catalogue value that reaches you either. Deterministic post-processing adjusts it in both directions: rules keyed to the check id demote a finding whose evidence does not support the class the catalogue assumed, a content-exposure finding whose evidence was never validated is downgraded to a potential issue (or, where it was already low, to an observation), and a quality gate caps a potential issue at Medium while dropping anything needing review, and anything that could not be verified, to info. So a severity is Soryvex's own rating of a specific observation, not a fixed property of the check and not a model's guess about your site.
Confidence: How sure the engine is that the condition is really there. It scales a finding's contribution to the score. It is not what decides which section of the report a finding lands in — that is decided by the grade below.

Every finding carries a grade as well, and the grade is what the report is organised by. Each one below is a section a report can contain:

Confirmed — the condition was observed directly and the evidence is attached to the finding.
Likely — the evidence points one way but is not conclusive. A prompt to look, not a demonstrated defect.
Findings needing review — a real signal whose evidence is not yet strong enough to classify either way.
Potential issue — a pattern consistent with a weakness that this method cannot resolve from outside, frequently something an authenticated test would settle.
Security observations — worth knowing, not a defect: a technology disclosed in a header, a certificate transparency entry, a third-party service named in a TXT record.
False positives — recorded rather than deleted, with the reason, so a reader can see what was rejected and why.
Verified controls — checks that positively confirmed something is configured correctly.
Not verifiable — a check that could not be decided from outside. It is reported as undetermined and never as a pass.

What "confirmed" does and does not mean

It means observed, with the record. The engine reached the condition itself and the evidence is attached to the finding, so you can check it rather than take it on trust.
It does not mean exploited. No check attempts to exploit what it found. A confirmed finding is evidence that a condition is present, not a demonstration that an attacker has used it, and not a breach.
It does not mean someone else could not. A condition confirmed from outside says nothing about what is reachable from inside, behind a login, or through a business process.
It is Soryvex's rating. The severity is our judgement of the class of issue, on our evidence, on one day.

The score is computed from this, and deliberately so: a confirmed finding carries the score's starting anchor and adds its own amount, a likely one is discounted and can only raise a number an anchor has already set, and a potential issue, an observation or anything needing review contributes nothing. A report that listed five findings and scored as though it had three is telling you something about how much weight each carries. The report states the band the score falls in, what that band means, and how many findings it was computed from; the full formula, with every constant in it, is published on the product page so the arithmetic itself can be redone.

False negatives are the other half of it. Everything in "what is outside the method" above is also a class of thing this assessment will not find, and a site with no findings has not been shown to have none. Severity and confidence are estimates and are labelled as such.

Repeatability

Because the method is bounded and stated, a re-run is comparable to the last one. That is the property that turns a scan into evidence: fix something, assess again, and the difference between the two reports is a fact about what changed rather than an opinion.

A report is a snapshot. The target's state moves on after the run, so a green report describes the site at the moment it was taken.

How a Soryvex assessment works