PUBLIC DOMAIN DOSSIER

dimaready.com

What is observed, how to verify it and what changed

4 public observations are documented in this dossier.

1 structuring public dependencies are visible.

No useful change is retained since the previous reading.

2 points still require confirmation or cannot be observed from outside.

Measured 2026-09-04 19:57 UTC First observation 2026-09-04 19:46 UTC Latest observation 2026-09-05 17:21 UTC

History Compare JSON Markdown

TIME

What changed over time

Compared with the previous stored reading

0Appeared

0Modified

39Stable

0Disappeared

SHORT VIEW

Four readings before the detail

The 12 historical angles remain available below for deeper inspection.

Identity & governance

ObservedDepends on providerCloudflare
Not observable from outsideOrigin host
Not testedCanary detection

Infrastructure & transport

ObservedTls issuerC = US, O = Google Trust Services, CN = WE1
Not testedPost quantum tls

Mail & trust

ObservedDmarc policyreject
ObservedSpf policyhardfail

Dependencies & exposure

Not observable from outsideData location

Explanatory record

What Scanapse understands about this domain

Scanapse has enough material to describe 11 of 12 knowledge angles for dimaready.com. 4 questions remain open with the available public evidence.

Measured on 2026-09-04 19:57 UTC Engine 2.6.0.1

Read the domain folder

The key points for reading this domain folder

Four key points to understand what Scanapse observed, what can reasonably be retained, and what still needs verification.

Key points

Worth looking at today

Only a few items are shown when they add something genuinely useful to the reading.

DEPENDENCIES

Critical function concentration

Cloudflare is associated with 3 critical function(s) or observations in the visible scope.

This concentration is descriptive. It does not prove a future outage or the absence of failover mechanisms invisible to the scan.

Territorial and legal context

Which legal context can reasonably be retained

Scanapse distinguishes established, probable and to-confirm jurisdiction and always explains which clues support the reading.

To confirm To confirm

Why this context appears

No sufficiently reliable public jurisdiction clue was found in the report

What this does not establish

Technical hosting, IP addresses, ASNs and CDN locations do not establish the applicable legal jurisdiction by themselves.
The applicable jurisdiction requires additional public or organisational evidence.

Regulatory frameworks

Useful texts for this context

References are selected from the observed context. Their presence explains potential relevance, never automatic compliance.

To confirmTo determine

Regulatory context to determine

The available public evidence does not establish a sufficiently reliable jurisdiction for automatic legal contextualisation.

This section provides documentary context. It is not legal advice, certification or a compliance verdict.

Trajectory

Useful changes since the previous reading

Only differences that help interpretation are highlighted. Stable or purely technical variations remain available in the evidence.

No significant change retained

The available comparison does not surface a change worth highlighting in the public reading.

12 knowledge angles

12 angles to understand the domain

Each angle explains what is known, why it matters, how to read it, its purpose and its limits.

Documented Change observed

Domain identity

Public evidence provides enough material to document this angle

Documented Change observed

Infrastructure

Public evidence provides enough material to document this angle

Partial Change observed

Encryption and transport

This angle is only partially documented by public evidence

Documented Change observed

Mail and trust

Public evidence provides enough material to document this angle

Documented Change observed

DNS and governance

Public evidence provides enough material to document this angle

Documented Change observed

External dependencies

Public evidence provides enough material to document this angle

Documented Stable

Observable technologies

Public evidence provides enough material to document this angle

Partial Change observed

Public exposure

This angle is only partially documented by public evidence

Documented Change observed

Documentary trust

Public evidence provides enough material to document this angle

Documented Change observed

Security signals

Public evidence provides enough material to document this angle

To determine First observation

Evolution over time

This angle still needs additional public evidence

Documented Stable

Evidence and traceability

Public evidence provides enough material to document this angle

Overview

What the domain already shows, and what still needs clarification

An overview of visible relationships and uncertainty areas that still need verification.

Visible relations

