How Honua protects the platform—and your data.

Last updated: July 27, 2026

This page summarizes Honua's security posture for buyers and security reviewers: architecture, encryption, access control, data residency, attestation status, and the public evidence behind each claim. Every statement here describes what exists today; nothing on this page is a certification claim.

Report a vulnerability: security@honua.io · Security Policy · security.txt

Posture at a glance

Security architecture

Honua Server is a single .NET runtime in which every public protocol surface (GeoServices REST, OGC APIs, WFS/WMS/WMTS, OData, STAC, tiles, gRPC, MCP) is a thin adapter over shared, centrally audited pipelines. Security-relevant behavior is implemented once, not per protocol:

• Shared enforcement pipelines. Query, edit, metadata, raster, and process execution flow through canonical pipelines, so authorization, validation, error mapping, and telemetry cannot silently diverge between protocols.
• Input validation and parameterized data access. Requests pass shared validation middleware (injection, path-traversal, and encoding pattern checks) and all database access uses parameterized queries; filter parsers are recursion-depth-capped.
• Error hygiene. A global exception pipeline maps failures to safe problem responses; SQL text, stack traces, filesystem paths, and connection strings are never returned to clients.
• Hardened build discipline. The server builds with warnings-as-errors and enforced architecture tests; changes land only through peer-reviewed pull requests on protected branches.
• Threat modeling. STRIDE threat models are maintained for the primary attack surfaces — feature access, administration, process/job execution, import/export, and rendering — and residual risks are tracked to closure in the engineering backlog.

Encryption & data protection

• In transit. The server enforces HTTPS redirection and emits HSTS (one year, including subdomains); HTTP Basic credentials are only accepted over HTTPS; mutual TLS with client certificates is available for service-to-service traffic.
• At rest. In the customer-managed default, at-rest encryption is provided by your data stores and cloud key management (PostgreSQL/PostGIS volumes, Redis, object storage). Honua's deployment guidance documents this expectation explicitly; Honua never holds your data-encryption keys.
• Secrets. Configuration uses secret references resolved at runtime against managed secret stores (AWS Secrets Manager, Azure Key Vault). No plaintext secrets in code; org-wide secret scanning with push protection guards the repositories.
• Data minimization. The public website collects evaluation-inquiry and Preview trial enquiry form submissions, consent-gated analytics, and the basic server logs inherent to hosting (collected by the hosting provider independently of analytics consent) — all described in the privacy notice. Product telemetry stays inside your deployment (OpenTelemetry to the backend you configure).

Access control & authentication

• Role-based access control in one place. Authorization is enforced in a shared pipeline — at service, layer, field, job, and mutation scope — rather than by per-endpoint discipline. Denied decisions are logged.
• Durable role storage. Role assignments persist in a PostgreSQL-backed store and survive restarts.
• Authentication options. Scoped API keys by default; the public source implements single-provider and multi-provider OIDC with custom claim-to-role mapping. All catalog entitlements are active in 2026.1; Pro/Enterprise assignments are 2026.2 intent; mutual-TLS client certificates are supported. OIDC remains off until configured.
• Request accountability. Administrative and mutating requests pass through audit-logging middleware with correlation IDs; in customer-managed deployments, long-term log retention is handled by the logging pipeline you attach.
• Organizational access. Honua staff access to organizational and cloud-administrative systems requires MFA and follows least-privilege with joiner/mover/leaver revocation.

Data residency

Because Honua is customer-managed by default, residency is under your control: your data lives in the cloud accounts and regions you choose and does not transit Honua-operated infrastructure. Honua staff have no default access to customer workload data. Any future Honua-managed hosting offering will publish its own residency commitments before launch.

Sub-processors

In the self-hosted default there are no workload sub-processors to disclose: no third party processes your geospatial data on Honua's behalf, because Honua itself does not process it. Two narrower scopes do exist:

• This website uses GitHub Pages (hosting), FormSubmit (contact-form delivery), and Google Analytics (consent-gated) as service providers, as described in the privacy notice.
• Commercial engagements. If a support or services contract requires Honua to process customer personal data, the applicable sub-processors are disclosed in that contract package, and a formal public sub-processor register will be published before any Honua-managed hosting offering launches.

Vulnerability disclosure & incident response

• Coordinated disclosure. Report vulnerabilities to security@honua.io per our security policy and RFC 9116 security.txt. We aim to acknowledge complete reports within three business days and provide safe harbor for good-faith research.
• Incident response. An approved incident-response policy defines the detect → triage → contain → eradicate → recover → review lifecycle, with customer notification per contractual and legal obligations.
• Detection surface. The server ships OpenTelemetry traces, metrics, and structured logs so your operations team can wire detection and alerting into your existing stack.

Secure development & supply chain

• Change management. Protected-branch pull requests with repository-specific quality gates; the server build treats warnings as errors and enforces architecture and coverage checks.
• Automated scanning. CodeQL static analysis, Dependabot dependency alerts and security updates, and secret scanning with push protection are enabled across organization repositories where repository visibility and GitHub features permit; container images are scanned with Trivy and infrastructure-as-code with Checkov.
• Supply-chain pipeline. The release pipeline is configured to generate CycloneDX/SPDX bills of materials and keyless-sign the platform manifest and BOM with cosign. No promoted public release artifact is linked yet; this page will link the first signed release when it ships.
• Posture transparency. Selected public repositories publish OpenSSF Scorecard results (re-scored weekly), and OpenSSF Allstar monitors organization-wide repository-policy drift.

Standards & attestations

Honua's control program is anchored on the CSA Cloud Controls Matrix v4: controls, policies, and evidence are organized against CCM so the same register can later support SOC 2, ISO 27001, and NIST CSF work. The table states current status honestly — self-assessments are not audits, and Honua holds no third-party certification today.

An approved information-security policy set (information security, access control, incident response, change management/SDLC, data classification & retention, business continuity, vendor management, acceptable use) backs the register; policies are shared with evaluating security teams on request.

Request the compliance pack

For a security review, Honua shares a compliance pack drawn from its private control repository. Every artifact in it is a self-attestation or internal working document — none is a third-party certification or audit report, and no SOC 2, ISO 27001, or equivalent certification exists today. Request it at security@honua.io; items marked in progress are shared once finalized.

What we will not claim: none of the above is FedRAMP, StateRAMP, CJIS, SOC 2, ISO 27001, or any other certification, authorization, or third-party attestation. If your review requires a certification Honua does not hold, we will say so directly rather than approximate it.

Public evidence & external validators

Prefer evidence you can check yourself. These surfaces are public and re-runnable:

Honest boundary: this site is currently served from GitHub Pages, which does not attach the repository's full response-header set, so header-based validator scores reflect the meta-CSP baseline rather than the complete edge-delivered header policy. The security page documents that boundary and when the fuller header set becomes claimable.

Shared responsibility & current scope

Honua secures the software and its release pipeline; you control the cloud account, network perimeter, TLS termination, WAF and rate-limiting policy at the edge, backups, and identity-provider integration unless a signed agreement assigns a responsibility differently. This boundary is deliberate and documented so there are no surprises in a security review — the full split, plus data-processing terms, lives on the Security & DPA page.

Questions from your security team? Email security@honua.io — we will walk through the control register, share the compliance pack artifacts listed above, and provide policy documents under the terms of your evaluation. Commercial and procurement questions: info@honua.io.

AI security assurance

Our AI framework assessment is in progress. Review the framework mappings, source evidence, scope and remaining verification work.