Skip to main content
Some cyber programs use ONYPHE on-demand scans of the applicant’s public internet footprint. The current Qualified Intelligence Cyber program uses the result as underwriting evidence. ONYPHE performs remote checks on the consented targets; Underflow installs no agent on the applicant’s systems. Before Aurora can request a scan, the application must contain:
  • Consent to ONYPHE remote external scanning and vulnerability checks.
  • At least one usable owned or operated domain, or another configured target.
Consent can come from material Aurora reads, a collection conversation, or a fact recorded through Aurora. The Application section currently displays these answers but has no direct field editor.
Do not treat a domain in the application as consent. Aurora refuses the request when consent is unanswered or false.

​
How a scan starts

There is no operator scan button. Aurora decides when the program requires the evidence and calls the scan action. A request is refused when:
  • The program has no scan configuration.
  • The scanning service is not configured.
  • Consent or usable targets are missing.
  • Another run is queued or active.
  • A completed run is less than 30 days old, unless the request is explicitly forced.
A successful request creates a queued run. A background worker launches ONYPHE scans, saves their IDs, and polls for completed results. Retries resume the saved scans.

​
Sources and findings

The scan combines:
  • DNS: the addresses each domain resolves to and the SPF and DMARC records it publishes.
  • ONYPHE: fresh service and vulnerability observations from on-demand scans.
  • Hudson Rock credential exposure.
  • CISA Known Exploited Vulnerabilities.
  • End-of-life software data.
Incomplete, killed, empty or stale provider results fail without recording clean answers. Temporary lookup failures retry in the background; scan completion is bounded to 30 minutes. Unavailable enrichment is recorded in the notes and its answers remain unknown. A successful run clears previous scan answers that its current evidence cannot establish. A failed run keeps previous dated answers and wakes Aurora with the reason. Findings include observed remote access, known exploited CVEs, obsolete software, email authentication, exposed databases and TLS issues. Missing CVE severity, product versions or TLS checks remain unknown. Exposed secrets, dangling DNS and compromise indicators remain for the underwriting team to establish from a security report.

​
Underwriting effect

The program derives a technical security score from the scan. Until the required observed-at fact exists, the application is incomplete for quoting. Depending on the result:
  • The score changes rating.
  • A score above the program threshold requires referral.
  • A remotely accessible known exploited vulnerability creates a blocking clean-rescan subjectivity.
  • Internet-facing end-of-life software can require referral.
  • Active compromise can lead to declination.
Aurora receives a new turn when a scan completes or fails. A failure turn carries the run’s reason, and it is Aurora’s call whether to run the scan again or ask the desk.

​
Current visibility

The workbench has no dedicated scan-status screen. Operators see completed findings as application answers, with the evidence behind each as its note, and can ask Aurora about the run.
A terminal scan failure currently creates no Desk moment and may leave the requested scan visible only through the action history. If required scan facts do not arrive, ask Aurora for the current state and contact Underflow before quoting.