Visible relations around the domain

Relations are grouped by function. They describe what is publicly visible, not contracts or the full internal architecture.

Observed domain dimaready.com

DNS

DNS server Observed

thea.ns.cloudflare.com

DNS server Observed

david.ns.cloudflare.com

external resources

External provider or resource Corroborated

Cloudflare

Open questions

4 areas to confirm

An unknown becomes useful information when it precisely explains what is missing to reach a conclusion.

To confirm

Origin hosting

An edge service does not reveal the origin hosting provider.

To confirm

Effective data location

Public provider metadata does not prove where data is actually processed.

To confirm

Post-quantum TLS exchange

This check was not run with a compatible client during this measurement.

To confirm

Public canary signal

Detection of this signal was not enabled for this measurement.

These items do not mean there is a problem. They simply show that useful information is still missing.

Sources and evidence

Evidence supporting this reading

38 evidence items are available. They remain collapsed to preserve a short reading and can be explored on demand.

38evidence items available

Each proof keeps its method, provenance, date, reliability and interpretation limits.

Download evidence JSON

Explore evidence

#01 Mail-related public records

Evidence: mail_policy_flag

Public mail policies show how the domain frames sending, authentication and email transport.

Active non-intrusive High

Why it matters

These mechanisms can reduce domain spoofing and document mail-transport posture.

What to check next

Relate SPF, DKIM when a selector is known, DMARC, MX, MTA-STS and TLS-RPT. Compare policy changes over time.

Possible action

Before strengthening a policy, inventory legitimate mail flows and verify alignment. Roll out changes progressively to avoid blocking authorized senders.

Observation
Understand: Public DNS and policy endpoint inspection
Source: Mail-related public records
Reliability: High
What this supports: Describe published mail authentication and transport policies
What this does not prove: They do not prove actual deliverability, every recipient’s behavior, or the absence of phishing.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Sender Policy Framework RFC 7208
Domain-based Message Authentication, Reporting, and Conformance RFC 7489
SMTP TLS Reporting RFC 8460
SMTP MTA Strict Transport Security RFC 8461

View raw data

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#02 DNS public records

Evidence: dns_address

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: 104.21.13.20
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

dig A dimaready.com && dig AAAA dimaready.com

View raw data

104.21.13.20

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#03 Public HTTP response

Evidence: module_finding

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: { "evidence": null, "severity": "medium" }
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

