Research methodology
Sentryx Outside-In Research Methodology
Sentryx research uses bounded, read-only observations of public internet signals and publishes only privacy-qualified aggregates with documented definitions, thresholds, time windows, and limitations.
What does Sentryx scan?
Sentryx observes public, unauthenticated signals associated with a submitted domain. Depending on availability and scope, this can include DNS records, certificate transparency names, resolving public hosts, HTTPS and TLS certificate evidence, baseline HTTP security headers, supported email-authentication records, and reachable service metadata.
What does Sentryx not scan?
The public workflow does not log in, exploit systems, crawl authenticated routes, fuzz application inputs, attempt credential attacks, access private networks, or claim complete vulnerability coverage. Results are outside-in observations, not a penetration test or security certification.
How are assets discovered?
Discovery begins with a submitted domain and expands through bounded public relationships such as DNS, certificate names, same-host public links, and resolving hosts. Candidate relationships are evidence of association and require owner validation before they are treated as confirmed organizational assets.
What qualifies as an observed host?
An observed host is a normalized public hostname supported by a recorded discovery source and timestamp. Shared infrastructure, wildcard DNS, historical certificates, and third-party services can create false associations, so the methodology distinguishes observed evidence from confirmed ownership.
How are TLS and security headers checked?
TLS checks use the public hostname and endpoint to observe certificate and HTTPS behavior. Header checks inspect response metadata for selected baseline policies. Presence alone is not treated as proof of security, and response bodies are not retained for research aggregation.
How are statistics aggregated?
Research statistics may be published only from aggregated, anonymized observations that meet a minimum cohort threshold. Identifiers, hostnames, IP addresses, customer names, report links, and row-level findings are excluded. Repeated observations are deduplicated according to the metric definition and reporting period.
What limitations exist?
Public scans can be affected by rate limits, geolocation, caching, CDN behavior, transient outages, shared hosting, wildcard records, and incomplete public sources. A result describes what was observed from a defined method and time window, not every possible client or internal state.
How are corrections handled?
Research pages should publish metric definitions, observation windows, sample thresholds, and revision dates. Material methodology or calculation corrections should be recorded openly rather than silently rewriting the interpretation of earlier figures.
What does a technical example look like?
Raw observation -> normalization -> deduplication -> eligibility rules -> minimum cohort threshold -> aggregate metric -> disclosure review -> publicationThe example uses reserved documentation domains and addresses. Apply the same reasoning to systems you own or are authorized to assess.
Authoritative technical references
How does continuous monitoring help?
A point-in-time check explains the observed state now. Continuous monitoring establishes an expected baseline, repeats the relevant check, and records meaningful state changes so an owner can investigate before a small configuration drift becomes a prolonged security or availability problem. See Research for the surrounding technical context.
Where does Sentryx Monitor fit?
Sentryx Monitor provides read-only outside-in discovery and monitoring for public hosts, DNS, HTTPS, TLS certificates, baseline security headers, email-security records, and selected network services. It supports evidence and operational follow-up, but it does not replace authorized penetration testing, authenticated vulnerability assessment, or owner validation.