How It Works
How free checks, self-service app workspaces, optional CLI access and expert reviews fit together.
Start with the task you need
- A public hostname check: Free check requires no account. Check only a hostname you own or are authorized to check; its result and download do not require signup.
- Saved workspace observations: Create a free account, verify your email, then create your own workspace. Joining someone else’s workspace requires an invitation. Creating an account or workspace does not authorize collection. The browser app needs no installation.
- Your first app result: follow Your first observation, then Understand results and reports. Owners and Contributors can authorize supported checks; Viewers inspect accessible data.
- Command-line access: use the optional CLI setup guide. Login and permission to collect are separate.
- Expert help: choose a review or service. Scope, price and authorization are agreed separately from an app account.
Paid app plans remain illustrative. Creating an account does not start a paid subscription. See FAQ for access and billing questions.
Understand what you received
External Exposure snapshots are unsigned. Reports are derived presentations. Local Audit Proofpacks have a separate signature and pinned-trust checking path. Public /verify accepts supported receipt JSON only. Compare these outputs before interpreting a verdict.
The technical reference below describes the legacy public_exposure_review profile for an authorized External Attack Surface Review. It is not the format of every app observation or report. The product workflow, evidence producer, receipt builder, trust policy, verifier, and web adapter remain separate components.
Expert-review evidence workflow
For that review profile, the documented order is:
- request
- scoped review
- evidence collection
- pre-signing bounded review/comparison result
- signed receipt
- verification page
The verification layer supports this review. App signup, workspace permissions and browser reports are separate product features.
The pre-signing result uses receipt outcomes pass, partial, fail, or inconclusive; blocked remains an operational state, not a receipt outcome. Review outcome and verifier verdict are separate domains, so a review pass can still project as indeterminate when independent checks are incomplete.
2. Component boundaries
| Component | Responsibility | Does not do |
|---|---|---|
| Public request and review workflow | Captures fit, authority, scope, approved checks, timing, limits, and review outcome | Does not establish cryptographic proof by itself |
| Bounded OffSec adapter | Exports eligible source records, stages evidence, and supplies real manifest artifact IDs and verification context | Does not contact targets, sign receipts, choose trust, or verify packages |
| Proof engine | Builds deterministic package files and signs receipts when an authorized signer is supplied | Does not independently verify its own output or define production key custody |
| Key registry and policy | Defines which signer could be accepted for production workflow use | Is currently draft and authorizes no production key for the legacy public_exposure_review profile |
| Internal verifier | Recomputes package, signature, evidence, workflow, and trust checks from explicit inputs | Is not currently a supported public distribution |
Public /verify adapter | Runs compatible receipt-only checks and presents valid, invalid, or indeterminate | Does not accept bundles or caller-supplied evidence and trust inputs |
3. Evidence and receipt construction
The OffSec adapter deterministically derives each offsec_<24 lowercase hex> artifact ID from the source run, normalized source path, and source SHA-256. The proof engine carries those identifiers into the evidence manifest and receipt claim references.
The legacy-named public_exposure_review receipt uses witnessops.receipt.v0 with witnessops.verification_context.v1. It preserves the exact method, subject, scope, timestamps, claims, limitations, outcome, manifest digest, and signature declaration.
Producer verification_result.json records build and comparison checks. It is not an independent verifier result.
4. Public verification
The web adapter validates the exact receipt profile and returns invalid for a profile conflict. A conforming receipt currently returns indeterminate because request and authority records, workflow execution, manifest and artifact bytes, evidence support, cryptographic signature, and production key authorization are not independently checked on the public surface.
An internal limited-pass also maps to public indeterminate.
5. Production acceptance boundary
Production validity requires a complete package, every required independent check, an active workflow acceptance policy, and an active pinned key-registry policy. Both current policies are draft; their trusted revision and hash pins are unset, and no production key is allowlisted.
Missing required evidence or trust is indeterminate. A failed profile, digest, signature, revoked-key, or active-policy check is invalid when that check is actually performed.
6. Non-claims
The verification architecture does not prove that a finding is correct, the system is secure, no vulnerability exists, the source environment was uncompromised, or the review covers anything outside its bounded contract.
7. Next-page handoff
Read Verification, Receipt Specification, and Evidence Bundles for the executable boundaries.