{
    "evidence": null,
    "severity": "medium"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#04 Public TLS endpoint

Evidence: tls_issuer

TLS protects the observed connection between the scanner and the public service.

Active non-intrusive High

Why it matters

These elements document public-channel protection and the cryptographic mechanisms actually negotiated.

What to check next

Compare negotiated protocol, issuer, expiry, chain and cryptographic parameters with history. Check other public entry points separately.

Possible action

Address only observed gaps such as an expiring certificate, invalid chain, or unwanted protocol. Test changes in a controlled environment before deployment.

Observation: C = US, O = Google Trust Services, CN = WE1
Understand: TLS handshake and public certificate inspection
Source: Public TLS endpoint
Reliability: High
What this supports: Describe the TLS session and certificate presented to Scanapse
What this does not prove: Strong TLS does not prove application security or origin-server security behind a CDN or reverse proxy.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

TLS 1.3 RFC 8446
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

openssl s_client -connect dimaready.com:443 -servername dimaready.com </dev/null

View raw data

C = US, O = Google Trust Services, CN = WE1

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#05 Public HTTP response

Evidence: module_finding

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: { "evidence": null, "severity": "low" }
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

{
    "evidence": null,
    "severity": "low"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#06 Public transparency endpoint

Evidence: module_finding

Public artefacts such as security.txt make some technical processes verifiable.

Passive Medium

Why it matters

A documented reporting channel supports responsible coordination when an issue is found.

What to check next

Check expiry, contact, Canonical, Policy, Encryption and any signature. Compare the file with previous scans.

Possible action

Publish a compliant security.txt only when a real handling channel exists, keep it current, and align contacts with the internal reporting process.

Observation: { "evidence": null, "severity": "medium" }
Understand: Public transparency artefact inspection
Source: Public transparency endpoint
Reliability: Medium
What this supports: Describe published disclosure mechanisms
What this does not prove: A file being present does not prove response speed or overall organizational maturity.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

A File Format to Aid in Security Vulnerability Disclosure RFC 9116

View raw data

{
    "evidence": null,
    "severity": "medium"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#07 DNS public records

Evidence: dmarc_record

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: v=DMARC1; p=reject;
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

v=DMARC1; p=reject;

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#08 Mail-related public records

Evidence: mail_policy_flag

Public mail policies show how the domain frames sending, authentication and email transport.

Active non-intrusive High

Why it matters

These mechanisms can reduce domain spoofing and document mail-transport posture.

What to check next

Relate SPF, DKIM when a selector is known, DMARC, MX, MTA-STS and TLS-RPT. Compare policy changes over time.

Possible action

Before strengthening a policy, inventory legitimate mail flows and verify alignment. Roll out changes progressively to avoid blocking authorized senders.

Observation
Understand: Public DNS and policy endpoint inspection
Source: Mail-related public records
Reliability: High
What this supports: Describe published mail authentication and transport policies
What this does not prove: They do not prove actual deliverability, every recipient’s behavior, or the absence of phishing.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Sender Policy Framework RFC 7208
Domain-based Message Authentication, Reporting, and Conformance RFC 7489
SMTP TLS Reporting RFC 8460
SMTP MTA Strict Transport Security RFC 8461

View raw data

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#09 Public TLS endpoint

Evidence: tls_valid_to

TLS protects the observed connection between the scanner and the public service.

Active non-intrusive High

Why it matters

These elements document public-channel protection and the cryptographic mechanisms actually negotiated.

What to check next

Compare negotiated protocol, issuer, expiry, chain and cryptographic parameters with history. Check other public entry points separately.

Possible action

Address only observed gaps such as an expiring certificate, invalid chain, or unwanted protocol. Test changes in a controlled environment before deployment.

Observation: 2026-11-27T20:04:00+00:00
Understand: TLS handshake and public certificate inspection
Source: Public TLS endpoint
Reliability: High
What this supports: Describe the TLS session and certificate presented to Scanapse
What this does not prove: Strong TLS does not prove application security or origin-server security behind a CDN or reverse proxy.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

TLS 1.3 RFC 8446
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

2026-11-27T20:04:00+00:00

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#10 Public HTTP response

Evidence: module_finding

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: { "evidence": null, "severity": "critical" }
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

{
    "evidence": null,
    "severity": "critical"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#11 DNS public records

Evidence: module_finding

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: { "evidence": null, "severity": "low" }
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

{
    "evidence": null,
    "severity": "low"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#12 DNS public records

Evidence: dns_address

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: 172.67.132.117
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

dig A dimaready.com && dig AAAA dimaready.com

View raw data

172.67.132.117

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#13 DNS public records

Evidence: module_finding

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: { "evidence": { "reason": "No external validating resolver is used; DS validation is intentionally not inferred.", "status": "not_tested" }, "severity": "info" }
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

{
    "evidence": {
        "reason": "No external validating resolver is used; DS validation is intentionally not inferred.",
        "status": "not_tested"
    },
    "severity": "info"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#14 module_finding

Evidence: module_finding

Scanapse shows visible providers and third-party services on which the public service depends.

Active non-intrusive Medium

Why it matters

Concentration on one actor or many third parties can affect continuity and governance.

What to check next

Identify each provider role, functions concentrated on the same actor, and dependencies that appeared or disappeared since the previous scan.

Possible action

For a critical dependency, document owner, contract, reversibility, failover and rationale. Diversify only after analysing the actual need.

Observation: { "evidence": 404, "severity": "high" }
Understand: Public observation
Source: module_finding
Reliability: Medium
What this supports: Describe the observed public artefact
What this does not prove: A visible dependency does not prove data location, actual contractual jurisdiction, or hidden subcontractors.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - supply-chain risk context Context only, scope must be established separately
Regulation (EU) 2022/2554 - DORA ICT third-party risk context for entities in scope

View raw data

{
    "evidence": 404,
    "severity": "high"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#15 Mail-related public records

Evidence: dmarc_policy

Public mail policies show how the domain frames sending, authentication and email transport.

Active non-intrusive High

Why it matters

These mechanisms can reduce domain spoofing and document mail-transport posture.

What to check next

Relate SPF, DKIM when a selector is known, DMARC, MX, MTA-STS and TLS-RPT. Compare policy changes over time.

Possible action

Before strengthening a policy, inventory legitimate mail flows and verify alignment. Roll out changes progressively to avoid blocking authorized senders.

Observation: reject
Understand: Public DNS and policy endpoint inspection
Source: Mail-related public records
Reliability: High
What this supports: Describe published mail authentication and transport policies
What this does not prove: They do not prove actual deliverability, every recipient’s behavior, or the absence of phishing.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Sender Policy Framework RFC 7208
Domain-based Message Authentication, Reporting, and Conformance RFC 7489
SMTP TLS Reporting RFC 8460
SMTP MTA Strict Transport Security RFC 8461

Verify it yourself

This command reproduces the public observation without changing the target.

dig TXT _dmarc.dimaready.com

View raw data

reject

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#16 Mail-related public records

Evidence: module_finding

Public mail policies show how the domain frames sending, authentication and email transport.

Active non-intrusive High

Why it matters

These mechanisms can reduce domain spoofing and document mail-transport posture.

What to check next

Relate SPF, DKIM when a selector is known, DMARC, MX, MTA-STS and TLS-RPT. Compare policy changes over time.

Possible action

Before strengthening a policy, inventory legitimate mail flows and verify alignment. Roll out changes progressively to avoid blocking authorized senders.

Observation: { "evidence": null, "severity": "info" }
Understand: Public DNS and policy endpoint inspection
Source: Mail-related public records
Reliability: High
What this supports: Describe published mail authentication and transport policies
What this does not prove: They do not prove actual deliverability, every recipient’s behavior, or the absence of phishing.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Sender Policy Framework RFC 7208
Domain-based Message Authentication, Reporting, and Conformance RFC 7489
SMTP TLS Reporting RFC 8460
SMTP MTA Strict Transport Security RFC 8461

View raw data

{
    "evidence": null,
    "severity": "info"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#17 Public HTTP response

Evidence: module_finding

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: { "evidence": null, "severity": "low" }
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

{
    "evidence": null,
    "severity": "low"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#18 Public HTTP response

Evidence: module_finding

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: { "evidence": null, "severity": "info" }
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

{
    "evidence": null,
    "severity": "info"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#19 module_finding

Evidence: module_finding

Scanapse shows visible providers and third-party services on which the public service depends.

Passive Medium

Why it matters

Concentration on one actor or many third parties can affect continuity and governance.

What to check next

Identify each provider role, functions concentrated on the same actor, and dependencies that appeared or disappeared since the previous scan.

Possible action

For a critical dependency, document owner, contract, reversibility, failover and rationale. Diversify only after analysing the actual need.

Observation: { "evidence": [ "Cloudflare" ], "severity": "high" }
Understand: Public observation
Source: module_finding
Reliability: Medium
What this supports: Describe the observed public artefact
What this does not prove: A visible dependency does not prove data location, actual contractual jurisdiction, or hidden subcontractors.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - supply-chain risk context Context only, scope must be established separately
Regulation (EU) 2022/2554 - DORA ICT third-party risk context for entities in scope

View raw data

{
    "evidence": [
        "Cloudflare"
    ],
    "severity": "high"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#20 Public transparency endpoint

Evidence: module_finding

Public artefacts such as security.txt make some technical processes verifiable.

Passive Medium

Why it matters

A documented reporting channel supports responsible coordination when an issue is found.

What to check next

Check expiry, contact, Canonical, Policy, Encryption and any signature. Compare the file with previous scans.

Possible action

Publish a compliant security.txt only when a real handling channel exists, keep it current, and align contacts with the internal reporting process.

Observation: { "evidence": null, "severity": "low" }
Understand: Public transparency artefact inspection
Source: Public transparency endpoint
Reliability: Medium
What this supports: Describe published disclosure mechanisms
What this does not prove: A file being present does not prove response speed or overall organizational maturity.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

A File Format to Aid in Security Vulnerability Disclosure RFC 9116

View raw data

{
    "evidence": null,
    "severity": "low"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#21 Public transparency endpoint

Evidence: module_finding

Public artefacts such as security.txt make some technical processes verifiable.

Passive Medium

Why it matters

A documented reporting channel supports responsible coordination when an issue is found.

What to check next

Check expiry, contact, Canonical, Policy, Encryption and any signature. Compare the file with previous scans.

Possible action

Publish a compliant security.txt only when a real handling channel exists, keep it current, and align contacts with the internal reporting process.

Observation: { "evidence": null, "severity": "low" }
Understand: Public transparency artefact inspection
Source: Public transparency endpoint
Reliability: Medium
What this supports: Describe published disclosure mechanisms
What this does not prove: A file being present does not prove response speed or overall organizational maturity.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

A File Format to Aid in Security Vulnerability Disclosure RFC 9116

View raw data

{
    "evidence": null,
    "severity": "low"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#22 Public HTTP response

Evidence: module_finding

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: { "evidence": null, "severity": "high" }
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

{
    "evidence": null,
    "severity": "high"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#23 DNS public records

Evidence: module_finding

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: { "evidence": [ "david.ns.cloudflare.com", "thea.ns.cloudflare.com" ], "severity": "low" }
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

{
    "evidence": [
        "david.ns.cloudflare.com",
        "thea.ns.cloudflare.com"
    ],
    "severity": "low"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#24 Public HTTP response

Evidence: module_finding

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: { "evidence": null, "severity": "high" }
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

{
    "evidence": null,
    "severity": "high"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#25 Public HTTP response

Evidence: http_header

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: [ "nosniff" ]
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

[
    "nosniff"
]

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#26 DNS public records

Evidence: dns_nameserver

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: thea.ns.cloudflare.com
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

dig NS dimaready.com

View raw data

thea.ns.cloudflare.com

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#27 DNS public records

Evidence: dns_nameserver

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: david.ns.cloudflare.com
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

dig NS dimaready.com

View raw data

david.ns.cloudflare.com

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#28 Mail-related public records

Evidence: spf_policy

Public mail policies show how the domain frames sending, authentication and email transport.

Active non-intrusive High

Why it matters

These mechanisms can reduce domain spoofing and document mail-transport posture.

What to check next

Relate SPF, DKIM when a selector is known, DMARC, MX, MTA-STS and TLS-RPT. Compare policy changes over time.

Possible action

Before strengthening a policy, inventory legitimate mail flows and verify alignment. Roll out changes progressively to avoid blocking authorized senders.

Observation: hardfail
Understand: Public DNS and policy endpoint inspection
Source: Mail-related public records
Reliability: High
What this supports: Describe published mail authentication and transport policies
What this does not prove: They do not prove actual deliverability, every recipient’s behavior, or the absence of phishing.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Sender Policy Framework RFC 7208
Domain-based Message Authentication, Reporting, and Conformance RFC 7489
SMTP TLS Reporting RFC 8460
SMTP MTA Strict Transport Security RFC 8461

Verify it yourself

This command reproduces the public observation without changing the target.

dig TXT dimaready.com

View raw data

hardfail

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#29 DNS public records

Evidence: dns_address

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: 2606:4700:3033::6815:d14
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

dig A dimaready.com && dig AAAA dimaready.com

View raw data

2606:4700:3033::6815:d14

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#30 module_finding

Evidence: module_finding

Scanapse shows visible providers and third-party services on which the public service depends.

Passive Medium

Why it matters

Concentration on one actor or many third parties can affect continuity and governance.

What to check next

Identify each provider role, functions concentrated on the same actor, and dependencies that appeared or disappeared since the previous scan.

Possible action

For a critical dependency, document owner, contract, reversibility, failover and rationale. Diversify only after analysing the actual need.

Observation: { "evidence": [ "david.ns.cloudflare.com", "thea.ns.cloudflare.com" ], "severity": "medium" }
Understand: Public observation
Source: module_finding
Reliability: Medium
What this supports: Describe the observed public artefact
What this does not prove: A visible dependency does not prove data location, actual contractual jurisdiction, or hidden subcontractors.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - supply-chain risk context Context only, scope must be established separately
Regulation (EU) 2022/2554 - DORA ICT third-party risk context for entities in scope

View raw data

{
    "evidence": [
        "david.ns.cloudflare.com",
        "thea.ns.cloudflare.com"
    ],
    "severity": "medium"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#31 Observed public page

Evidence: module_finding

Third-party resources loaded by a page create visible execution dependencies.

Active non-intrusive Medium

Why it matters

An external resource executed in the browser extends the site’s trust chain.

What to check next

Identify executed third-party scripts and styles, their origin, stability, and SRI use when technically applicable.

Possible action

Remove unnecessary third-party resources, self-host when appropriate, and use SRI only when the resource and update lifecycle make it suitable.

Observation: { "evidence": null, "severity": "info" }
Understand: Public page resource and integrity-attribute inspection
Source: Observed public page
Reliability: Medium
What this supports: Describe visible supply-chain exposure and SRI use
What this does not prove: Missing SRI does not mean a resource is malicious, and static parsing may miss dynamic loads.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - supply-chain risk context Context only, scope must be established separately
Regulation (EU) 2022/2554 - DORA ICT third-party risk context for entities in scope

View raw data

{
    "evidence": null,
    "severity": "info"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#32 Public HTTP response

Evidence: http_header

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: [ "cloudflare" ]
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

[
    "cloudflare"
]

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#33 Mail-related public records

Evidence: mail_policy_flag

Public mail policies show how the domain frames sending, authentication and email transport.

Active non-intrusive High

Why it matters

These mechanisms can reduce domain spoofing and document mail-transport posture.

What to check next

Relate SPF, DKIM when a selector is known, DMARC, MX, MTA-STS and TLS-RPT. Compare policy changes over time.

Possible action

Before strengthening a policy, inventory legitimate mail flows and verify alignment. Roll out changes progressively to avoid blocking authorized senders.

Observation
Understand: Public DNS and policy endpoint inspection
Source: Mail-related public records
Reliability: High
What this supports: Describe published mail authentication and transport policies
What this does not prove: They do not prove actual deliverability, every recipient’s behavior, or the absence of phishing.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Sender Policy Framework RFC 7208
Domain-based Message Authentication, Reporting, and Conformance RFC 7489
SMTP TLS Reporting RFC 8460
SMTP MTA Strict Transport Security RFC 8461

View raw data

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#34 Public HTTP response

Evidence: module_finding

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: { "evidence": null, "severity": "low" }
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

{
    "evidence": null,
    "severity": "low"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#35 DNS public records

Evidence: dns_address

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: 2606:4700:3036::ac43:8475
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

dig A dimaready.com && dig AAAA dimaready.com

View raw data

2606:4700:3036::ac43:8475

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#36 DNS public records

Evidence: spf_record

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: v=spf1 -all
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

v=spf1 -all

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#37 Public transparency endpoint

Evidence: module_finding

Public artefacts such as security.txt make some technical processes verifiable.

Passive Medium

Why it matters

A documented reporting channel supports responsible coordination when an issue is found.

What to check next

Check expiry, contact, Canonical, Policy, Encryption and any signature. Compare the file with previous scans.

Possible action

Publish a compliant security.txt only when a real handling channel exists, keep it current, and align contacts with the internal reporting process.

Observation: { "evidence": 404, "severity": "medium" }
Understand: Public transparency artefact inspection
Source: Public transparency endpoint
Reliability: Medium
What this supports: Describe published disclosure mechanisms
What this does not prove: A file being present does not prove response speed or overall organizational maturity.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

A File Format to Aid in Security Vulnerability Disclosure RFC 9116

View raw data

{
    "evidence": 404,
    "severity": "medium"
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

#38 Observed public resources

Evidence: dependency_provider

Scanapse shows visible providers and third-party services on which the public service depends.

Passive Medium

Why it matters

Concentration on one actor or many third parties can affect continuity and governance.

What to check next

Identify each provider role, functions concentrated on the same actor, and dependencies that appeared or disappeared since the previous scan.

Possible action

For a critical dependency, document owner, contract, reversibility, failover and rationale. Diversify only after analysing the actual need.

Observation: { "critical": true, "hosts": [ "cloudflare.com", "david.ns.cloudflare.com", "thea.ns.cloudflare.com" ], "id": "cloudflare", "known": true, "name": "Cloudflare", "observation_count": 3, "services": [ "cdn", "security" ], "tracker": false }
Understand: Public HTML/resource dependency extraction and provider matching
Source: Observed public resources
Reliability: Medium
What this supports: Describe visible third-party dependencies
What this does not prove: A visible dependency does not prove data location, actual contractual jurisdiction, or hidden subcontractors.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - supply-chain risk context Context only, scope must be established separately
Regulation (EU) 2022/2554 - DORA ICT third-party risk context for entities in scope

View raw data

{
    "critical": true,
    "hosts": [
        "cloudflare.com",
        "david.ns.cloudflare.com",
        "thea.ns.cloudflare.com"
    ],
    "id": "cloudflare",
    "known": true,
    "name": "Cloudflare",
    "observation_count": 3,
    "services": [
        "cdn",
        "security"
    ],
    "tracker": false
}

Rule 2026.09.4 · 2026-09-04T19:57:33+00:00

Show technical details

{
    "schema_version": "2.0",
    "engine_version": "2.6.0.1",
    "pattern_version": "2026.09.4",
    "scope": {
        "mode": "passive",
        "coverage": "partial",
        "access_level": "partial",
        "access_reason": "error_document",
        "requests": 4,
        "homepage_only": true,
        "javascript_executed": false,
        "ports_scanned": false,
        "private_networks_blocked": true,
        "protection_bypassed": false,
        "max_body_bytes": 1572864,
        "scan_budget_seconds": 24,
        "budget_exhausted": false,
        "transport": "curl_with_socket_fallback"
    },
    "entity": {
        "id": "3d1133096ac0e363d9e9316a4d37f3ca7d812f70772e92b013e9db433c201770",
        "display_name": "dimaready.com",
        "slug": "dimaready-com",
        "entity_type": "domain_subject",
        "auto_created": true,
        "primary_asset": "dimaready.com"
    },
    "methodology": {
        "version": "2.3.1",
        "model": "evidence_first",
        "principles": [
            "absence_of_evidence_is_not_evidence_of_absence",
            "unknown_remains_unknown",
            "provider_metadata_is_not_data_location",
            "edge_provider_is_not_origin_host",
            "single_snapshot_does_not_prove_resilience"
        ]
    },
    "trajectory_summary": {
        "has_previous_scan": true,
        "change_counts": {
            "stable": 39
        },
        "observation_count": 38,
        "evidence_count": 38,
        "provider_count": 1,
        "strategic_signal_count": 1,
        "top_signal_count": 1
    }
}