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
| Topic | Position |
|---|---|
| Deployment model | Customer-managed self-host by default; you run Honua in your own cloud account. |
| Workload data access | Your geospatial data stays in your infrastructure. Honua has no default access to it. |
| Control framework | Security program anchored on the CSA Cloud Controls Matrix (CCM) v4. |
| Certifications | None yet. CSA STAR Level 1 self-assessment in progress; OWASP ASVS Level 1 self-attested. No SOC 2 or ISO 27001 certification today. |
| Vulnerability reports | security@honua.io; acknowledgment target within three business days; safe harbor for good-faith research. |
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 Cloud early-access 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 OIDC under the Pro entitlement and multi-provider OIDC with custom claim-to-role mapping under Enterprise; 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.
| Framework | Status | How to obtain |
|---|---|---|
| CSA STAR Level 1 (CAIQ v4 self-assessment) | In progress | The public STAR registry listing will be linked here once live. |
| OWASP ASVS v4.0.3 (application security) | Level 1 self-attested (June 2026); Level 2 gaps tracked | Self-assessment available on request via security@honua.io. |
| NIST CSF / CIS Controls v8 | In progress — first-pass gap assessments drafted | On request once finalized. |
| SIG Lite questionnaire | Answered, cross-referenced to CCM v4 | Available on request for active evaluations. |
| SOC 2 Type II | Planned — not started; no report exists | — |
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.
| Artifact | What it is | Availability |
|---|---|---|
| OWASP ASVS v4.0.3 self-assessment | Level 1 self-attested (published June 24, 2026), grounded in code review with per-chapter evidence paths; Level 2 gaps tracked as backlog. Self-attested, not audited. | On request |
| SIG Lite questionnaire (answered) | Pre-filled SIG Lite answers, first pass June 2026, derived row-by-row from the CCM v4 control register so answers never overstate register status. | On request for active evaluations |
| CSA CCM v4.0 control register | The master control register (statuses: implemented / partial / planned; last reviewed June 14, 2026) that every other artifact derives from, with a crosswalk toward SOC 2, ISO 27001, and NIST CSF. | Walked through with evaluating security teams on request |
| Information-security policy set | Eight approved policies (approved June 14, 2026): information security, access control, incident response, change management/SDLC, data classification & retention, business continuity, vendor management, acceptable use. | On request under the terms of your evaluation |
| CAIQ v4.0.3 self-assessment (CSA STAR Level 1) | In draft, derived from the CCM register; not yet complete or submitted to the CSA STAR registry. Self-attested when published, not audited. | Once submitted; the public STAR listing will be linked here |
| NIST CSF 2.0 gap self-assessment | Program-level first-pass gap assessment (June 2026) with a scored function summary and remediation backlog. | Once finalized |
| CIS Controls v8 gap self-assessment | First-pass gap assessment against the Implementation Group 1 baseline (June 2026). | 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:
| Evidence | What it shows |
|---|---|
| Capability evidence index | Per-capability receipts: proving tests with CI runs, OGC CITE conformance results, real-client interop envelopes, benchmark runs, and executable samples. |
| GitHub organization | Public source for the server, SDKs, and tooling — inspect the security middleware, authorization pipeline, and CI gates directly. |
| OpenSSF Scorecard | Weekly supply-chain posture scores for selected public repositories (substitute other honua-io public repositories in the viewer URL; not every repository publishes a Scorecard). |
| security.txt · Security policy | RFC 9116 disclosure channel and the coordinated-disclosure terms behind it. |
| SSL Labs | Live TLS configuration grade for honua.io — run it now. |
| Mozilla HTTP Observatory | Live HTTP security-header assessment for honua.io — run it now. |
| securityheaders.com | Independent response-header check for honua.io — run it now. |
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.